LOGGING, MONITORING, AND DETECTION STANDARD

Mandatory Log Sources · SIEM Onboarding · Day-One Detection Set · OT and CUI Overlays · Triage and Tuning

Table of Contents

1. Purpose and Scope
2. Operating Principles
3. Mandatory Log Sources
4. Log Routing, Protection, and Retention
5. SIEM Onboarding
6. Day-One Detection Set
7. Detection Lifecycle and Validation
8. Alert Triage and Tuning
9. OT Monitoring Overlay
10. CUI Monitoring Overlay
11. Identity Detection Use Case Pack
12. Regulatory and Framework Alignment Summary
13. Document Control

1. Purpose and Scope

The policy requires privileged-access logging, log protection, retention, SIEM (or equivalent) monitoring, OT-safe collection methods, and threat-intelligence integration. The IT, OT, CUI, and Access standards each impose more specific log and detection requirements. Until this standard, those requirements existed in fragments, no consolidated list of mandatory log sources, no day-one detection set, no triage procedure.

This standard consolidates those requirements. It defines the log sources every in-scope environment must onboard, how those logs are routed and retained, the detection set the SIEM must implement on day one, and how detections are validated and tuned over time. It applies to every in-scope asset and every CERG-managed detection platform.

Detection Coverage Is a Product, Not a Project

Onboarding a SIEM is a project. Detection coverage is the ongoing measurement of whether the detections that should be firing actually do, for the threats that matter to this environment. CERG instruments coverage as a metric (DT-001 in CERG-GOV-MTR-001) and treats anything below the target as an incident-readiness gap.

2. Operating Principles

1. MITRE ATT&CK is the threat reference. Detection scope and prioritization use ATT&CK Enterprise (IT/cloud/SaaS), ATT&CK for ICS (OT), and ATT&CK for Cloud sub-matrices.
2. Day-One Set is non-negotiable. Every in-scope environment has the minimum detection set in Section 6 enabled within 30 days of onboarding (CERG-X-05).
3. Coverage over count. A SIEM with 4,000 rules and 35% real ATT&CK coverage is worse than a SIEM with 400 rules and 80% real ATT&CK coverage.
4. Tune to signal, not silence. A muted alert that should have fired is an incident. Tuning suppresses noise, not findings.
5. Logs are immutable. No production identity can edit or delete a log inside its retention period.
6. OT collection is passive by default. Collection methods that risk OT availability are prohibited without engineering approval.

3. Mandatory Log Sources

The list below is the minimum every CERG-managed environment must onboard. Anything not listed may still be required by a subordinate standard; nothing in this list may be waived without an approved exception per CERG-PRC-RM-001.

3.1 Identity, Endpoint, and Application

3.2 Cloud and SaaS

3.3 Network, Vulnerability, and Telemetry

3.4 OT (See Also §9)

3.5 CUI (See Also §10)

4. Log Routing, Protection, and Retention

4.1 Routing

• IT/cloud/SaaS logs route to the enterprise SIEM via supported native connectors or log shippers.
• OT logs route via the one-way transfer pattern specified in CERG-STD-OT-001 and Section 9 below. No bidirectional pulls from OT.
• CUI logs route to a SIEM tenancy / index that aligns with the CUI boundary and supports FIPS-validated transport (CERG-STD-CR-001).

4.2 Protection

• Logs are written to immutable / WORM storage for the retention period.
• Administrative actions on logs (delete, retention change, export) are themselves logged and reviewed.
• Log access follows least privilege per CERG-STD-AC-001; privileged log access uses PAM.

4.3 Retention

5. SIEM Onboarding

Onboarding follows a fixed checklist. The output is a SIEM Onboarding Record per environment.

5.1 SIEM Onboarding Checklist

5.2 Source Health Monitoring

Each onboarded source is itself monitored. CERG alerts on:

• Source silence (no events for > expected interval).
• Volume drop > 30% week-over-week (configurable per source).
• Parsing failure rate > 1%.
• Connector error or authentication failure.

These alerts are treated as high-priority operational items, not as detections in their own right.

6. Day-One Detection Set

The Day-One Detection Set is the minimum coverage required in any in-scope environment within 30 days of onboarding. The set is curated against MITRE ATT&CK with ATT&CK Enterprise as the IT spine, ATT&CK for Cloud sub-techniques for cloud/SaaS scopes, and ATT&CK for ICS for OT scopes.

6.1 Day-One: IT / Cloud / SaaS / Identity

6.2 Day-One: OT

6.3 Day-One: CUI

CUI overlay (see Section 10) adds CUI-specific detections (export, share, label changes, classified-data movement to non-CUI destinations).

6.4 Coverage Reporting

• Coverage is computed as the % of ATT&CK techniques within the in-scope sub-matrix that have at least one detection authored, tested, and operating. Reported as DT-001 in CERG-GOV-MTR-001.
• CERG coverage target: 70% of in-scope ATT&CK sub-matrix techniques with at least one operating detection. Below 70% is reported red on the CISO dashboard and treated as an incident-readiness gap until closed.
• The detection inventory is exported monthly and reviewed quarterly against the in-scope sub-matrix.

7. Detection Lifecycle and Validation

Every detection has a lifecycle from Proposed through Retired. Detection metadata is recorded in the detection inventory.

7.1 Detection Metadata

Each production detection has:

• ID and name
• ATT&CK technique(s) and tactic(s)
• Data sources used
• Logic summary (no proprietary leakage outside detection eng)
• Severity / triage queue routing
• Expected fire rate (per env)
• False-positive notes and tuning history
• Last purple-test validation date and result
• Owner

7.2 Validation

• Detections are validated quarterly via the purple-team procedure in CERG-PRC-AV-001 §6.
• Validation result feeds metric DT-002.
• Failed validations open a risk register entry per CERG-PRC-RM-001 until restored.

8. Alert Triage and Tuning

8.1 Triage Queue Model

• P1, Critical: business impact suspected; SOC engages immediately and pages IR per CERG-PLN-IR-001.
• P2, High: likely true positive worth examining within hours.
• P3, Medium: worth examining within the shift.
• P4, Low: examined for trends; bulk-tuned where appropriate.

8.2 Triage SLA

8.3 Tuning Discipline

• Tuning suppresses noise; tuning never suppresses findings.
• Every tuning change records: detection ID, reason, suppressed condition, expiration / review date.
• Tuning changes are reviewed monthly; expired tunings are reinstated unless renewed with justification.

The Bar for Suppressing an Alert

If a tuning suppresses a condition that has ever yielded a real finding in this environment, peer organization, or current threat intelligence, the tuning needs a different shape, a different field condition, a different threshold, not a blanket suppression.

9. OT Monitoring Overlay

OT monitoring adds to the IT pattern; it does not replace it.

• Passive monitoring is the default. Span / tap / mirror-fed sensors capture protocol-aware traffic for asset inventory, anomaly, and detection.
• Engineering-supervised authenticated checks allowed in defined windows for endpoint health, configuration capture.
• One-way transfer to SIEM. Data diodes or filtered one-way pipelines per CERG-STD-OT-001.
• OT-specific detection set per Section 6.2.
• OT alerts route through a queue that the SOC and OT operations both see to avoid loss of fidelity in handoff.
• No active scanning of live OT surfaces without an approved scope and time window per CERG-PRC-AV-001.
• CIP-015 (forward-looking). As CIP-015 finalizes, the BES INSM detection set in Section 6.2 is the foundation; additional CIP-015 detections are added when the standard is approved.

10. CUI Monitoring Overlay

• CUI labeling enforcement. Data classified as CUI is labeled in source systems; movement of labeled data is monitored.
• CUI exfiltration alerts. Outbound transfers of CUI to non-CUI destinations trigger P2 minimum.
• CUI workspace boundary alerts on any cross-boundary access attempts.
• EDR on CUI endpoints has CUI-aware policies (USB lockdown, application allowlist).
• Threat advisories relevant to CUI (DFARS / DC3 advisories) are routed to detection engineering and incorporated where applicable.

11. Identity Detection Use Case Pack

Identity is the most common attack surface; CERG names a use case pack explicitly.

12. Regulatory and Framework Alignment Summary

13. Document Control

Source: standards/CERG-STD-LM-001_Logging_Monitoring_and_Detection_Standard.md · Download .md · View on GitHub