Cloud Logging and Detection: CloudTrail and Friends

The cloud has one enormous gift for defenders: because every action is an API call, every action can be logged, in structured form, with the identity that made it. AWS CloudTrail, Azure's activity and sign-in logs, and Google Cloud Audit Logs are the flight recorders of your estate. The catch is that the recorder is only as useful as your decision to enable it, retain it, and actually look at it.

CloudTrail records the control-plane calls made in an AWS account: who called which API, when, from where, and whether it succeeded. Azure Activity Log and Microsoft Entra sign-in logs, and GCP's Admin Activity and Data Access audit logs, play the same role on their platforms. Together they are the primary source of truth for cloud incident response — when a breach happens, this is the record you reconstruct the timeline from.

Management events vs data events

A distinction trips up teams constantly. Management events — creating a role, changing a policy, launching an instance — are logged by default and are cheap. Data events — reading an individual S3 object, invoking a specific Lambda — are high-volume, off by default, and cost extra. The gap matters: without data-event logging, you can see that a role was assumed but not necessarily which objects it then read. Deciding where you need object-level visibility is a real design choice, not a checkbox.

The signals worth alerting on

Raw logs are not detection; they are the substrate for it. Certain events are high-signal enough to alert on directly, and they map cleanly to attacker behaviour:

• Root / global-admin usage. The most privileged account should almost never act. Any use is worth an immediate page.
• IAM changes. New trust-policy edits, policy attachments, access-key creation, and login-profile resets — the fingerprints of privilege escalation.
• Logging tampering. StopLogging, deleting a trail, or disabling audit logs is a near-certain sign someone wants to go dark. Alert on it and protect the logs from the identities they record.
• Anomalous credential use. A role assumed from a new country, an access key used from an unfamiliar ASN, or a sudden burst of Describe/List calls — the reconnaissance that follows initial access.
• Security-control changes. Security groups opened, public-access blocks removed, GuardDuty or Defender disabled.

Building detection that lasts

• Centralise and protect logs. Ship every account's trail to a dedicated, locked-down logging account with object-lock or immutability, so an attacker who owns a workload cannot erase the evidence.
• Turn on log-file integrity validation so tampering is detectable, and set retention to match your investigation and compliance needs.
• Layer managed threat detection. GuardDuty, Defender for Cloud, and Security Command Center consume these logs and flag known-bad patterns you would otherwise write rules for yourself.
• Route to a SIEM and write behavioural rules for the escalation and exfiltration patterns specific to your environment, then tune out the noise so real alerts are seen.

Cloud logging flips the usual asymmetry: the same API surface that lets an attacker act at machine speed also records every move they make. That advantage only exists if the recorder is running in every account, feeding somewhere someone watches. An account with logging disabled is a blind spot by definition — and you can't detect, or defend, what you haven't discovered.