AU.L2-3.3.8Audit Protection
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
[a]
audit information is protected from unauthorized access;[b]
audit information is protected from unauthorized modification;[c]
audit information is protected from unauthorized deletion;[d]
audit logging tools are protected from unauthorized access;[e]
audit logging tools are protected from unauthorized modification; and[f]
audit logging tools are protected from unauthorized deletion.
Write-once archive in a separate account so a log admin cannot erase their own trail
Implementation
AO coverage. Addresses all six Audit Protection objectives: audit information protected from unauthorized access [a], modification [b], and deletion [c], and the logging tools themselves protected from unauthorized access [d], modification [e], and deletion [f].
Access to audit information [a]. Search access is role-based and scoped: analysts read the indices they need, application owners see only their own source, and nobody reads audit data through a shared credential. Index-level permissions are defined as code, and access grants to audit data are themselves logged.
Modification and deletion [b][c]. Events forward continuously to an archive bucket in a separate cloud account with object lock in compliance mode. Nobody in the operational account — including the log administrators — holds credentials in the archive account, so the copy of record cannot be altered or removed even with full rights on the analytics platform. Local host logs are treated as transient by design: they are a convenience copy, and the archive is the authority.
Protecting the tools [d][e][f]. Platform administration is limited to the two roles described in the AU.L2-3.3.9 example, and the platform's own configuration (ingest pipelines, retention policies, detection rules, role definitions) is deployed from version control with deletion protection on the underlying resources. Changes to retention or to the archive lifecycle raise a high-severity alert regardless of who made them, because a legitimate retention change is rare and an illegitimate one is the first move in covering tracks.
Maintenance. Quarterly restore test: pull a random day from the archive and confirm it is readable and complete. Semi-annual attempt, by an operational administrator, to delete an archived object — the expected result is denial, and the denial is captured as evidence. Annual review of who holds archive-account credentials.
Accepted gap. One SaaS source cannot forward continuously and is pulled daily. Between pulls, the only copy is in the vendor's tenant under their retention and their access controls, which is a dependency we cannot remove; the pull job's failure alerts on-call so the window never silently extends.
What the evidence looks like
- Role definitions and index-level permissions for audit data
- Object lock configuration on the archive bucket, including the retention mode
- Account separation evidence showing operational admins hold no archive credentials
- Alert rule and history for retention or lifecycle changes
- Quarterly restore test record and the semi-annual denied-deletion attempt
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.