1.2.2. Incidents, Entities, and Classification
💡 First Principle: Attacks are sequences, not single events, so the unit of response must be the sequence. Correlation engines group alerts that share entities (the same user, device, or IP), fall close together in time, and fit a plausible attack progression. The resulting incident is the case file you work, and how you close it (its classification) teaches the platform what to tune.
An entity is any object that alerts can be about: user accounts, devices, IP addresses, files, processes, mailboxes, URLs, cloud applications, and Azure resources. Entities are the glue of correlation and the starting point of investigation. When you click an entity, you pivot to everything the platform knows about it, across every alert and data source. Detection rules you author must map entities from their query results (2.5), or the correlation engine has nothing to stitch together.
An incident groups related alerts, their entities, and supporting evidence into one story with its own severity, status (Active, In progress, Resolved), owner, tags, and comments. You manage work at this level: assign an incident to an analyst, track response tasks, and resolve it with a classification.
Classification is not just paperwork. It is feedback that drives tuning:
| Classification | Meaning | Typical follow-up |
|---|---|---|
| True positive | Real malicious or unauthorized activity | Contain, remediate, record determination (for example, phishing, malware, compromised account) |
| Informational, expected activity | Detection fired correctly on real but authorized activity (a "benign positive", such as a sanctioned penetration test or admin script) | Consider a narrow tuning rule or exclusion for that known activity |
| False positive | Detection logic fired on activity that doesn't match its intent | Fix or tune the detection logic itself |
The difference between the last two rows matters on the exam. A benign positive means the rule worked and the activity was approved; a false positive means the rule was wrong. They lead to different fixes.
⚠️ Exam Trap: "The security team's scheduled red-team exercise triggered alerts. How should you classify the incident?" The answer is Informational, expected activity, not False positive. The detection correctly identified attack-like behavior; the behavior was simply authorized.
Reflection Question: Two alerts fire an hour apart: a suspicious sign-in for user Dana from an unfamiliar country, and a malicious PowerShell command on Dana's laptop. What shared entity lets a correlation engine join them into one incident, and why is that more useful to an analyst than two separate queue items?
