0.1 Incident Triage and the First Hour

Introduction

Incident triage is the work of deciding, quickly and from incomplete evidence, what an alert or incident actually is and what must happen next. It sits between detection, which raises alerts, and investigation, which works out everything that happened. Its product is a small set of decisions made in the first hour: whether the thing is real, how far it reaches, how bad it is, what stops it now, and who needs to know. This course teaches those decisions one at a time, each in its own module, against a month of records from Northgate Engineering, a fictional 810-person company whose security team faces the volume every real team does. This first sub sets out the five decisions, shows the volume they are made against, narrows a month of Northgate's alerts to the one incident that most needs a decision, and explains why the order a queue presents is rarely the order that matters. By the end you'll be able to say what triage decides, and where to start on a queue you have never seen.

Every incident that reaches a security team eventually gets investigated, contained and closed by someone. Triage is the part that comes first, and it is defined by what it decides rather than by how long it takes. An hour is the usual budget for the first pass on a serious incident, and much less for a routine one, but the decisions are the same either way. Five questions make up the decision, and they are answered in roughly this order:

Each question narrows the one after it, which is why the order matters. An alert that is not real needs no scope; an incident with a small scope and no live activity needs no emergency containment; an incident that scores low needs no call to the CISO. A triage that answers them out of order wastes its hour: scoping an alert nobody has validated, or containing something before anyone knows how far it reaches.

The questions are also answered at different speeds. Whether an alert is real can often be settled in minutes from a handful of records; how far it reaches may take the rest of the hour; who needs to know depends on both. A triage plans its hour around that, starting the slow questions early and closing the fast ones as it goes, so that nothing waits on something that did not need to wait.

The answers also carry their confidence, and saying so is part of the answer. Triage works from what the records show at the time, and the records are nearly always incomplete in the first hour: a sensor that saw little, a log that has not arrived, a question nobody can answer yet. Good triage does not wait for completeness. It states what is established, what is inferred and what is still unknown, and makes the decision the evidence supports, as Module 10 sets out for the report.

What triage does not do, by design, is finish the job. Working out everything the attacker did, how they got in, and what to change so it does not happen again is investigation and remediation, and they come after. The line between the two is the subject of the next sub.

The five questions are also the shape of this course. Each has at least one module of its own, and every incident-type module from 5 to 8 answers all five for one kind of attack. By the end, asking them in order is a habit rather than a checklist. The habit is what matters under pressure, when there is no time to consult anything and the first question asked is the one that sets the hour.

Triage exists because there are more alerts than anyone can investigate. The month's records at Northgate show how many:

SecurityAlert
// the month's alerts: how many, how many High, over how many days
| summarize Alerts = count(), High = countif(AlertSeverity == "High"),
    Days = dcount(bin(TimeGenerated, 1d))

sourcetype="ms365:defender:incident:alerts"
| where isnull(EntityType) OR EntityType=""
| eval High=if(AlertSeverity="High", 1, 0)
| eval Day=strftime(_time, "%Y-%m-%d")
| stats count as Alerts, sum(High) as High, dc(Day) as Days

One row. 537 alerts over 31 days, from 13 February to the morning of 15 March, 30 of them rated High by the tool that raised them. That is about seventeen a day, most of them Low or Medium, for a team whose Level 1 analysts also handle everything else a security team does.

Where they came from, and which tools raised the serious ones, matters as much as how many there were:

SecurityAlert
// which tools raised them
| summarize Alerts = count(), High = countif(AlertSeverity == "High") by ProductName
| order by Alerts desc

sourcetype="ms365:defender:incident:alerts"
| eval High=if(AlertSeverity="High", 1, 0)
| stats count as Alerts, sum(High) as High by ProductName
| sort - Alerts

Seven rows, one per tool. The cloud app security product raised 371 of the alerts, the identity risk engine 132, Defender for Identity 22, the endpoint product 7, and the SIEM, email security and XDR correlation a handful between them. The loudest tool is not the one with the most serious alerts: Defender for Identity raised 22 alerts, 17 of them High, while the cloud app product raised 371, one of them High. A queue sorted by volume puts attention where the noise is.

This shape is ordinary, and nothing about it is peculiar to Northgate. Every security team's alert volume is shaped the same way: a few tools produce most of the alerts, a few alerts carry most of the risk, and the two groups barely overlap. Triage is the discipline of finding the second group inside the first, fast, on every shift.

The numbers also set expectations for the rest of the course. Seventeen alerts a day is not overwhelming for a team that triages well, and it is impossible for a team that investigates everything. The difference is the five questions: asked quickly of every alert, they dismiss most in minutes and pick out the few that need the whole first hour.

The tools' own severity is part of the problem. The 30 High alerts are the tools' view, and some of the month's most serious activity arrived rated Medium or Low, as Section 11.3 shows for a mailbox rule on a compromised account. A triage that reads only the Highs misses those; a triage that reads everything never finishes. The course's answer is the scorecard of Module 4, which rates incidents on what they touched rather than on the label the tool gave them.

It also explains why the course keeps returning to the records rather than to the alerts. An alert is a tool's claim about something it matched. The records behind it, the sign-ins, processes, connections and audit entries, are what triage reads to decide whether the claim is true and what it means.

Alerts become incidents, incidents are either worked or left to wait, and at any moment a queue holds some mix of them. At noon on 15 March, Northgate's queue looks like this:

SecurityIncident
// the queue at noon on 15 March: open incidents by severity, and who holds them
| where Status != "Closed"
| summarize Open = count(),
    Unowned = countif(isempty(tostring(parse_json(Owner).assignedTo)))
    by Severity

sourcetype="ms365:defender:incident" Status!="Closed"
| rex field=Owner "assignedTo\":\"(?<AssignedTo>[^\"]*)"
| eval Unowned=if(isnull(AssignedTo) OR AssignedTo="", 1, 0)
| stats count as Open, sum(Unowned) as Unowned by Severity

Three rows. 45 incidents are open: 25 Low and 18 Medium, all owned by Level 1 analysts, and 2 High, one of which has no owner at all.

The ownership column is the one to read first. An owner is a promise that someone is working the incident; an incident without one is waiting for nobody in particular, and the longer it waits the less likely anyone is to notice. Forty-three incidents with owners and two Highs, one of them unowned, is not a queue in trouble on volume. It is a queue in trouble on attention, which is the more common kind and the harder one to see from a dashboard that reports totals.

The severity labels deserve the same care. They are the tools' ratings, set when each incident was raised, and Module 4 shows how often the scorecard moves an incident up or down once its scope is known. A Medium can turn out to be Critical. But at noon, with 45 incidents open, the labels and the ownership are what the analyst has, and they are enough to choose where the first hour goes. The month narrows quickly once it is sorted by what matters:

Each step is a filter anyone can run on any queue, and the last one leaves a single incident. It is a High, it has sat in the queue for 22 hours, and nobody has promised to work it. That is the incident triage exists to find.

The funnel is not a special report. It is four questions any analyst can ask of any queue in a minute: how many, how many open, how many serious, how many with nobody on them. The first answer is usually large and the last is usually small, and the value of asking in that order is that the small answer is found before the hour is spent on the large one.

The two open Highs, read in full from the incident records:

SecurityIncident
// the two open Highs, in full
| where Status != "Closed" and Severity == "High"
| project IncidentNumber, Title, Status, CreatedTime,
    Owner = tostring(parse_json(Owner).assignedTo)

sourcetype="ms365:defender:incident" Status!="Closed" Severity="High"
| rex field=Owner "assignedTo\":\"(?<AssignedTo>[^\"]*)"
| table IncidentNumber, Title, Status, CreatedTime, AssignedTo

Two rows, and they are two very different incidents. An Active Directory domain compromise, raised at 05:30 on 14 March and held by a Level 1 analyst, and a multi-stage intrusion from the network edge into the cloud, raised at 13:41 on 14 March and owned by nobody. Module 12, the capstone, is that second incident, triaged from the moment someone finally opens it.

Once an incident is chosen, the first hour runs through a sequence of decisions that the course then teaches, one module at a time:

The order is not rigid, and the course never treats it as a script to follow line by line. Preservation often runs alongside validation, because the evidence most at risk is lost while anyone waits; scope and scoring feed each other, since a wider scope raises the score. But the dependencies are real. Containment ordered before scope closes the routes the triage knows about and leaves the rest; a report written before the score has no severity to carry.

The first hour is also the right frame for the course because of what the organization is up against during it. Some attacks finish their damage inside it: Module 11 measures ransomware that encrypted its first file eight minutes after its alert, and an intrusion that finished taking files forty-six minutes after its alert. Others move slowly and do their harm over weeks, and for those the first hour decides whether anyone notices at all.

The sequence also explains what each module assumes. Module 3 assumes the alert has been validated, because scoping a false positive is wasted effort; Module 9 assumes a scope and a score, because containment without them closes some routes and misses others. A reader who starts in the middle can still follow each module, but will see these assumptions stated rather than built.

The queue's other High shows why escalation has a module of its own. It is owned, and by a Level 1 analyst, which looks like attention and is not quite enough: a domain compromise needs decisions a Level 1 analyst cannot make, such as resetting the domain's most privileged accounts or isolating a domain controller. Module 10 takes that problem up as escalation. For the first hour, it is enough to notice that an owner on the wrong rung is only partly an owner.

The modules after 10 carry the method further. Module 11 is about the automation and AI that now sit between the analyst and the records, and how to check what they hand over. Module 12 runs the whole first hour on one incident, from the unopened alert to the report.

A student can start anywhere in the course, and many will. The modules build on one another and are written so that each is useful on its own, but the order above is the order a real incident follows, and it is the order the course recommends for a first read.

Triage makes decisions on partial evidence, and it stops when its decisions are made and handed on. It does not reconstruct the full attack, collect every artifact, identify the attacker or fix the control that failed. It makes sure those things can happen afterwards, by preserving what they will need and handing it on in order. Those are investigation, forensics and remediation, and they need time the first hour does not have.

The line matters most at the start of a shift, when the queue's own layout invites the opposite. An analyst who opens the oldest incident and starts investigating it thoroughly is doing good work on the wrong thing, while the incident that most needs a decision waits:

Working the queue oldest first.
Next: incident raised 13 Feb, Low.

Two open Highs first; one has no owner.
Then the rest, by severity.

The right-hand version is what the lead's question asks for. It does not mean the Low incidents are unimportant; each will be triaged in turn, and some may turn out to be more serious than their labels. It means the order is set by what an incident could cost if it waits, which is what severity and ownership show and age does not.

The same discipline applies inside a single incident once it is chosen. Triage answers the five questions to the level a decision needs and then hands on, rather than chasing every thread to its end. A triage that becomes an investigation delays the containment and escalation the organization needed from it, however good the investigation turns out to be.

The opposite failure is quieter and just as costly: a triage that stops too soon. Closing an incident as benign because the first record looked ordinary, or tiering it on the tool's label without checking what it touched, saves minutes and can cost weeks. Module 12's incident sat for a day because nobody asked the first question of it, and Section 11.3 shows a queue suggesting that an alert be closed on a tool's verdict while the account behind it was in an attacker's hands.

Knowing where to stop is a skill in its own right. The test the course uses is whether the next decision needs more evidence than the triage can get in the time it has. If it does, the question goes on the report's list of open questions with an owner, and the triage moves on. If it does not, the triage answers it and moves on. Either way, the hour keeps moving.

That is also why this course has a separate module on handoff, and why its report is one page. The next sub draws the line between triage and incident response precisely, and shows what crosses it.

The analyst reading from the top has made the most common first-hour mistake, and it is easy to see why: the queue presents incidents in the order they arrived, and reading them in that order feels thorough. Read the queue as it stands and make the first call:

The call is to take the unowned High first. Open it, check whether it is still active, and put an owner on it; then confirm the other High is held by someone who can make its decisions, since a Level 1 analyst cannot authorize most of what a domain compromise needs; then work the rest by severity. Each step is written on the incidents with the time, so the next shift inherits the order rather than rediscovering it.

The call takes a few minutes of the analyst's hour and costs the Low incidents nothing: they are still owned, still in the queue, and will be triaged in turn. What it changes is where the next hour goes, which is the only resource a triage has too little of.

The same reading works on any queue, however large. A team with five hundred open incidents runs the same four filters and finds the same kind of answer at the bottom: a handful of serious incidents, some of them with nobody on them. The numbers change; the order of the questions does not.

That call, made at noon on 15 March, is where the capstone begins. The unowned High turns out to be an intrusion that ran from a public web server to an application able to read every mailbox in the organization, and that was still signing in overnight while the incident waited. Nothing about it looked urgent from the top of the queue.

The steps fit a card for the start of any shift:

The fourth row is the one this whole sub is about, and the one most often skipped. Every later module assumes the analyst has already chosen the right incident; this is where that choice is made.

Practice

Start with your own queue, or with any real queue you are able to read.

If step two finds anything, it is the first thing to work, whatever else the queue shows.

Section 0.2 draws the line between triage and incident response, and shows what crosses it.