Triage: validating what you were told

Triage — the sequence that turns a finding into a scoped incident

1. A finding arrives

   From GuardDuty, Security Hub, Inspector, Macie, a Config rule, a CloudWatch alarm, or a human report.

2. Read it properly: type, severity, resource, principal, window

   The finding type tells you what pattern matched, which tells you what evidence would confirm or refute it. Note the exact time window — every subsequent query depends on it.

3. Confirm the resource and the principal are what the finding says

   Does the instance still exist? Which account and OU? What is its role, its tags, its owner? Is the principal a human identity, a role assumed by a workload, or a long-term access key? Each answer points at a different playbook.

4. Pull the CloudTrail events around the window

   The finding says a pattern matched; CloudTrail says what the principal actually called, from where, and with what result. This is where a hypothesis becomes evidence or dissolves.

5. Is this behaviour expected for this principal?

   Two ways to get this wrong: calling real activity "expected" because it looks familiar, and calling expected activity an incident because it looks alarming. Verify with the resource owner rather than assuming either way.

6. Not an incident — suppress precisely, and record why

   A suppression rule scoped to this finding type and this resource, with a written reason and a review date. A blanket suppression of the finding type is how the next real one gets missed.

7. Classify severity against the published table

   Your severity, not the detector’s. A MEDIUM finding on a production database holding personal data outranks a HIGH finding in a sandbox. The finding’s severity is one input.

8. Scope it: what else did this principal touch?

   Every API call by this principal in the window, every resource it reached, every other principal it assumed or created, and whether the same source IP appears elsewhere. This is what containment has to cover.

9. A scoped incident you can act on

   Confirmed, classified, and with a blast radius written down — the handover containment actually needs.

Which principal — and why it changes everything

Three cases, three playbooks. A role assumed by a workload (an instance profile, a Lambda execution role) means temporary credentials, so you are looking for exfiltration and your containment lever is session revocation plus the resource that held them. A long-term IAM user access key means a static secret that may be in a repository, a laptop, or a CI system, so containment is deactivation and the investigation extends to wherever the key was stored. A federated human identity means the compromise may be in the identity provider, not in AWS at all — and containment includes the provider’s session, not just the AWS role. Read the userIdentity block in CloudTrail before choosing a playbook.

What CloudTrail tells you that the finding cannot

The finding describes a pattern; CloudTrail describes actions. For each call in the window you get the principal and session, the sourceIPAddress and userAgent, the exact API and parameters, the result (including errorCode — a run of AccessDenied is an attacker mapping their permissions), and the request id you can cite. Search it with CloudTrail Lake or Athena rather than by scrolling the console, and remember the boundary: management events are on by default, data events are not — if nobody enabled S3 data events, "which objects were read?" may be unanswerable, which is itself a finding for the post-incident backlog. The query craft lives in Log Analysis.

The two ways to get "is this expected?" wrong

Over-familiarity: the activity resembles something legitimate, so you close it. Attackers deliberately use normal-looking APIs from normal-looking agents; "our backup job does that" needs to be checked against the backup job, not remembered. Over-alarm: the activity looks dramatic, so you isolate production — and the dramatic thing was a penetration test, a new deployment, or an engineer debugging. The discipline is the same in both directions: get a verification, from the resource owner or the change record, and write it down. An unverifiable "expected" is treated as unexpected.

Scoping questions, in the order they pay off

Which other resources did this principal touch in the window? Which other principals did it create, assume, or modify — new users, new access keys, new roles, new trust policies? Does the source address or user agent appear anywhere else, in any account? Did anything persist — an EventBridge rule, a Lambda function, a launch template, an identity provider? And what data was read or copied, because that question drives the notification obligations rather than the technical response. Answer them in that order and the containment plan writes itself.

Correlating across services and accounts

No single service answers a scoping question on its own. Security Hub gives you every finding about the resource from every detector, deduplicated and in one schema, which is the fastest way to see that Inspector already reported an unpatched CVE on this instance. Detective gives you the relationships and the baselines over time. CloudTrail Lake or Athena gives you precise, citable queries. Amazon Security Lake gives you the normalised log data to run your own or third-party analytics across accounts. Use findings to orient, the graph to scope, and the logs to prove.