AU-6(8): Full Text Analysis of Privileged Commands

AU-6(8) sits in the Audit and Accountability family of NIST SP 800-53 and is aimed at a common failure mode: privileged users can do the most damage, and basic event logs often miss the most important detail, the exact commands executed. This enhancement makes the expectation explicit. You must (1) log privileged commands in a way that preserves the actual command text, and (2) analyze that logged command text in a physically distinct subsystem or a dedicated analysis system.

For a Compliance Officer, CCO, or GRC lead, the trap is treating this as a “logging is enabled” checkbox. It is an operational control: you need a defined scope of privileged command sources, reliable log transport to an analysis environment that is separated from the monitored systems, and a routine for full-text review (manual or automated detections) with documented follow-up.

This page translates the requirement into an implementable runbook, the minimum evidence bundle to retain, and the audit questions you should be ready to answer. Source references are limited to NIST SP 800-53 artifacts provided. ¹

Regulatory text

Requirement (AU-6(8)): “Perform a full text analysis of logged privileged commands in a physically distinct component or subsystem of the system, or other system that is dedicated to that analysis.” ²

What the operator must do:

1. Ensure privileged commands are logged with full command text (not summaries, not just session starts, not only success/failure).
2. Move those logs to a distinct analysis environment (physically distinct component/subsystem, or a dedicated analysis system).
3. Perform “full text analysis” on the privileged command logs, meaning you can search, pattern-match, and/or run detections against the command strings and their parameters, then act on findings.

Plain-English interpretation

• “Privileged commands” means admin-level actions that can change security posture, access, configuration, or data.
• “Full text analysis” means your reviewers and detection logic can see the actual command text (example: the exact PowerShell, SQL, kubectl, or sudo command) and analyze it for risky patterns.
• “Physically distinct” means analysis is not performed on the same machine or subsystem where the commands run. This reduces the chance an attacker with admin access can tamper with logs and the analysis tool at the same time.

Who it applies to

Entities

• Federal information systems and contractor systems handling federal data using NIST SP 800-53 as a control baseline. ³

Operational context (where auditors expect this to land)

• Systems with privileged interactive administration (Windows admin, Linux root/sudo, network device admin, database admin).
• Environments with automation using elevated permissions (CI/CD runners, IaC pipelines, break-glass accounts, privileged service accounts).
• Central logging programs where a SIEM/log analytics platform is treated as the “dedicated analysis system.”

What you actually need to do (step-by-step)

Step 1: Define scope and ownership (make it auditable)

Create a short “control card” that answers:

• Owner: Security Operations (primary), with Infra/Platform as implementers; Compliance/GRC as oversight.
• In-scope command sources: servers, endpoints, network devices, cloud control planes, databases, Kubernetes.
• In-scope privileged identities: root, local admins, domain admins, IAM admin roles, break-glass, privileged service accounts.
• Cadence: how analysis runs (continuous detections plus scheduled review).
• Escalation path: what becomes an incident, who gets paged/ticketed.

This converts AU-6(8) from “a logging idea” into an owned control that can be tested.

Step 2: Capture privileged command text at the source

You need logging that records the actual command line or script content. Examples of what “good” looks like:

• Linux/Unix: shell history is not sufficient by itself; focus on audit-grade sources that record executed commands with context (user, TTY/session, time).
• Windows: capture PowerShell script block/module logging where applicable, plus process creation command line events where feasible.
• Databases: record executed SQL statements for privileged users (at least for admin actions) and relevant administrative stored procedures.
• Kubernetes/Cloud: collect API audit logs that include request payloads (the “command” equivalent) for cluster/admin role actions.

Design decision you must document: what counts as “privileged commands” in your environment, and which logging sources produce full-text command visibility.

Step 3: Send logs to a physically distinct analysis environment

Meet the separation requirement by using:

• A central log platform (SIEM/log analytics) that is separate from production hosts and managed with separate admin access.
• A dedicated logging pipeline (collectors/forwarders, storage, analytics) that is hardened and access-controlled.

Operational expectations to document:

• Immutable or tamper-resistant storage controls in the analysis environment (conceptually; implementation varies).
• Access separation: production admins should not be able to edit/delete analysis data without independent oversight.
• Time synchronization and log integrity checks as part of your logging program, so text analysis results map back to real events.

AU-6(8) is not asking for a specific product. It is asking for a separation-of-duties outcome: privileged command execution happens “over there,” analysis happens “over here.” ²

Step 4: Implement “full text analysis” as detections + review

Treat analysis as two layers:

A. Automated detections (primary) Build detections that query command text for risky patterns. Examples to tailor:

• Commands that disable logging, clear logs, change audit policy, or alter EDR/AV settings.
• Creation of new privileged users/keys, changes to sudoers, IAM policy attachments, or group membership changes.
• Data access patterns suggesting bulk export (database dump commands, cloud storage sync/copy at scale).
• Use of “living off the land” tooling (encoded PowerShell, suspicious curl/wget with execution, remote shell invocation).

B. Scheduled review (backstop) Even with good detections, set a recurring review where an analyst pulls:

• A sample of privileged command logs (by system tier, by identity type).
• All “high-risk” command categories for the period.
• Commands executed by break-glass accounts.

Document what “reviewed” means: reviewer name, date/time, queries run, exceptions noted, and tickets created.

Step 5: Define response and exception handling

Your runbook should specify:

• Triage criteria: what makes a privileged command suspicious vs. expected maintenance.
• Approval mapping: link certain risky changes to change tickets (so the analyst can validate authorization fast).
• Exception process: allowlists for known automation accounts and scripts, but require:
  • expiry dates,
  • periodic re-validation,
  • a record of why the exception does not increase unacceptable risk.

Step 6: Prove the control operates (control health checks)

Run recurring control health checks focused on:

• Are all in-scope sources still forwarding command logs?
• Did any endpoint/server stop sending logs?
• Did parsing break (fields missing command text)?
• Are detections firing and being dispositioned?

Track issues through closure with tickets and evidence of remediation.

Required evidence and artifacts to retain

Auditors and customer assessors usually want a tight evidence bundle. Keep it simple and repeatable.

Minimum evidence bundle (retain in a controlled repository):

• Control card / runbook: scope, owner, cadence, escalation, exception rules.
• Log source inventory: list of systems generating privileged command logs, with source type and where command text is captured.
• Architecture diagram: showing log forwarding into a physically distinct analysis system.
• Configuration evidence (samples are fine): representative logging settings that demonstrate command text capture.
• Detection logic or saved queries: the actual SIEM queries/rules used for full-text analysis.
• Review records: analyst reviews, query outputs or references, disposition notes, and tickets/incident links.
• Exception register: allowlists, rationale, approver, expiry, re-validation evidence.
• Control health check results: missed logs, parser failures, tuning changes, remediation tickets.

If you use Daydream to manage controls, map AU-6(8) to a single control card, attach the evidence bundle per review cycle, and track health checks and remediation tasks to closure so you can answer audits with one record set rather than scattered screenshots.

Common exam/audit questions and hangups

Expect these questions, and prepare crisp answers:

1. “Show me that you capture the command text, not just ‘admin activity.’”
   Hangup: teams only log authentication and privilege escalation events, not the command line or request payload.

2. “Where does analysis occur, and how is it physically distinct?”
   Hangup: logs stored and analyzed on the same host (or same admin plane) that privileged users can alter.

3. “Who reviews the output, and what happens when you find something?”
   Hangup: detections exist but no ticketing, no triage notes, no evidence of follow-up.

4. “How do you prevent admins from deleting or tampering with the logs?”
   Hangup: access controls are unclear; too many people have admin to the SIEM and production.

5. “How do you know the control is still working?”
   Hangup: no health checks; sources drift, agents break, parsers change.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AU-6(8)	Fix
Logging only privileged logins, not commands	No “full text” to analyze	Enable sources that record command lines/script blocks/API payloads; validate fields in SIEM
Treating shell history as the main record	Easy to delete/alter; incomplete context	Use audit-grade telemetry and central forwarding to the analysis system
SIEM exists but no defined analysis procedure	“Perform analysis” becomes untestable	Write saved queries, set review cadence, require tickets for findings
Analysis environment shares admin access with production admins	Separation goal is undermined	Separate roles, strong access controls, independent review for SIEM admin actions
Allowlisting everything noisy	Blind spots for real abuse	Time-bound exceptions with approver, rationale, and periodic re-validation
No linkage to change management	Analysts can’t quickly decide “expected vs. suspicious”	Require change ticket IDs for high-risk privileged activities and train reviewers to check them

Enforcement context and risk implications

No public enforcement cases were provided in the source material for AU-6(8), so this page does not cite specific actions. Practically, failure modes for AU-6(8) show up during investigations and assessments as: inability to reconstruct admin actions, delayed detection of misuse of privileged access, and weak separation between operators and monitoring systems. Those outcomes increase the impact of credential compromise and insider misuse.

A practical 30/60/90-day execution plan

Use this as an operator’s rollout plan. Adjust sequencing based on system criticality.

First 30 days (establish control shape)

• Assign an owner and publish the AU-6(8) control card (scope, cadence, escalation, exceptions).
• Identify top privileged command sources (critical servers, identity systems, cloud admin plane).
• Validate that logs arriving in the analysis environment include full command text fields for at least one source per platform.
• Stand up initial saved queries for the highest-risk command patterns (logging disablement, privilege grants, suspicious remote execution).
• Start a lightweight review record template (date, queries run, findings, tickets).

Days 31–60 (expand coverage and make it repeatable)

• Expand command-text logging coverage across the in-scope fleet; close gaps where command text is missing.
• Formalize access separation for the analysis environment (who can administer SIEM, who can view/search, who can delete).
• Implement alert routing to ticketing/incident tooling; require disposition notes.
• Create an exception register for noisy automation, with approvals and expirations.

Days 61–90 (prove operating effectiveness)

• Run a control health check cycle and document results (sources, parsing, alert flow, reviewer actions).
• Tune detections based on false positives and operational realities; keep a tuning log.
• Execute a tabletop: pick a privileged command scenario and confirm you can trace command text to identity, system, time, and follow-up actions.
• Package the evidence bundle for audit readiness (runbook, diagrams, queries, review records, tickets, exceptions).

Frequently Asked Questions

What counts as “privileged commands” for AU-6(8)?

Commands executed by accounts or roles that can administer systems, change security settings, or access sensitive data at scale. Define your own list by platform (root/sudo, Windows admin, cloud IAM admin roles, DBAs) and document it in the control card. ²

Does AU-6(8) require a SIEM?

No specific tool is required, but you must analyze command text in a physically distinct component/subsystem or a dedicated analysis system. A SIEM commonly satisfies the “dedicated analysis system” expectation if it is separated from production and has controlled access. ²

What does “full text analysis” mean in practice?

It means your analysts and detections can inspect the actual command strings (and relevant parameters) from privileged activity logs. Evidence usually includes saved searches/detection rules and review records that show those searches were run and acted upon.

Can analysis happen on the same server where the commands were executed?

That conflicts with the requirement’s separation language, which calls for a physically distinct component/subsystem or another dedicated analysis system. Send logs off-host to a separate analytics/logging environment and perform analysis there. ²

How do we handle automation accounts that run privileged commands constantly?

Treat them as in-scope, then manage noise with narrowly scoped allowlists and time-bound exceptions tied to known scripts and expected command patterns. Require an approver and an expiry date so exceptions don’t become permanent blind spots.

What evidence is most persuasive to an auditor?

A short runbook plus proof of operation: sample logs showing command text, an architecture diagram showing separation, saved queries/detections, and review/ticket records showing findings were dispositioned. Consistency matters more than volume.

Footnotes

1. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI; NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON