Blog

Security Starts When Authentication Ends: Analysing Application Activity

This is the second in a three part series taking a look at the rise of pre-emptive identity security and the need to detect and disrupt adversarial attack activity before it completes. The first article introduced the concept of shifting “left of boom” in identity.

What Happens After Login

  • Tokens, Sessions and Access
  • Application Activity
  • Tying it all Together

We are all familiar with authentication and the “login-event”. This main pinchpoint to workforce single sign on and consumer applications gets considerable attention – and for good reason. Migrations to strong and hopefully password-free authentication, the constant uplift in multi-factor modalities and consolidation deliver both security and productivity improvements. Whilst the password may not be dead, it is certainly very ill. We have many technical alternatives including the rise of passkeys which has seen a huge uptick in adoption in the past three years. But authentication factors alone will not solve the problem of our identity and access management infrastructure and identities within it being such an adversarial target. 

For seasoned red team operators, automation, logic chaining, and adaptive attack processes have been part of daily tradecraft for a long time. Legitimate teams have used automated tooling to accelerate everything from reconnaissance to exploitation, from social engineering to post-exploitation and persistence.

Why? Because automation buys time and time is the most valuable resource in an engagement. The more you can offload, the more you can think, pivot, and react. It’s exactly the same reason adversaries do it.

So, while the Anthropic report is new in attribution, it’s not new in concept. The only real change is scale and accessibility. What once required a team of skilled operators and custom tooling is now achievable through an MCP and an LLM that can be scripted to think, reason, and act semi-autonomously.

However, as authentication techniques become more difficult to attack on a per user basis, adversarial activity seeps into these more downstream parts of the access journey. We start to see man in the middle (MiTM) style attacks against the issued session and token material. If the tokens are not bound to the original device or browser that started the authentication journey (and there are techniques such as demonstration of proof of possession DPoP to help here, as well as basic TLS implementation) then they can be stolen and replayed as a very basic example. So perhaps whilst password-migration can negate brute-force attacks and credential theft attacks, authentication by-pass and session specific attacks still exist.

Even without token theft, behaviour issues in downstream systems are often not tracked at a fine-grained level or correlated across applications, identity providers or over federated boundaries too. We can then start to see disconnects between assigned permissions, claims and expected behaviour, versus what is actually happening in the downstream system. Is it valid? Has the activity changed? How does it compare historically or to other users? Either these analysis points can’t be fulfilled due to a lack of information, or the tools are simply not available to do so. 

The net result? Consumer fraud. Employee fraud. Data exfiltration resulting in compliance issues, intellectual property loss and competitive disadvantage.

Securing the Enterprise Application Space

  • Humans, Non-Humans and AI
  • Cross-Application View
  • Behaviours Over Rules

As our authentication (and even external authorization) capabilities mature and become more stable from a design and implementation perspective, we need to start considering how to deliver a more holistic approach to securing the application layer from an identity centric perspective. We need to link together the entire identity information flow – including the “story of access” – focusing on authentication, session management and IDP interaction – as well as the downstream application activity.

In order to make more informed decisions about malicious behaviour it is critical we can understand not only the attribution of an identity, but also the intent.  Attribution is focused upon concepts like identity verification and validation – perhaps using biometrics for people or process attestation for workloads. Intent – that is going to require a deeper understanding of activity.

This concept should also not be limited to a specific type of identity, account or system. We have a broad array of identity types to manage today – including people (for staff and customers), non-human for services and workloads as well as the emerging and volatile agentic-AI. 

A consumer may login to a web application, but fulfillment of their order may well use agents, workloads and service accounts. An employee sharing a file across teams, may leverage APIs and containers to complete the task. So to that end, we need to extend the lens of focus – by analysing service and application activity. 

A second aspect to consider is the need to go across-application. Siloed patterns of activity can mask the true intention of the actor. Be it malicious or benign, the ability to capture and correlate same-identity activity across similar or orthogonal systems provides further intelligence with respect to intention and and in turn risk assessment.

What Capabilities Do We Need

  • Data, Data, Everywhere
  • Timeline Analysis and Evaluation
  • Automated Response

The modern identity analysis stack needs to be fed data. This is going to come from a variety of sources – from identity providers, directories, policy enforcement points, system logs and application activity sources. We currently live in a highly asymmetric world as it pertains to information security analysis and management. The adversary often has the advantage due to essentially being hidden – either between product stacks, or between jump off points and trust boundaries across different technologies. This provides an advantage with respect to attribution and intent exposure. 

Attribution can be improved by tying authentication events closer to the identity verification and validation stages. This essentially allows the identity assurance level (IAL) and authentication assurance level (AAL) to overlap and remove the possibility of gaps existing between strong onboarding stages and poorly executed credential issuance or credential reset processes. Intent is a more complex issue – and requires a broader view of behaviour and a composite approach to risk assessment. The more data we have, the higher fidelity decision making we can achieve.

Whilst data collection – via log analysis, API scanning and the like – should be broad in coverage and simple to expand – it is only one part of the approach. Previous-era approaches to log analytics (see security information event monitoring (SIEM) and user entity behaviour analytics (UEBA)) were often reliant on rules. Sets of signatures that mapped into security controls for well known “bad things” that could happen. The standard “known knowns” approach. These “best practices” are well understood and documented. But that also means they are well known to the “bad guys”. They’re too static and easy to avoid and often result in high alert fatigue anyway. A switch to behaviour analysis is well underway that supports the ability to look for “needles in needlestacks” and be confident in identifying “unknown unknowns” and zero-day type patterns of attack.

Some other subtle requirements will emerge here – from the ability to cross-reference behaviour across systems, but also across specific time-lines. This improves the ability to identify changes in behaviour either for an individual against itself – the classic “salami attack”, or across a group of peers, allowing specific “trendy” events to be collected to create “trends” of bad behaviour. Individual events that go under the threshold from a risk perspective can then be re-evaluated in runtime based on better intelligence across the entire application ecosystem.

Whilst many organisations are not ready for entirely automated responses, as an industry we are getting closer to achieving this. Playbook response, targeted automated remediation and human in the loop approaches to runtime approvals and notifications allow security operation steams to disrupt inflight attacks at speed. Be that associated with account and permissions change, policy improvements or session and access evaluation changes.


To learn more about how to shift left of boom, explore the Reveal Platform here.