Org trails & immutable logging

One trail to a locked account, tamper-evident.

You cannot respond to what you cannot see, and you cannot trust evidence an attacker could edit. The foundation of AWS 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 deleting it is not an option even for a compromised admin.

One organization trail to a locked account

Configure a single organization CloudTrail that captures management events (and, where affordable, S3/Lambda data events) from every account and delivers them to a dedicated log-archive account. Segregating logs from the accounts that generate them means a workload compromise cannot reach its own audit record. Lock the destination bucket with Object Lock and a deny-delete bucket policy, and enable log-file validation so any tampering is cryptographically detectable.

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
aws cloudtrail update-trail --name org-trail --enable-log-file-validation
 
# Bucket in the log-archive account: Object Lock ON at creation + deny-delete.
{
  "Sid": "DenyLogTampering", "Effect": "Deny", "Principal": "*",
  "Action": ["s3:DeleteObject","s3:PutBucketVersioning","s3:PutObjectRetention"],
  "Resource": "arn:aws:s3:::acme-org-audit/*"
}

Config for state, and alert on blinding

CloudTrail records API calls; AWS Config records resource configuration over time and evaluates rules, so you can answer "what did this security group look like at 14:00?" and detect drift. Combine both with alerting on the meta-events — StopLogging, DeleteTrail, StopConfigurationRecorder, bucket-policy changes on the log sink — because an attacker who understands the trail tries to blind it first. "Someone touched logging" is one of the highest-signal detections you can have.