Triage and investigation
An alert queue never ends, and most alerts are not attacks. This lesson gives you a repeatable way to work one alert at a time: read its intent, gather context around the people and machines it names, build a short timeline, reach a verdict you can defend, and hand a real incident to the next tier with the evidence they need. The goal is to answer three questions fast and the same way every time: is this real, how bad is it, and what happens next.
By the end you can
- Run the same triage loop on every alert, from reading the rule's intent to recording why you closed it
- Enrich an alert with asset, identity, reputation, geo and history, and pivot from one indicator to related activity
- Give an alert a verdict (true positive, false positive, benign true positive, or escalate) and a severity based on asset value and blast radius, not the rule's default
- Escalate to Tier 2 with an evidence bundle so they do not start over, and turn a false positive into a tuning ticket
- Name the traps that make analysts close the wrong alert: confirmation bias, alert fatigue, tunnel vision
The everyday picture
Picture the security desk in a large building at night. Sensors send a steady stream of signals: a fire door opened, motion in a stockroom, a badge used on the wrong floor. The guard cannot send a patrol to every one, and most are harmless: a cleaner, a late worker, a cat. So the guard works each signal the same way. What tripped, and what is that sensor meant to catch? Who is nearby right now, from the badge log and the camera? Is this normal for this hour and this door? Only then does the guard decide: ignore it, note it, or call for help. And when they call, they do not say "something happened on floor three". They say what, where, when, and what they already checked, so the responding team moves straight to the problem.
Alert triage is that desk. Each alert is a tripped sensor. Your job is not to stop the signals or to investigate every one to the end. It is to gather just enough context to decide, consistently, and to pass on the few that are real with everything the next person needs. The signals that look identical on the screen often mean very different things once you know who and what they touch, and that difference is the whole job.
One loop for every alert
Triage works because it is a fixed loop, not a fresh puzzle each time. You built the rules that raise these alerts in Writing detections, and you know which logs to query from Logs that matter. Triage is what you do when one of those rules fires. The loop has five steps, and you run all five even when an alert looks obvious:
- Read the alert and its rule's intent. What did the rule try to catch, and what would a true match look like? A rule named "impossible travel" is looking for one account used from two places too far apart to travel between in the time that passed. If you do not know a rule's intent, you cannot tell a hit from noise.
- Gather context around the entity. Every alert names things: a user, a host, an IP address, a time. Pull the facts about each one before you judge. This is enrichment, and it is the next section.
- Build a mini timeline. Put the events in order with timestamps in one time zone (UTC is safest). A list of log lines sorted by time tells a story that the same lines scattered across tools never do.
- Decide a verdict. One of four: true positive, false positive, benign true positive, or escalate. More on these below.
- Record why. Write the one or two facts that decided it, with the log lines or query behind them. A closed alert with no reason cannot be audited, learned from, or reopened.
A useful shorthand for the context step is the five Ws, borrowed from journalism: who is the account or person, what did they do (the action the log shows), where did it come from (host, IP, location), when did it happen (and what came just before and after), and why did the rule fire. If you can answer all five from evidence, you can almost always reach a verdict. If you cannot, you know exactly what to go and find.
Quick check
A "new country sign-in" alert fires on a staff account. You open it and immediately write "FP, user travels" and close it. What is the main problem with this?
The verdict may even be right, but you guessed it. Triage means gathering context first (does the identity directory show approved travel, does the device match, is the login time normal) and recording the fact that decided it. Closing on a hunch with no note is how real sign-ins get missed and how the next analyst repeats your work. Whether to close or escalate, and the exact verdict word, both come after the context, not before.