Security Audit Logging

After discovering unauthorized data access, the incident response team asked the obvious question: "Who accessed this data, when, and from where?" The answer was devastating. Nobody knew. The application logged errors and performance metrics but not security events. There were no records of who logged in, who accessed sensitive resources, who changed permissions, or who exported data.

Without audit logs, the team could not determine the scope of the breach, which users were affected, or how the attacker got in. The company had to assume the worst and notify all 2 million users, a decision that cost $4.5 million in notification expenses and destroyed customer trust. If they had audit logs, the scope might have been limited to 200 affected accounts.

Equifax's 2017 breach investigation was hampered by the same problem. The attackers operated undetected for 76 days because security event logging was fragmented and incomplete. Contrast that with GitHub's 2022 OAuth token incident where their audit logs enabled them to identify exactly which repositories were accessed, by which tokens, within hours.

Security audit logging is NOT the same as application logging. Application logs capture errors, performance metrics, and debug information. Security audit logs specifically record who did what to which resource, when, and whether it was allowed.

Security events you must capture:

Every log entry must contain these fields:

Tamper protection is non-negotiable. If an attacker can delete audit logs to cover their tracks, the logs are worthless. Write to append-only storage: S3 with Object Lock (WORM mode), CloudWatch Logs (cannot delete individual entries), or immutable Azure Blob storage. Forward logs to a separate system (SIEM) that the application has no write or delete access to.

Retention requirements by compliance framework: