Nexus SecOps Controls Catalog¶

This catalog contains all 220 normative controls organized by domain. Each control uses RFC 2119 language (MUST/SHOULD/MAY). Use the Self-Assessment Workbook to score your organization against these controls.

Domain: TEL — Telemetry & Logging (Nexus SecOps-001–015)¶

Nexus SecOps-001: Log Source Inventory¶

Rationale: You cannot detect what you do not log. An inventory is the foundation for understanding coverage gaps and ensuring accountability for log collection.

Implementation Guidance: Maintain a log source registry in a CMDB, spreadsheet, or dedicated platform. Include fields: source name, IP/hostname, log type, collection agent/method, status (active/inactive), owner, last validated date. Review quarterly.

Evidence to Collect: Export of log source registry showing all fields; date of last review; evidence of quarterly review (meeting notes or ticket).

Tests/Validation: Compare log source inventory against network asset inventory and cloud resource inventory. Identify sources present in asset inventory but absent from log inventory. Calculate coverage ratio.

Metrics: Log source inventory completeness (target ≥98%); staleness (target: no source unreviewed >90 days); owner coverage (target: 100% of sources have named owner).

Common Pitfalls: Inventory created once and never updated; cloud assets omitted; shadow IT log sources unknown; no owner assigned to sources.

Framework Mappings: - NIST CSF: ID.AM-01 (Asset management) - CIS v8: Control 1 (Inventory and Control of Enterprise Assets) - ISO 27001: A.8.1 (Asset inventory) - NIST 800-53: CM-8 (System Component Inventory) - MITRE ATT&CK: Detection gap analysis lens - MITRE D3FEND: D3-NM (Network Mapping)

Nexus SecOps-002: Log Collection Coverage¶

Rationale: Detection coverage is bounded by collection coverage. Missing log sources create blind spots that adversaries can exploit to move undetected.

Implementation Guidance: Define criticality tiers for systems. Ensure Tier 1 (critical) systems have 100% log collection coverage. Use automated deployment of agents or centralized syslog receivers. Validate collection by checking for expected log volume from each source.

Evidence to Collect: Coverage report showing percentage of assets with active log collection by tier; configuration screenshots of collection agents; alert rules that fire when expected sources go silent.

Tests/Validation: Disable logging on a test system temporarily and verify that a coverage gap alert fires within the expected SLA. Compare actual source count to inventory count.

Metrics: Collection coverage by tier (Tier 1 target: 100%; Tier 2 target: ≥95%; Tier 3 target: ≥85%); time-to-detect collection gap (target: <1 hour for Tier 1).

Common Pitfalls: Coverage measured by device count but not by log type; cloud workloads excluded; containerized workloads not instrumented; test systems omitted from scope.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-2 (Event Logging), AU-12 (Audit Record Generation) - MITRE ATT&CK: Detection coverage lens (multiple tactics) - MITRE D3FEND: D3-HA (Hardware Auditing)

Nexus SecOps-003: Log Transport Security¶

Rationale: Unencrypted log transport exposes sensitive operational data and allows adversaries to tamper with or suppress logs during an incident.

Implementation Guidance: Configure TLS on all log shippers (Beats, Fluentd, NXLog, etc.) and receivers. Use certificate pinning or mutual TLS for high-value log streams. Audit TLS configurations quarterly.

Evidence to Collect: TLS configuration screenshots for log shippers and receivers; certificate inventory; network capture showing encrypted log traffic (metadata only, not content).

Tests/Validation: Attempt to intercept log traffic on the network and confirm it is encrypted. Verify TLS version and cipher suite meet policy minimums.

Metrics: Percentage of log streams using TLS 1.2+ (target: 100%); percentage using mutual auth (target: ≥80% for external-facing collectors).

Common Pitfalls: Internal network log streams left unencrypted; TLS 1.0/1.1 still in use; self-signed certificates not rotated; syslog over UDP with no encryption.

Framework Mappings: - NIST CSF: PR.DS-02 (Data-in-transit protected) - CIS v8: Control 3.10 (Encrypt Sensitive Data in Transit) - ISO 27001: A.8.24 (Use of cryptography) - NIST 800-53: SC-8 (Transmission Confidentiality and Integrity) - MITRE ATT&CK: T1557 (Adversary-in-the-Middle — detection lens) - MITRE D3FEND: D3-ET (Encrypted Tunnels)

Nexus SecOps-004: Log Parsing Validation¶

Rationale: A parser that silently drops fields or misformats data creates invisible detection gaps. Analysts and detection rules depend on correctly parsed fields.

Implementation Guidance: Implement parser test suites with representative log samples for each source. Run tests in CI/CD pipelines when parsers change. Monitor parsing error rates in production. Alert on high error rates or sudden changes in field extraction quality.

Evidence to Collect: Parser test suite results; parsing error rate dashboard; alert configuration for parsing failure thresholds; sample of correctly parsed logs.

Tests/Validation: Send a known test log line and verify output fields match expected values. Inject a malformed log line and confirm it is handled gracefully without silent data loss.

Metrics: Parser error rate per source (target: <0.1%); field extraction completeness for required fields (target: ≥99%); time to detect and remediate parser failures (target: <4 hours).

Common Pitfalls: Parser changes deployed without testing; no monitoring on parsing error rates; vendor format changes break parsers silently; multiline logs not handled correctly.

Framework Mappings: - NIST CSF: DE.CM-09 (Computing hardware monitored) - CIS v8: Control 8.2 (Collect Audit Logs) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-3 (Content of Audit Records) - MITRE ATT&CK: Data quality lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-005: Timestamp Normalization¶

Rationale: Timestamp inconsistency is one of the most common investigation blockers. Mixed timezones make timeline reconstruction error-prone and slow incident response.

Implementation Guidance: Configure all log sources to emit timestamps in ISO 8601 format (UTC). If source systems emit local time, perform timezone conversion at the collection layer with documented timezone mappings. Store both original and normalized timestamps.

Evidence to Collect: Documentation of timestamp normalization pipeline; sample logs showing UTC timestamps; timezone mapping table; evidence that NTP is enforced on log sources.

Tests/Validation: Correlate logs from sources in different timezones for a known event and verify timestamps align correctly. Check NTP synchronization status on critical log sources.

Metrics: Percentage of log sources with NTP configured (target: 100%); timestamp parsing error rate (target: <0.01%); clock skew monitored (target: all sources within ±1 second of NTP).

Common Pitfalls: Log sources not using NTP; local time emitted without timezone offset; timezone conversion applied inconsistently; millisecond precision lost during normalization.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 8.4 (Standardize Time Synchronization) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-8 (Time Stamps) - MITRE ATT&CK: T1070.006 (Timestomp — detection lens) - MITRE D3FEND: D3-NTA (Network Traffic Analysis)

Nexus SecOps-006: Log Retention Compliance¶

Rationale: Insufficient retention prevents investigation of incidents discovered late. Excessive retention without controls creates privacy and cost risk.

Implementation Guidance: Define retention tiers: hot (30–90 days, fast query), warm (90–365 days, slower), cold/archive (1–7 years, compliance). Automate lifecycle transitions. Document retention periods per log type in a retention schedule. Test restoration from archive quarterly.

Evidence to Collect: Retention policy document; storage configuration screenshots showing lifecycle rules; retention schedule by log type; evidence of compliance with regulatory minimums (e.g., 90 days for PCI DSS).

Tests/Validation: Verify that logs older than the hot tier boundary are accessible (warm) and logs older than warm boundary are accessible from archive. Confirm logs beyond retention period are deleted on schedule.

Metrics: Compliance with defined retention periods (target: 100%); archive restoration success rate (target: ≥99%); cost per GB per tier tracked.

Common Pitfalls: Single retention period for all log types; no archive testing; regulatory minimums not reviewed when regulations change; cold storage inaccessible during incidents.

Framework Mappings: - NIST CSF: PR.IP-04 (Backups of information conducted) - CIS v8: Control 8.3 (Ensure Adequate Audit Log Storage) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-11 (Audit Record Retention) - MITRE ATT&CK: T1070 (Indicator Removal — detection lens) - MITRE D3FEND: D3-DENCR (Data Encryption at Rest)

Nexus SecOps-007: Log Integrity Protection¶

Rationale: Adversaries frequently attempt to delete or modify logs to cover their tracks. Log integrity protection ensures evidence is trustworthy for investigations.

Implementation Guidance: Use write-once (WORM) storage for critical log archives. Implement hash chaining or cryptographic signing for audit logs. Ship logs to a secondary repository immediately upon collection. Alert on bulk log deletion events.

Evidence to Collect: WORM or immutable storage configuration; log signing implementation documentation; alert rule for bulk deletion; evidence of log delivery to secondary repository.

Tests/Validation: Attempt to modify a log entry and verify the modification is detected. Confirm that bulk deletion triggers an alert within SLA.

Metrics: Percentage of critical audit logs with integrity protection (target: 100%); time to detect log tampering (target: <15 minutes).

Common Pitfalls: Log integrity only applied to archives, not live logs; admin accounts can disable logging; secondary repository on same infrastructure as primary.

Framework Mappings: - NIST CSF: PR.DS-01 (Data-at-rest protected) - CIS v8: Control 8.5 (Collect Detailed Audit Logs) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-9 (Protection of Audit Information) - MITRE ATT&CK: T1070 (Indicator Removal) - MITRE D3FEND: D3-DENCR (Data Encryption)

Nexus SecOps-008: Cloud Log Collection¶

Rationale: Cloud control plane logs capture all administrative and API activity, which is essential for detecting unauthorized changes, privilege escalation, and data exfiltration in cloud environments.

Implementation Guidance: Enable cloud-native audit logging in all accounts/subscriptions. Use organization-level log aggregation to a central SIEM. Ensure multi-region coverage. Alert on logging being disabled.

Evidence to Collect: Cloud logging configuration screenshots; list of accounts/subscriptions with logging enabled; alert rule for logging disabled events; evidence of centralized aggregation.

Tests/Validation: Disable logging in a test account and verify alert fires. Perform an administrative action and confirm it appears in the SIEM within SLA.

Metrics: Cloud accounts with control plane logging enabled (target: 100%); time for cloud logs to appear in SIEM (target: <5 minutes); coverage of Tier 1 cloud workloads for data plane logs (target: ≥95%).

Common Pitfalls: New cloud accounts provisioned without enabling logging; multi-region logging gaps; data plane logs not collected due to cost; logs not forwarded to SIEM.

Framework Mappings: - NIST CSF: DE.CM-06 (External service provider activity monitored) - CIS v8: Control 8.2 (Collect Audit Logs) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-2, AU-12 (Event Logging) - MITRE ATT&CK: T1578 (Modify Cloud Compute Infrastructure — detection lens) - MITRE D3FEND: D3-NM (Network Mapping)

Nexus SecOps-009: Endpoint Telemetry¶

Rationale: Endpoints are primary targets for initial access and lateral movement. Rich endpoint telemetry enables detection of techniques that network logs cannot see.

Implementation Guidance: Deploy EDR agents to all managed workstations and servers. Validate coverage via deployment management tooling. Configure telemetry to include process trees, command lines, DNS queries, and authentication events. Forward EDR telemetry to SIEM.

Evidence to Collect: EDR deployment coverage report; telemetry field listing; evidence of SIEM integration; alert on EDR agent health failures.

Tests/Validation: Execute a known benign test process on an endpoint and confirm telemetry appears in SIEM within expected SLA. Verify command line arguments are captured.

Metrics: EDR coverage of managed endpoints (target: ≥99%); EDR agent health (online rate target: ≥98%); telemetry completeness (required fields present: target ≥99%).

Common Pitfalls: EDR not deployed on servers; coverage gaps in remote/OT environments; telemetry forwarding misconfigured; EDR exclusions too broad.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks and physical environment monitored) - CIS v8: Control 10 (Malware Defenses), Control 13 (Network Monitoring) - ISO 27001: A.8.7 (Protection against malware) - NIST 800-53: SI-3 (Malicious Code Protection), AU-2 (Event Logging) - MITRE ATT&CK: T1059 (Command and Scripting Interpreter — detection lens) - MITRE D3FEND: D3-PA (Process Analysis)

Nexus SecOps-010: Network Telemetry¶

Rationale: Network telemetry provides visibility into east-west traffic and connections that endpoint telemetry may miss, enabling detection of lateral movement, C2 beaconing, and data exfiltration.

Implementation Guidance: Configure NetFlow/IPFIX export on routers, switches, and firewalls. Deploy network sensors at perimeter, DMZ, and critical internal segments. Consider deep packet inspection metadata (not content) for high-value segments.

Evidence to Collect: Network flow collection configuration; sensor deployment map; evidence of data appearing in SIEM; list of monitored segments.

Tests/Validation: Generate known network traffic patterns and confirm they appear in flow data within expected SLA. Verify coverage of all defined critical segments.

Metrics: Network segments with flow collection (target: 100% of critical segments); flow data completeness (required fields present: target ≥99%); time for flows to appear in SIEM (target: <2 minutes).

Common Pitfalls: East-west traffic not monitored; only perimeter flows collected; encrypted traffic analysis not implemented; high-bandwidth segments dropped due to storage limits.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 13 (Network Monitoring and Defense) - ISO 27001: A.8.20 (Networks security) - NIST 800-53: AU-2 (Event Logging), SC-7 (Boundary Protection) - MITRE ATT&CK: T1071 (Application Layer Protocol — detection lens) - MITRE D3FEND: D3-NTA (Network Traffic Analysis)

Nexus SecOps-011: Identity and Authentication Telemetry¶

Rationale: Identity is the primary attack surface in modern environments. Authentication logs are essential for detecting credential attacks, account compromise, and privilege abuse.

Implementation Guidance: Collect logs from: Active Directory, Azure AD/Entra ID, Okta, AWS IAM, Google Workspace, PAM systems. Ensure both success and failure events are captured. Include MFA events, token issuance, and group membership changes.

Evidence to Collect: Identity provider logging configuration; list of identity sources feeding SIEM; sample of authentication events showing required fields; coverage of all identity providers.

Tests/Validation: Perform a failed authentication attempt and confirm the event appears in SIEM within SLA with all required fields. Verify MFA bypass attempts are captured.

Metrics: Identity provider coverage (target: 100%); authentication log volume per day (baseline and anomaly detection); required fields present (target: ≥99%).

Common Pitfalls: Legacy on-prem AD logs not forwarded; SaaS identity providers not integrated; privileged account activity missing; MFA events not captured.

Framework Mappings: - NIST CSF: DE.CM-03 (Personnel activity monitored) - CIS v8: Control 5 (Account Management) - ISO 27001: A.8.5 (Secure authentication) - NIST 800-53: AC-2 (Account Management), IA-2 (Identification and Authentication) - MITRE ATT&CK: T1110 (Brute Force — detection lens) - MITRE D3FEND: D3-UAA (User Account Analysis)

Nexus SecOps-012: Application and API Telemetry¶

Rationale: Application-layer attacks (OWASP Top 10, API abuse, data exfiltration) are not visible in network or endpoint logs alone. Application telemetry closes this detection gap.

Implementation Guidance: Work with application owners to define and implement security event logging. Use WAF logs, application event logs, and API gateway logs. Normalize events to common schema. Prioritize customer-facing and high-sensitivity applications.

Evidence to Collect: Application logging requirements document; list of critical applications with logging status; WAF integration configuration; sample application security events in SIEM.

Tests/Validation: Trigger an application-level security event (e.g., failed login to application) and verify it appears in SIEM with required fields.

Metrics: Critical applications with security logging enabled (target: ≥90%); application log completeness (required fields: target ≥95%).

Common Pitfalls: Application teams not engaged; WAF logs collected but not parsed; internal APIs excluded; error logs confused with security events.

Framework Mappings: - NIST CSF: DE.CM-09 (Computing hardware and software monitored) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-2, AU-12 (Audit Logging) - MITRE ATT&CK: T1190 (Exploit Public-Facing Application — detection lens) - MITRE D3FEND: D3-WAN (Web Application Auditing)

Nexus SecOps-013: Container and Kubernetes Telemetry¶

Rationale: Containers introduce unique attack surfaces including container escapes, privileged containers, and supply chain attacks. Standard endpoint telemetry does not cover these adequately.

Implementation Guidance: Enable Kubernetes API server audit logging. Deploy container runtime security tools. Collect events: pod creation/deletion, image pulls, privileged container starts, network policy changes, secrets access. Forward to SIEM.

Evidence to Collect: Kubernetes audit log configuration; container runtime security tool deployment; list of events captured; evidence of SIEM integration.

Tests/Validation: Start a privileged container and verify the event appears in SIEM. Modify a Kubernetes namespace and confirm the audit event is captured.

Metrics: Kubernetes clusters with audit logging (target: 100%); container workload coverage (target: ≥95%); required event types captured (target: ≥90%).

Common Pitfalls: Kubernetes audit logging not enabled (off by default); container telemetry sent to separate platform not integrated with SIEM; ephemeral container logs lost.

Framework Mappings: - NIST CSF: DE.CM-09 (Computing hardware monitored) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-2, AU-12 (Audit Logging) - MITRE ATT&CK: T1610 (Deploy Container — detection lens) - MITRE D3FEND: D3-PA (Process Analysis)

Nexus SecOps-014: Telemetry Health Monitoring¶

Rationale: Silent collection failures create undetected blind spots. Telemetry health monitoring ensures that detection coverage is continuously validated, not just assumed.

Implementation Guidance: Build a telemetry health dashboard showing: events per source per hour, parsing error rates, collection latency, and last-seen timestamps. Configure alerts for: source silent >30 minutes, error rate >5%, latency >10 minutes. Treat collection failures as Severity 2 incidents.

Evidence to Collect: Telemetry health dashboard screenshot; alert configuration for collection failures; records of collection failure incidents and resolution times.

Tests/Validation: Stop logging on a test source and verify alert fires within defined SLA. Review incident tickets for collection failure response times.

Metrics: Time to detect collection failure (target: <30 minutes for Tier 1 sources); collection failure alert false positive rate (target: <10%); collection SLA compliance (target: ≥99.5% uptime).

Common Pitfalls: Health monitoring only checks agent status, not actual log volume; no alerting on silent sources; collection failures not treated as security incidents.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 8.11 (Conduct Audit Log Reviews) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-5 (Response to Audit Logging Process Failures) - MITRE ATT&CK: T1562 (Impair Defenses — detection lens) - MITRE D3FEND: D3-NM (Network Mapping)

Nexus SecOps-015: OT/IoT Telemetry¶

Rationale: OT/IoT devices are increasingly targeted and often lack traditional endpoint security. Network-based telemetry provides visibility without risking operational disruption.

Implementation Guidance: Deploy passive network sensors in OT/IoT segments. Use protocol-aware monitoring for industrial protocols. Avoid active scanning in OT environments. Integrate with industrial security platforms where available.

Evidence to Collect: OT/IoT network sensor deployment map; list of monitored protocols; evidence of SIEM integration; documentation of safety constraints limiting collection.

Tests/Validation: Verify passive sensor data appears in SIEM without disrupting OT operations. Confirm industrial protocol events are correctly classified.

Metrics: OT/IoT segments with passive monitoring (target: ≥90% of critical segments); events appearing in SIEM within latency SLA.

Common Pitfalls: Active scanning deployed in OT environment causing disruption; OT systems treated as IT systems; no coordination with OT operations team.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 13 (Network Monitoring) - ISO 27001: A.8.20 (Networks security) - NIST 800-53: AU-2 (Event Logging) - MITRE ATT&CK: T0840 (Network Connection Enumeration — detection lens) - MITRE D3FEND: D3-NTA (Network Traffic Analysis)

Domain: DQN — Data Quality & Normalization (Nexus SecOps-016–030)¶

Nexus SecOps-016: Security Data Schema Standard¶

Rationale: A consistent schema enables cross-source correlation, reusable detection logic, and faster investigation. Without it, analysts waste time on data wrangling.

Implementation Guidance: Adopt an industry standard schema (OCSF, ECS, or CIM) or define a documented organizational schema. Create field mapping specifications for each log source. Enforce schema in the normalization pipeline.

Evidence to Collect: Schema documentation; field mapping specifications per log source; evidence of schema enforcement in pipeline; example normalized events showing required fields.

Tests/Validation: Query the SIEM for a specific normalized field across 5 different log sources and verify consistent data type and format.

Metrics: Percentage of log sources normalized to schema (target: ≥98%); required field completeness in normalized events (target: ≥99%); schema drift incidents per quarter (target: 0).

Common Pitfalls: Multiple competing schemas; schema not enforced—normalization is aspirational only; schema changes not communicated to detection engineers; legacy sources exempted indefinitely.

Framework Mappings: - NIST CSF: ID.AM-05 (Resources prioritized) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-3 (Content of Audit Records) - MITRE ATT&CK: Data quality lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-017: Enrichment Pipeline¶

Rationale: Raw events lack context. Enrichment transforms raw data into actionable intelligence, reducing analyst investigation time and improving decision accuracy.

Implementation Guidance: Build an enrichment pipeline that runs on all events before they reach the analyst queue. Use internal asset databases, LDAP/AD for user context, threat intel feeds for IOC matching, and GeoIP for geographic context. Track enrichment latency and failure rates.

Evidence to Collect: Enrichment pipeline architecture; list of enrichment sources and fields added; latency metrics; example enriched events showing context fields.

Tests/Validation: Submit a test event with a known IP address and verify enrichment fields (GeoIP, threat intel match, asset context) appear within expected latency.

Metrics: Enrichment coverage (events with all required enrichment fields: target ≥95%); enrichment latency (target: <500ms median); enrichment source freshness (threat intel feed updated: target ≤24 hours).

Common Pitfalls: Enrichment adds latency without benefit; enrichment data stale; enrichment applied only at query time, not at ingest; GeoIP database not updated.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 13 (Network Monitoring) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-3 (Content of Audit Records) - MITRE ATT&CK: T1071 (detection enrichment lens) - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-018: Data Quality Scoring¶

Rationale: Poor data quality is a hidden cause of missed detections and false positives. Making quality visible enables targeted improvement.

Implementation Guidance: Define quality metrics per field. Compute a quality score per log source (0–100). Surface scores in SIEM dashboards. Set thresholds that trigger quality alerts. Review quality trends monthly.

Evidence to Collect: Data quality scoring framework documentation; quality dashboard screenshot; quality alert configuration; monthly quality trend report.

Tests/Validation: Introduce a known quality issue (e.g., missing field) in a test log stream and verify quality score drops and alert fires.

Metrics: Average data quality score across all sources (target: ≥85/100); sources below quality threshold (target: 0); quality score trend (improving quarter over quarter).

Common Pitfalls: Quality scoring done manually during incidents only; quality scores not visible to detection engineers; quality issues remediated reactively.

Framework Mappings: - NIST CSF: ID.IM-01 (Improvements identified) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-3 (Content of Audit Records) - MITRE ATT&CK: Data quality lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-019: Deduplication and Event Correlation Preparation¶

Rationale: Duplicate events inflate storage costs, slow queries, and inflate alert counts. However, aggressive deduplication that suppresses real events creates detection gaps.

Implementation Guidance: Implement deduplication based on event fingerprinting (hash of key fields). Apply time-windowed deduplication (suppress exact duplicate within N minutes). Document deduplication logic. Monitor suppression rates. Exempt security-critical event types.

Evidence to Collect: Deduplication policy documentation; suppression rate metrics; list of event types exempt from deduplication; evidence that dedup does not suppress unique events.

Tests/Validation: Submit two identical test events 5 seconds apart and verify deduplication. Submit two similar but distinct events and verify both are stored.

Metrics: Deduplication rate per source (tracked for anomaly detection); storage cost reduction from deduplication; unique events accidentally suppressed (target: 0).

Common Pitfalls: Deduplication too aggressive—suppresses events that differ only in minor fields; deduplication rules not reviewed as log formats change; no monitoring of suppression rates.

Framework Mappings: - NIST CSF: PR.DS-01 (Data-at-rest protected) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-4 (Audit Log Storage Capacity) - MITRE ATT&CK: Data management lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-020: Data Lineage and Cataloging¶

Rationale: During investigations, analysts need to know where data came from, how it was transformed, and where to find it. Without lineage, investigation efficiency suffers.

Implementation Guidance: Document data flow from source to SIEM for each log type. Record transformations applied (parsing rules, enrichment, normalization). Make catalog searchable. Update catalog when pipelines change.

Evidence to Collect: Data catalog or data dictionary; lineage documentation for 5 critical log sources; evidence catalog is updated after pipeline changes.

Tests/Validation: Ask an analyst to find the source system for a specific event type using the catalog. Measure time to locate the information.

Metrics: Log source types with documented lineage (target: ≥90%); catalog search time (target: <2 minutes for common sources); catalog staleness (target: no entry unreviewed >6 months).

Common Pitfalls: Catalog exists but is not maintained; lineage documentation only for new sources; analysts unaware catalog exists; catalog in format inaccessible during incidents.

Framework Mappings: - NIST CSF: ID.AM-05 (Resources prioritized) - CIS v8: Control 1 (Asset Inventory) - ISO 27001: A.8.1 (Asset inventory) - NIST 800-53: CM-8 (System Component Inventory) - MITRE ATT&CK: Investigation support lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-021: Timeliness SLA for Log Delivery¶

Rationale: Detection is only as timely as log delivery. A 30-minute log delivery delay means a 30-minute minimum MTTD regardless of detection rule quality.

Implementation Guidance: Measure end-to-end log latency (event generation to searchable in SIEM). Define SLAs per tier. Alert when SLA is breached. Review latency metrics weekly.

Evidence to Collect: Latency measurement methodology; per-source latency dashboard; SLA definition document; alert configuration for latency breaches; sample SLA compliance report.

Tests/Validation: Generate a test event on a source system and measure time until it is searchable in SIEM. Compare against defined SLA.

Metrics: Percentage of Tier 1 sources meeting ≤5 minute SLA (target: ≥99%); median log delivery latency per tier; latency SLA breach frequency (target: <1 per month per source).

Common Pitfalls: Latency measured from collection agent, not source event time; batch delivery intervals create latency spikes; network congestion not accounted for; SLA not defined per tier.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.15 (Logging) - NIST 800-53: AU-5 (Response to Audit Logging Failures) - MITRE ATT&CK: Detection timeliness lens - MITRE D3FEND: D3-NTA (Network Traffic Analysis)

Nexus SecOps-022 through Nexus SecOps-030: Additional DQN Controls¶

Domain: DET — Detection Engineering & Content Ops (Nexus SecOps-031–050)¶

Nexus SecOps-031: Detection Content Lifecycle Management¶

Rationale: Detection rules that are not managed deteriorate over time — they generate false positives, miss evolved threats, or become irrelevant. A lifecycle process keeps detection content effective.

Implementation Guidance: Define lifecycle stages and gate criteria for each. Use a ticketing system or detection management platform to track each rule through its lifecycle. Require sign-off before production deployment. Schedule regular rule reviews.

Evidence to Collect: Detection content lifecycle policy; workflow screenshots showing rules in different stages; gate criteria documentation; evidence of sign-off before deployment.

Tests/Validation: Pull a random sample of 10 production detection rules and verify each has lifecycle documentation, last review date, and owner.

Metrics: Detection rules with documented lifecycle stage (target: 100%); rules with review overdue >90 days (target: 0); detection content churn rate (rules retired/deployed per quarter tracked).

Common Pitfalls: Rules deployed and never reviewed; no retirement process; lifecycle exists on paper but not enforced; ownership not assigned.

Framework Mappings: - NIST CSF: DE.CM-01 (Networks monitored) - CIS v8: Control 8 (Audit Log Management) - ISO 27001: A.8.8 (Management of technical vulnerabilities) - NIST 800-53: SI-3 (Malicious Code Protection), CA-7 (Continuous Monitoring) - MITRE ATT&CK: Detection engineering lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-032: Detection-as-Code Standards¶

Rationale: Treating detection rules as code enables version control, peer review, automated testing, and rollback — the same benefits software engineering gained from version control.

Implementation Guidance: Store all detection rules in git. Use a structured format (Sigma, YARA, or platform-native with documented schema). Require pull request review before merging. Tag rules with metadata: author, ATT&CK technique, log sources required, last tested date.

Evidence to Collect: Git repository showing detection rules; pull request workflow; rule metadata schema; example rule with full metadata.

Tests/Validation: Review the git history for 5 recently changed rules. Verify each has a PR, reviewer, and commit message explaining the change.

Metrics: Detection rules in version control (target: 100%); rules with complete metadata (target: ≥95%); average PR review time (target: <24 hours); rules deployed without PR review (target: 0).

Common Pitfalls: Version control adopted but reviews bypassed; metadata fields empty; no enforcement of format standards; detection platform and git repo drift.

Framework Mappings: - NIST CSF: PR.IP-01 (Baseline configuration) - CIS v8: Control 4 (Secure Configuration) - ISO 27001: A.8.9 (Configuration management) - NIST 800-53: CM-3 (Configuration Change Control) - MITRE ATT&CK: Detection engineering lens - MITRE D3FEND: D3-DA (Data Analysis)

Nexus SecOps-033 through Nexus SecOps-050: Additional DET Controls¶

Domain: TRI — Triage & Investigation (Nexus SecOps-051–065)¶

Domain: INC — Incident Response (Nexus SecOps-066–080)¶

Domain: CTI — Threat Intelligence (Nexus SecOps-081–095)¶

Domain: AUT — SOAR & Automation Safety (Nexus SecOps-096–110)¶

Domain: IAM — Identity & Access Signals (Nexus SecOps-111–120)¶

Domain: CLD — Cloud Security Operations (Nexus SecOps-121–135)¶

Domain: END — Endpoint & Network Operations (Nexus SecOps-136–150)¶

Domain: VUL — Vulnerability/Exposure Signal Integration (Nexus SecOps-151–160)¶

Domain: AIM — AI/ML Model Risk Management (Nexus SecOps-161–180)¶

Domain: LLM — LLM Copilots & Guardrails (Nexus SecOps-181–200)¶

Domain: GOV — Governance, Training & Resilience (Nexus SecOps-201–220)¶