× 
Logging & alerting
Logging and alerting determine what the team can see and how fast it finds out. Coverage decides what gets recorded, retention decides for how long, and detection and alerting decide whether anyone is told in time.
Detection can only work on systems that send logs. These controls require that critical systems be identified, onboarded to centralized logging, and prioritized by risk.
Critical systems are identified and onboarded to centralized logging, including endpoints, network devices, identity systems, cloud platforms, applications, and security tooling.
New systems are evaluated for logging requirements before production.
Log sources are prioritized by risk and criticality.
Investigations often examine events months after they happened. Logs have to arrive centrally in near real time, resist tampering in transit and at rest, and be retained long enough to cover that window.
Logs are centrally collected in near real time.
Log integrity is protected through encryption in transit.
Log integrity is protected through access controls.
Retention periods meet regulatory requirements.
Retention periods meet business requirements.
Different systems emit logs with different field names, timestamp formats, and identifiers. Normalization to a shared schema makes cross-system analysis possible, and enrichment adds the asset and identity context an analyst needs.
Ingested logs are normalized to a standard schema for consistent analysis.
Logs are enriched with context such as asset criticality, user identity, and threat intelligence indicators.
Parsing rules are reviewed periodically.
Detection rules encode the specific behaviors the team has decided to catch. Untuned rules bury real alerts under false positives, so the controls cover tuning and change management as well as the rules themselves.
Detection rules are implemented for defined use cases, each with a severity tier.
Rules are tuned regularly to manage false positive and false negative rates.
Changes to detection rules follow change management procedures.
After a rule fires, the alerting pipeline runs automated triage, creates a ticket, notifies the response team, and pages for high-severity events. Escalation procedures cover the case where the first responder does not answer.
Alerts route through a defined pipeline that begins with automated triage.
The pipeline creates tickets.
The pipeline notifies response teams.
High and critical severity alerts trigger immediate paging.
Escalation procedures and response time SLAs are documented.