Audit Protection

Protect audit information and audit logging tools from unauthorized access, modification, and deletion.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.3.8.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   audit information is protected from unauthorized access;

   1 example covers this

2. [b]

   audit information is protected from unauthorized modification;

   1 example covers this

3. [c]

   audit information is protected from unauthorized deletion;

   1 example covers this

4. [d]

   audit logging tools are protected from unauthorized access;

   1 example covers this

5. [e]

   audit logging tools are protected from unauthorized modification; and

   1 example covers this

6. [f]

   audit logging tools are protected from unauthorized deletion.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][c][d][e][f]

  AU.L2-3.3.8 · Audit 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

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  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

  Cloud-native logging. Motivated by an incident at a peer where an administrator cleared a Windows event log and the only copy went with it.

  Tools

  • Elastic Security
  • Object storage
  • Cloud landing zone
  • SIEM

  Edit history

  · No edits yet