Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Security Event Detection and Monitoring Methods
Time is damage
Attackers often spend days or weeks inside a network before they act. Every hour they go unnoticed, they reach more systems and data. Detection shortens that window. One CISM task is to develop and implement processes to ensure the timely identification of information security incidents.
Where detections come from
| Source | What it catches |
|---|---|
| SIEM correlation | Patterns across many log sources |
| EDR and NDR | Malicious behaviour on hosts and in network traffic |
| Cloud and identity alerts | Risky sign-ins, misconfiguration, API abuse |
| User reports | Phishing, odd behaviour, lost devices |
| Threat intelligence | Known indicators, sector warnings |
| Third parties | Suppliers, customers, researchers, law enforcement |
Many incidents are first spotted by people, so reporting must be easy. Learning about a breach from an outsider is a sign that detection is weak.
Signature vs behaviour
- Signature-based detection matches known patterns. Accurate for known threats, blind to new ones.
- Behaviour and anomaly-based detection flags deviations from normal. It can catch new attacks, but produces more false positives and needs a clean baseline.
Most programs use both.
Making detection effective
- Coverage: critical systems, identity services and cloud platforms send the right logs.
- Use cases: detections mapped to likely attacker techniques, for example using MITRE ATT&CK.
- Tuning: reduce false positives, which otherwise cause alert fatigue and missed real attacks.
- Testing: simulate attacks (purple teaming) to check detections actually fire.
Example. A purple-team exercise runs ten common attacker techniques. Only four trigger alerts; the other six reveal missing logs from domain controllers and cloud consoles. Fixing coverage raises detection to nine out of ten at the next exercise.
Measuring detection
- mean time to detect (MTTD)
- % of critical assets sending logs
- coverage of priority ATT&CK techniques
- false-positive rate
- how incidents were first detected: internally or by outsiders
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Main goal of security monitoring | Timely identification of incidents |
| Detection method that can find new attacks | Behaviour- or anomaly-based detection |
| Effect of too many false positives | Alert fatigue; real alerts missed |
| Key detection metric | Mean time to detect |
| Breaches are mostly reported by outsiders | Detection capability is weak |
In short
- Developing and implementing processes for timely identification of incidents is a CISM task; the faster an incident is found, the less damage it does.
- Detection sources include SIEM correlation, EDR and network detection, cloud and identity alerts, user reports, threat intelligence and third parties.
- Signature-based detection catches known threats; behaviour and anomaly detection can catch new ones but produce more false positives.
- Coverage matters: critical systems, identities and cloud services must send the right logs.
- Tuning reduces false positives, which otherwise cause alert fatigue and missed real attacks.
- Key metric: mean time to detect (MTTD), along with detection coverage and the source of first detection.
Exam traps
- Logs that aren't collected or reviewed detect nothing.
- Too many false positives lead to real alerts being ignored.
- Learning about a breach from a third party is a sign detection is weak.
- Signature-based tools alone miss new attacks.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Where detections come from
Signature vs behaviour
1 / 9