Triage: context before verdict

Triage is deciding what an alert is and what should happen next. The four outcomes you will hear most are true positive (the alert fired and something bad really happened), false positive (it fired but nothing bad happened), benign true positive (it fired correctly on real activity that turned out to be allowed, like an admin running a scan) and, the one you never see in the queue, false negative (something bad happened and nothing fired).

The most common mistake in the first month is choosing a verdict too early. The alert title says "possible credential theft", you open it already believing it, and every fact after that gets read in that light. Or the opposite: this rule fires a hundred times a day, so it must be noise again.

Gather context first

1. Who. Which user or service account? What is their role? Are they new, leaving, or travelling?
2. What. What exactly did the detection see? Read the raw event, not just the alert title.
3. Where. Which host or cloud resource? Is it a server, a laptop, a build agent?
4. When. At what time, and what happened just before and just after on the same host or account?
5. Is this normal? Has this user or host done the same thing before? Search the last 30 days.

Only then decide. Often the context makes the decision for you. A PowerShell download on a developer machine at 2pm with a ticket open for a tooling install is a different alert from the same command on a finance laptop at 3am.

Speaking the same language

Many teams tag alerts with MITRE ATT&CK tactics and techniques. A tactic is the attacker's goal at that step, such as Initial Access or Lateral Movement. When the source was read for this book, the Enterprise matrix listed 15 tactics, including Stealth and Defense Impairment. Check the version your team uses, because ATT&CK changes over time.

Rule of thumb:Rule of thumb: write your verdict last. If you notice you wrote it first, go back and check one thing that could prove it wrong.