Nothing Ran. Everything Changed.

An intrusion that executes nothing

A cloud environment has two surfaces, and security programmes were built almost entirely for one of them. The data plane is where workloads run: the instances, the containers, the functions, the things an agent can be installed on. The control plane is the API that creates, configures and destroys all of it.

An attacker who holds a credential with enough rights does not need the data plane at all. Creating an access key, attaching a policy, taking a snapshot of a volume and sharing it with another account are four API calls. None of them runs code anywhere you are watching, and all four are operations a platform engineer performs on an ordinary Tuesday.

This is the uncomfortable part for anyone whose cloud security posture is an agent on every instance. The agent is working. It is reporting accurately that nothing executed. The intrusion happened in the layer above it, and it was logged, in a place most operations collect and almost nobody investigates.

The logs are a different shape, and the detection has to be too

Endpoint telemetry describes behaviour. A process started, it had a parent, it was launched with these arguments, it opened that file. The whole discipline of endpoint detection rests on those relationships, because the relationships are what make a lone event meaningful.

Control plane audit logs describe intent. One line per API call: who the principal was, which service, which action, with what parameters, from what address, and whether it succeeded. There is no parent, no tree and no session beyond the credential that signed the request. A detection engineer coming from the endpoint world finds the fields they rely on simply absent.

What replaces them is the principal and the order. The unit of analysis is not a process but an identity, and the evidence is not a single call but a sequence of them across services that are not otherwise related. Every rule written against a single cloud event is therefore either noisy or narrow, and usually both.

• No process tree, so no parent to ask about.
• No command line, so nothing to pattern match on.
• No file hash, so no reputation lookup to lean on.
• No session, only a credential, which may have been issued months ago.
• No ordering, because each call is logged alone and the attack is the order they arrived in.

Blast radius is a permissions graph, not a network diagram

In a data centre, what an intruder can reach is a routing question, and it is answered by firewalls and segments. Those are physical facts that a network engineer can draw. In a cloud environment reach is an identity question, and the answer is held in policy documents that nobody draws.

Role chaining, trust policies, workload identity, resource-level policies and federation from an external directory all grant reach that has no network component. Two accounts with no route between them can be one API call apart, because the connection was never meant to be a route. It was meant to be a permission, and permissions are what the environment runs on.

This is why a cloud incident so often turns out to be larger than it first looked. The first answer to what the attacker could reach is drawn from the network, and it is the wrong graph. The right graph is the one nobody has assembled, which is the set of principals this credential can become and what each of those can do.

Five calls, and none of them is wrong

The sequence is worth reading as a defender, because the thing to notice is that there is no moment in it where a rule should fire on its own.

Enumerating your own permissions is something every automation framework does at startup. Assuming a second role is the mechanism roles exist for. Creating an access key is a self-service operation. Snapshotting a volume is a backup. Sharing a snapshot with another account is how a legitimate cross-account workflow moves data.

The attack is the conjunction. One principal, in one short window, performing all five, in that order, when it has never performed any of them before. That statement can be detected. None of the five statements underneath it can.

There is no travel time in the control plane

On a network an attacker moves. Each hop to a new host takes an action, leaves a trace and costs time, which is the assumption underneath every metric the industry quotes about intrusion speed. Average breakout time for a criminal intrusion is 29 minutes, down from 98 minutes in 2021, and that number describes a world where getting somewhere else is work.

A permission change has no equivalent. A policy attached in one call does not propagate and does not need to arrive anywhere. It is simply true at the next call, everywhere, at once. The gap between an attacker having limited rights and having broad ones is not a journey, it is an edit.

The practical consequence is that the window for a cloud investigation is set by how fast the attacker can type, not by how far they have to go. An investigation queue measured in hours is not slightly behind in this environment. It is answering a question about a configuration that no longer exists.

The provider's own alerts are a floor

Every major platform ships a detection service, and they are worth switching on. They are good at the things a single event can carry: a call from an address with a known-bad reputation, a disabled logging configuration, credentials used from an unusual location.

What none of them is positioned to do is reason across an estate that spans more than one platform, more than one account and more than one identity provider, which is the shape of almost every real environment. The organisation's identity provider is not the platform's. Half the workloads are somewhere else. The on-premises estate the attacker came from is not in the picture at all.

Treating native detections as the floor and building the correlation above them is the only arrangement that survives a multi-platform estate. It is also the arrangement that lets an investigation follow a principal from a phished session, into the control plane and out to the data, which is the path the incident actually took.

The investigation spans four places, and it is the same cost

Answering a cloud alert honestly requires the control plane audit record, the identity provider that issued the credential, the workload the credential belongs to, and the data layer where the object actually lives. Each holds a quarter of the answer and none of them holds enough to close the ticket.

Performed by hand this is the familiar work: five to twelve consoles, 60 to 90 minutes, and a queue that decides which alerts get this treatment and which get a glance. In an environment with no travel time, that triage is not a prioritisation decision. It is a coverage decision, made by the clock rather than by anybody.

Run by agents, the same collection and correlation completes in 60 to 120 seconds and runs on every qualified alert rather than on the ones a shift reached. The analyst receives a timeline that already crosses the four domains, and spends their judgement on whether to revoke, which is the part that was always worth a person.

Containment is a different set of actions

The instinct to isolate the host is useless here, because the attacker is not on a host. The actions that end a control plane intrusion are policy actions, and they have the same awkward property that identity containment has: each one leaves something behind that the next must clean up.

Revoking a credential does not end sessions already issued from it. Detaching a policy does not undo a role the attacker can still assume by another path. Deleting a key does not remove the user it belonged to. And a snapshot that was shared out is already a copy somebody else controls, so removing the share stops the next read without retrieving the first one.

That last point is worth sitting with, because it changes what speed is for. In this category, containment after the fact frequently cannot restore the position. The value of a minute-scale investigation is that it closes the gap before the copy is made, not that it cleans up faster afterwards.

What to ask of a cloud detection capability

The questions that separate a capability from a dashboard are specific and are mostly about whether the evidence joins up.

Most products will answer the first two well. The ones that matter are the last three, because they are the difference between watching a cloud estate and being able to investigate one.

• Does it ingest control plane audit logs from every platform in use, not just the largest one?
• Can it follow one principal across accounts, across platforms and back to the identity provider that issued the credential?
• Does it reason over the sequence of calls, or alert on them individually?
• Can it answer what this credential could reach, from the permissions graph rather than the network?
• Does the response reach policies, keys, roles and resource shares, or does it stop at stopping an instance?

The honest version

Cloud security has spent a decade being described as a posture problem, and posture management is genuinely useful: finding the public bucket and the over-permissive role before anybody walks through them is cheaper than detecting it afterwards.

But posture is about the shape of the environment at rest, and an intrusion is a thing that happens in it. A configuration that was correct this morning is not a defence against a principal that changed it this afternoon, and the change was a permitted API call made with a valid credential.

What that leaves is detection, in a layer with no process trees, across an estate with no single platform, against a sequence where every individual step is legitimate. It is not a rule-writing problem, and it was never going to be solved by another agent on another instance.