AWS · Detection · CloudTrail Evidence
AWS CloudTrail Detection Reasoning
Intermediate LAB for understanding how CloudTrail evidence supports detection reasoning for iam:PassRole, sts:AssumeRole, Lambda updates, Secrets Manager access, KMS decrypt, and workload identity activity.
Overview
CloudTrail Detection Reasoning teaches how to interpret AWS API activity as security evidence. It moves the L2 track from access-control theory into investigation reasoning.
Concept Deep Dives
Expand these concepts when studying event evidence, investigation context, or detection logic.
What is CloudTrail?
CloudTrail records AWS API activity. It helps analysts understand who made a request, which API was called, which resource was targeted, when it happened, and whether the request succeeded or failed.
What is detection reasoning?
Detection reasoning is the process of turning raw event records into security meaning. The analyst asks whether the event is expected, risky, denied, successful, chained, or part of a larger path.
Why does iam:PassRole matter in CloudTrail?
PassRole events show when a principal attempted to attach or delegate a role to an AWS service. When paired with Lambda create or update activity, PassRole can indicate workload identity risk.
Why do Secrets Manager and KMS events matter together?
GetSecretValue shows secret retrieval. KMS Decrypt may show cryptographic access used to read protected secret material. Together, they can form a stronger evidence path than either event alone.
What should executives understand?
CloudTrail is evidence, not just logging. It helps prove whether sensitive access happened, whether a risky path was attempted, and whether control assumptions match real activity.
Visual CloudTrail Detection Model
Detection reasoning is easiest to understand as an evidence path from API call to investigation decision.
Example Scenario
A role updates Lambda code, then the workload accesses Secrets Manager and KMS.
CloudTrail signal path:
1. lambda:UpdateFunctionCode
2. secretsmanager:GetSecretValue
3. kms:Decrypt
Detection reasoning:
- Did the same identity or session initiate the path?
- Did the Lambda execution role retrieve the secret?
- Was this expected deployment behavior?
- Did KMS decrypt align with the secret access?
- Should this become a finding or investigation?
Bridge to Principal LABs
Principal LABs become more complete when learners can connect attack-path reasoning to evidence-path reasoning.
Governance Boundary
This lab is read-only and deterministic.
Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
- Does not query customer CloudTrail
- Does not invoke AWS APIs against customer accounts
- Does not deploy detection rules
- Does not create alerts
- Does not execute remediation
- Does not create Shield findings
- Does not create Aegis fixtures
- Does not override OPA
Source Artifacts
metadata.jsonarchitecture.mdindex.html