CoursesAdvanced cloud securityDetection, logging & response

Centralized audit logging & immutable trails

Org trails, a separate logging account, and tamper-evidence.

Advanced30 min · lesson 10 of 15

You cannot respond to what you cannot see, and you cannot trust evidence an attacker could edit. The foundation of cloud detection and incident response is a complete, centralized, tamper-evident audit trail — captured org-wide, delivered to an account almost nobody can touch, and protected so that deleting it is not an option even for a compromised admin.

One organization trail to a locked account

Configure a single organization-wide trail that captures management (and, where affordable, data) events from every account and delivers them to a dedicated log-archive account. Segregating the logs from the accounts that generate them means a workload compromise cannot reach its own audit record. Lock the destination bucket with object-lock / retention and a bucket policy that denies deletion, so the trail is write-once even to the account that owns it.

an immutable, org-wide trail sink
# Org trail delivering every account's events into the log-archive account.
aws cloudtrail create-trail --name org-trail \
--s3-bucket-name acme-org-audit --is-organization-trail --is-multi-region-trail
aws cloudtrail start-logging --name org-trail
# Bucket in log-archive: object-lock ON at creation + a deny-delete policy.
{
"Sid": "DenyLogTampering",
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:DeleteObject","s3:PutBucketVersioning","s3:PutObjectRetention"],
"Resource": "arn:aws:s3:::acme-org-audit/*"
}
# Enable log-file validation so any tampering is cryptographically detectable.
aws cloudtrail update-trail --name org-trail --enable-log-file-validation

Tamper-evidence, not just retention

Retention keeps logs; tamper-evidence proves they were not altered. Log-file validation writes signed digest files so you can detect any modification or gap after the fact. Combine that with a separate account boundary, minimal human access, and alerting on the meta-events — StopLogging, DeleteTrail, bucket-policy changes — because an attacker who understands the trail will try to blind it first. An alert on "someone touched the logging config" is one of the highest-signal detections you can have.

Trustworthy audit pipeline
capture
org trail
every account, every region
data events (scoped)
S3/Lambda access where it matters
protect
separate log-archive account
workloads cannot reach it
object-lock + deny-delete
write-once evidence
log-file validation
tampering is detectable
watch
alert on StopLogging/DeleteTrail
blinding attempts are loud
A trail an attacker can stop or delete is not evidence. Isolation + immutability + validation make it one.
Logs in the compromised account are deletable
If the audit trail lands in the same account as the workloads it records, an attacker who owns that account owns the evidence and can erase their tracks. Ship logs to a dedicated account with near-zero human access and immutable storage — evidence integrity is an architecture decision, not a config toggle.