Correlation and Anomaly Detection
🌟 Objective
Apply event correlation and anomaly detection techniques to identify behaviour patterns which, although harmless in isolation, may indicate significant risk when analysed together.
🎯 Objectives of applying correlation
- Detect suspicious behaviour emerging from discrete patterns
- Reduce false positives through cross-referenced context
- Prioritise real incidents on the basis of multiple pieces of evidence
- Support proactive and adaptive detection
🥁 Types of correlation
| Type | Practical example |
|---|
| Temporal | Suspicious actions within a short interval |
| Contextual | Out-of-hours login + unusual IP |
| Behavioural | Deviation from the user's pattern |
| Cross-source | Event in the app followed by firewall or SIEM |
| Session / flow | Events with the same trace.id or session token |
🛠️ Supporting techniques and tools
| Technique | Application / example |
|---|
| Rules in the SIEM | Splunk, Sentinel, QRadar |
| Chaining / graphs | Identity and session graphs |
| Baseline models | Deviations by IP, endpoint, time |
| Composite threshold | Multiple accumulated conditions |
| Aggregate score | Score per user, device or application |
⚠️ Rule-based correlation is the best starting point for most organisations.
🧠 Examples of correlated patterns
| Pattern identified | Interpretation |
|---|
| Login + massive download | Credential abuse |
| Repeated failures + success | Successful brute force |
| Role change + config change | Privilege escalation |
| API key + out-of-hours access | Misuse |
| Commit + atypical CI/CD execution | Compromise in the chain |
🪧 Good practices
- Normalise events before correlation (formats, fields)
- Use limited time windows (e.g. 5m, 15m)
- Correct false negatives with new correlation factors
- Use persistent IDs:
user.id, session.id, trace.id
- Assess the severity of the set, not of the isolated events
📊 Behaviour-based detection
| Technique | Purpose |
|---|
| Baseline per user | Individual deviations (time, volume, endpoint) |
| Profile per role | Actions not expected for a given profile |
| Aggregated metrics | API calls, latency, variation in the pattern |
| Supervised feedback | Reinforcement of rules based on real cases |
💡 Requires progressive tuning and the active participation of the teams.
| Document | Relation to this topic |
|---|
02-logging-centralizado.md | Source of the events for correlation |
04-integracao-siem.md | Channel and format of ingestion |
03-alertas-eventos-criticos.md | Pattern-based alert generation |
09-ameacas-mitigadas.md | Maps detection to threat scenarios (OSC&R) |
✅ Final recommendations
- Start with simple correlation, based on high-impact events
- Test with real data, simulated data and old logs
- Track quality metrics (signal/noise, triage time)
- Evolve towards scoring, dynamic baseline and assisted detection
🌟 Effective correlation reduces false positives and reveals complex patterns that would otherwise go unnoticed.