Safeguard 8.8: Collect Command-Line Audit Logs

Safeguard 8.8 requires you to capture and centrally collect audit logs that show command-line activity (the actual commands executed) on systems where command execution can materially affect security. To operationalize it, enable command-line/audit logging on covered endpoints and servers, forward events to your central log platform/SIEM, validate completeness, and retain evidence that the control runs continuously. ¹

Key takeaways:

• Turn on command-line telemetry at the endpoint/server layer, then forward it to a central collector you monitor.
• Scope matters: prioritize admin paths, servers, and high-risk endpoints where command execution changes configurations or data.
• Auditors will ask for proof of coverage and proof of ongoing operation, not just a policy.

Command lines are where attackers and admins both go to get work done fast: PowerShell, cmd, bash, zsh, Python shells, remote execution tools, and management frameworks. That makes command execution one of the highest-signal sources for detection and investigation. Safeguard 8.8 (CIS Controls v8) is the requirement that closes the “we didn’t log what was typed” gap by collecting command-line audit logs into a place where they can be searched, correlated, and retained. ¹

For a Compliance Officer, CCO, or GRC lead, the practical goal is simple: prove that command execution on in-scope systems is recorded with enough context to support incident investigation, and prove it stays on. You do not need perfect telemetry on day one. You do need a defensible scope, documented configuration standards, centralized collection, and repeatable evidence capture.

This page translates safeguard 8.8: collect command-line audit logs requirement into a quick, operator-ready implementation plan: applicability, concrete steps, required artifacts, audit questions, and the mistakes that cause control failures.

Regulatory text

Excerpt (provided): “CIS Controls v8 safeguard 8.8 implementation expectation (Collect Command-Line Audit Logs).” ¹

Operator interpretation: You must record command-line activity (commands executed) on relevant systems and collect those logs centrally so they can be monitored, searched, and retained. The control is not satisfied by local-only history files or ad hoc troubleshooting logs. It expects intentional audit logging plus collection. ¹

Plain-English interpretation (what the requirement means)

Safeguard 8.8 expects you to answer these questions from logs, reliably:

• What command was run?
• Who ran it (user/service account)?
• Where was it run (hostname, asset ID, IP, session type)?
• When was it run (timestamp, timezone consistency)?
• How was it run (interactive shell, remote admin tool, scheduled task, automation pipeline)?

From a compliance perspective, the success condition is evidence of continuous command-line log generation + centralized collection + coverage for in-scope assets. ¹

Who it applies to (entity and operational context)

Entity types: Enterprises and technology organizations adopting CIS Controls v8. ¹

Operationally, it applies wherever command execution materially affects security or data, including:

• Servers and workloads (Windows, Linux) running business services.
• Admin workstations / privileged jump hosts used for system administration.
• Endpoints where scripting is common (IT, engineering, finance workstations with automation).
• Cloud workloads where you manage instances via SSH, SSM, run-command, or similar tooling.
• Containers/Kubernetes nodes where interactive exec or automation runs commands (scope based on feasibility and your logging architecture).

High-priority scoping rule (use this in your control narrative): Start with systems that have (a) privileged accounts, (b) administrative tooling, (c) access to sensitive data, or (d) exposure to the internet. Expand coverage as your telemetry pipeline stabilizes.

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

Use this as a build sheet. Write each step into your control procedure and assign an owner.

1) Define scope and minimum log fields

Create a one-page “8.8 Logging Standard” that includes:

• In-scope asset classes (servers, admin endpoints, jump hosts).
• In-scope command interpreters (PowerShell, cmd, bash, SSH sessions, remote execution).
• Minimum fields: timestamp, host, user, process, command line, and outcome/exit code where available.
• Central destination: SIEM/log platform name and environment (prod/non-prod separation if applicable). This is the document auditors will read first. ¹

2) Enable command-line audit logging per platform

Work with endpoint/server engineering to turn on the platform-native logging that captures command-line details.

Windows (typical patterns):

• Enable process creation auditing with command-line capture.
• Enable PowerShell logging where appropriate (script block/module logging policies depend on your risk appetite).
• Confirm events include full command line and user context.

Linux/Unix (typical patterns):

• Enable audit logging for execve/command execution via audit frameworks where feasible.
• For SSH and privileged shells, ensure session attribution is preserved (user identity, source).

Your procedure should specify “enabled via baseline configuration” rather than “enabled manually.” That is how you keep it on. ¹

3) Forward logs to a central collector and normalize

Set up reliable collection:

• Install/enable your log forwarder/agent on in-scope hosts.
• Route logs to a central collector (SIEM, log analytics, data lake).
• Normalize key fields so searches work across OS types (user, host, command_line, parent_process, session_id).
• Tag events with environment, asset criticality, and owner team for triage.

Control objective: command-line logs are available centrally without logging into the host. ¹

4) Validate coverage and completeness (the step most teams skip)

Run a validation cycle that produces auditable output:

• Pick representative hosts in each asset class.
• Execute benign test commands (e.g., directory listing, whoami, system info) with a named test account.
• Confirm the events appear in the central platform with expected fields within your operational monitoring window.
• Document gaps by platform/OU/subnet/image and track remediation.

Store the query screenshots/exports and the test plan as evidence. ¹

5) Operational monitoring: alerting and review

CIS safeguard 8.8 is “collect,” but examiners often test whether collection is operationally meaningful. Add at least:

• A daily or weekly check that log volume from in-scope groups is non-zero.
• A detection or dashboard for high-risk command patterns (encoded PowerShell, suspicious download/execute chains, privilege escalation tooling), tuned to your environment.
• An incident-response handoff: how to pull command-line trails during investigations.

Write down who reviews, what they check, and where they record outcomes. ¹

6) Retention and access controls

Define:

• Retention period for command-line audit logs (align to your internal policy and any other frameworks you follow).
• Access controls: who can query raw command-line logs, how access is approved, and how queries are audited.
• Separation of duties for log administrators vs. system administrators where feasible.

Even without a prescribed number in CIS 8.8, you need a documented retention and access model to make “collect” defensible in an audit. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Control design (static)

• Logging standard for safeguard 8.8 (scope, fields, systems, tooling). ¹
• System configuration baselines/GPOs/MDM profiles/auditd rules showing command-line logging enabled.
• Log forwarding architecture diagram (sources → forwarders → collector/SIEM).

Operating evidence (recurring)

• Sample SIEM queries and exported results showing command-line events (with hostname, user, command line, timestamp).
• Coverage reports: list of in-scope assets and confirmation that each is sending command-line logs.
• Exception register: systems not covered yet, with compensating controls and remediation dates.
• Monitoring records: dashboard screenshots, tickets, or review attestations showing ongoing checks.

Evidence tip: Store the exact queries used for validation and periodic checks. Auditors like repeatability more than screenshots. ¹

Common exam/audit questions and hangups

Expect these, and pre-answer them in your control narrative:

1. “Which systems are in scope and why?”
   Have a scope statement tied to asset inventory and criticality.

2. “Show me an example of a captured command with user attribution.”
   Be ready with two examples: Windows PowerShell and Linux SSH.

3. “How do you know logging is still enabled?”
   Show baseline enforcement (GPO/MDM/config management) plus a recurring coverage check.

4. “What about administrators who can clear local logs?”
   Explain central forwarding and retention; local tampering does not remove centrally collected events.

5. “How do you handle sensitive data in command lines?”
   Have guidance: do not pass secrets in CLI args; add DLP/redaction controls where your platform supports it; restrict access to logs.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits	Fix
Relying on local shell history (bash_history, PSReadLine)	Easy to delete/disable, not centralized, often missing attribution	Use OS audit/process creation logs and forward centrally. 1
Logging is enabled, but forwarding is inconsistent	“Collect” implies central availability; gaps break investigations	Add a coverage dashboard and alert on silent hosts.
No documented scope	Auditors treat scope gaps as control failure	Publish a scoped standard plus an exception register.
Capturing commands without user/session context	Logs become low value for IR	Require fields for user, host, session type, parent process.
Over-collecting with no access controls	Creates privacy and insider-risk exposure	Tight RBAC for log search, audit access, and document approvals.

Risk implications (why CIS 8.8 is assessed)

Command lines are a primary path for:

• Living-off-the-land execution (native tools used for malicious actions).
• Rapid configuration changes that break security baselines.
• Data staging and exfil preparation steps.

Without command-line audit logs, investigations become testimonial. That increases containment time and weakens root-cause analysis. From a governance standpoint, it also undermines your ability to prove administrative accountability. ¹

A practical 30/60/90-day execution plan

Use this as an operational cadence. Adjust to your change windows and tooling.

First 30 days (stabilize scope + prove feasibility)

• Publish the safeguard 8.8 logging standard (scope, minimum fields, central destination). ¹
• Identify in-scope “tier 1” systems: domain controllers or identity systems, core servers, jump hosts, and admin workstations.
• Turn on command-line logging for one Windows group and one Linux group.
• Forward to SIEM/log platform; run test commands; save validation evidence.

Days 31–60 (expand coverage + operational checks)

• Roll configuration through baselines (GPO/MDM/config management) for all tier 1 systems.
• Build a coverage report that maps in-scope asset inventory to “sending command-line logs: yes/no.”
• Implement a recurring review: silent-host alerts, volume anomalies, and a short analyst checklist.
• Open exceptions for hard cases (legacy OS, appliances) with compensating controls.

Days 61–90 (make it audit-ready)

• Extend to broader endpoint groups and additional server tiers.
• Document retention and access controls for command-line logs (RBAC, approvals, audit trails).
• Run an internal “mini-audit”: pick random hosts, reproduce command execution, and show the event trail end-to-end.
• Package your evidence in a single folder: standard, baselines, diagrams, coverage report, sample queries, review records. ¹

Where Daydream fits (without creating tool lock-in)

Most teams fail safeguard 8.8 during assessments because evidence is scattered across engineering tickets, SIEM screenshots, and undocumented baselines. Daydream helps you map safeguard 8.8 to a documented control statement, define recurring evidence capture (coverage reports, validation queries, review attestations), and keep an exception register that an auditor can follow without re-interviewing engineering.

Frequently Asked Questions

Do we need to collect command-line logs from every endpoint?

Start with systems where command execution presents the highest risk (admin endpoints, jump hosts, servers). Document your scope and exceptions, then expand coverage as the telemetry pipeline matures. ¹

Are bash history files sufficient for safeguard 8.8?

No. Local history is user-controlled and often incomplete, and it is not centralized collection. Use OS audit/process execution telemetry and forward it to your central log platform. ¹

How do we handle commands that include secrets in arguments?

Set an engineering standard that prohibits secrets in command-line arguments and enforce it through CI/CD and admin guidance. Restrict access to command-line logs and document approvals for log search access.

What evidence will an auditor ask for first?

A scope statement, proof that command-line logging is enabled via baseline configuration, and SIEM exports showing real command lines with user/host attribution. Also expect a coverage report showing which in-scope systems are sending logs. ¹

What if we use a managed EDR instead of native OS audit logs?

That can satisfy the intent if the EDR reliably captures full command lines and you can export or forward those logs to centralized storage/search. Document the data source and show recurring evidence that collection is continuous. ¹

How do we prove logging stays enabled over time?

Show configuration enforcement (baseline policy) plus recurring operational checks that detect silent hosts and configuration drift. Keep the review records and alert history as evidence. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8