0.6 Triage Tools: Scorecard, Query Pack and Triage Report

Introduction

A triage instrument is a fixed method an analyst applies the same way every time, so that the decision it produces does not depend on who is on shift or how tired they are. This course is built around three of its own: the five-query pack, which answers the first questions about any alert; the scorecard, which turns evidence into a severity and a priority tier; and the Triage Report, which carries the decisions to the people who act on them. Two collection tools complete the set: Defender Live Response for a single device, and Velociraptor for many. This sub introduces each, shows it working on Northgate's records, sets out which decision it feeds, and notes the limits and licenses that decide when each can be used. One widely used collector, KAPE, is deliberately left out, for a licensing reason that matters to most of this course's students. By the end you'll know which instrument to reach for at each point in a triage, and where in the course each is taught in full.

The course has five instruments in all, and each feeds particular decisions:

The three methods are the course's own, written for it and refined across its twelve modules. They are signatures in the sense that the course teaches them in one module and then uses them in every module after: the pack opens every incident module, the scorecard closes each one, and the report is the product every Practice card points toward. A student who takes nothing else from the course takes these three, and they are what the course's project asks each student to rebuild for their own organization.

The two collectors are other people's tools, chosen because they are what working analysts use and because every student can use them in paid work, which is not true of every popular collector. Live Response is part of Defender for Endpoint, so any organization with that product has it; Velociraptor is open source and widely deployed for collection at scale. The course teaches them where collection is the decision: Module 2 for preservation, Module 7 for malware and Module 9 for containment.

The five share a single design principle, whatever their other differences may be: each can be applied the same way by any analyst, at any hour, and produce a result someone else can check. That is what separates an instrument from a habit. An experienced analyst's instincts are valuable and hard to review; an instrument's output can be read, compared and corrected, which is what a team, a review or a regulator needs.

How the instruments connect to the decisions is worth seeing at once:

The map reads left to right. The pack and the collectors feed the early decisions: whether an alert is real, what must be preserved and how far it reaches. The scorecard feeds severity. The report carries everything onward. No instrument makes a decision by itself; each produces the evidence or the structure a decision is made from, and the decision is the analyst's.

The instruments also travel well beyond this course and its fictional company. None of them depends on Northgate or on a particular product: the pack's five questions are asked in whatever query language a SIEM uses, the card's anchors are rewritten for any estate, and the report's ten lines suit any escalation path. The project at the end of the course asks each student to build their own version of all three, for their own organization.

The pack, taught in Section 1.4, is five questions asked of every alert before anything else is done with it: who is the account or host, where did the activity come from, what did it touch, when did it start and stop, and is it still happening. Each question is one query, and the five together take a few minutes. The first question, on the account at the center of the phishing compromise:

IdentityInfo
// question 1 of the pack, who: the account's job, department and directory roles
| where AccountUPN == "c.richardson@ne.com"
| summarize by AccountUPN, JobTitle, Department, AssignedRoles

| inputlookup identity_info.csv
| search AccountUPN="c.richardson@ne.com"
| table AccountUPN, JobTitle, Department, AssignedRoles

Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"
$upn = "c.richardson@ne.com"
Get-MgUser -UserId $upn -Property UserPrincipalName, JobTitle, Department |
    Select-Object UserPrincipalName, JobTitle, Department
# directory roles, from the account's memberships
$role = "#microsoft.graph.directoryRole"
Get-MgUserMemberOf -UserId $upn -All |
    Where-Object { $_.AdditionalProperties["@odata.type"] -eq $role } |
    ForEach-Object { $_.AdditionalProperties["displayName"] }

One row: c.richardson, a Senior Financial Analyst in Finance, whose directory role is a staff grouping rather than an administrative one. That single answer already shapes everything after it: a finance mailbox holds invoices and payment details, and an account without administrative rights limits what an attacker can do with it directly. The second through fourth questions follow the same pattern, one query each: every address the account used since the alert's window opened, how the access was obtained and what it touched, and the first and latest hostile activity. Each answer narrows the next question, which is why the order is fixed.

The fifth question is the one most often skipped under pressure, and it is the one that sets the urgency. On the capstone's attacker address:

union
    (AADServicePrincipalSignInLogs | where IPAddress == "45.137.21.9"
        | summarize Latest = max(TimeGenerated) | extend Route = "application"),
    (EntraIdSignInEvents | where IPAddress == "45.137.21.9"
        | summarize Latest = max(Timestamp) | extend Route = "user sign-ins"),
    (CommonSecurityLog
        | where SourceIP == "45.137.21.9" or DestinationIP == "45.137.21.9"
        | summarize Latest = max(TimeGenerated) | extend Route = "firewall")
// question 5 of the pack, still happening: the latest activity on every route

(sourcetype="azure:monitor:aad" src_ip="45.137.21.9")
    OR (sourcetype="pan:traffic" (src_ip="45.137.21.9" OR dest_ip="45.137.21.9"))
| eval Route=case(sourcetype="pan:traffic", "firewall",
    category="ServicePrincipalSignInLogs", "application", 1=1, "user sign-ins")
| stats max(_time) as Latest by Route

Three rows, one per route the attacker used. The firewall last saw the address at 13:32 on 14 March and the user sign-ins stopped at 13:38, but the application route was used at 03:47 on 15 March. The incident is still happening, which is the most important single fact the pack can produce, and it took one query.

The pack's value is that it is always the same, whoever runs it and whatever the alert. An analyst who asks the same five questions of every alert finds the unusual answer quickly, because the usual ones are familiar; one who improvises asks different questions each time and misses what the last alert would have shown. Section 1.4 builds the pack in full, and Module 5 onward opens with it.

The pack also protects against the most expensive mistake in triage: acting on an alert's claim without checking it. A High alert that the pack shows to be a known administrator on a known device is closed in minutes; one that the pack shows to be an unknown address on a privileged account is escalated in minutes. Either way the decision rests on the records rather than on the alert's label, and the five queries are the shortest route from one to the other.

Each question has a standard query, written once and saved where the team keeps its queries, and the analyst changes only the account, host or address. That is what keeps the pack to minutes: nobody writes a query from nothing under pressure.

The scorecard, taught in Module 4, turns what the pack and the scope have found into a severity and a priority tier. It asks eight questions, in four pairs, each scored from 0 to 3 against written anchors:

The eight questions were chosen to cover what makes an incident expensive: whether it happened, how much it reached, whether it is still going on, and what it leaves behind. A detector's severity usually rates the first well and the rest poorly, because it sees one event; the card rates all four because the analyst has seen the scope.

The pairs matter because the two questions in each share their evidence. Certainty comes from validation; extent from scope; time from the latest records; quiet harm from what persists and what can be read. Scoring a pair at once, from one query, keeps its answers consistent and makes the card quick to check. A card that takes more than a few minutes to score usually means scope is not yet written, and the fix is to finish scope first.

Two rules make the card work reliably on incomplete evidence, which is the only kind a triage has. An unanswered question is scored at the worst the evidence cannot rule out, and flagged with the check that would settle it, as Section 4.4 sets out. And an identity whose role is unknown is scored by what it did: an account that granted tenant-wide permissions is treated as Tier 0 whatever its role is called.

The card's output is what sets the clocks of Section 0.3, which makes its accuracy matter. The capstone scores 23 of 24, Critical, P1, over a detector that said High; the domain compromise and the edge-to-identity intrusion both land in the Critical band too. Without the card, each would have run on the detector's severity and its slower clocks.

The card is used more than once in any serious incident. It is scored when scope is first written, rescored when new evidence moves an answer, and rescored again as containment removes what the attacker held. Each rescoring goes on the incident with its time, so the record shows the incident moving down the bands as it is contained, which is how a lead knows the work is having an effect.

The card is also where disagreements are settled. Two analysts who reach different tiers compare their cards question by question, and the difference is almost always one anchor read differently, which is a question with an answer.

The Triage Report, taught in Sections 10.5 and 10.6, is the one page a triage hands to the person who will run the incident. It has ten lines in a fixed order:

The order is the order the reader needs the lines in, not the order the analyst found them: what it is and how bad, what the evidence shows, whether it is contained, and what is still open. Each line is filled from a decision the triage has already made, and each carries its confidence: established, inferred or unsupported, in wording the reader can repeat without losing the limit.

The report is the course's third signature because it is where the other two end, and where their results reach people outside the security team. The pack's answers become what happened, scope and timeline; the card becomes severity; the containment state becomes status. A triage that does everything right and hands on a report that says otherwise has not done its job, which is why the capstone ends by checking a draft report line by line against the records.

Its confidence wording is taught in Section 10.6 and is worth learning early. "Established" is written flat, with its source; "inferred" is written with "likely, because" and the basis; "unsupported" is not written as a finding at all, and becomes an open question. Readers skim, and a limit that travels in the sentence survives a skim where a label in a separate column does not.

It is also the instrument with the widest audience of the five, by some distance. The incident lead reads it to decide; the response team reads it to start; the privacy lead reads its loss line for the notification. One page, written once, serves all three, which is why the course holds it to fifteen minutes and one page.

The report is also versioned. A first version goes out within fifteen minutes of the triage call, and a new version follows whenever a line the reader acts on changes, status most often. Each version keeps its time, so a later reader can see what was known when, which is often the question a review or a regulator asks first.

Writing it well is a skill the course practices from the first Practice card to the last capstone sub. The most common faults are the ones the capstone's draft made: a detector's severity in place of the card's, a status of contained that means ordered, and open questions left empty. Each is easy to avoid once it has been seen, and hard to see in one's own draft without the habit of checking every line against the records.

Collection is the one part of triage that happens on the host itself rather than in the records a SIEM already holds. The course uses two collectors, and deliberately leaves out a third:

Live Response is the collector for one device at a time, driven from the same portal the analyst already works in, and it is always at hand where Defender for Endpoint Plan 2 is licensed. Its limits are the lessons, and each one shapes how collection is planned. A script run through it stops after 10 minutes, so a collection is split into small scripts, most volatile first, each finishing well inside the limit. Scripts run from the tenant's library, so the collection scripts are uploaded and reviewed before an incident, not written during one. In the Defender portal:

The unsigned-script setting deserves a note. By default Live Response runs only signed scripts; an administrator can allow unsigned ones in Defender's advanced features. Organizations that leave it off need their collection scripts signed before an incident, which is another reason the scripts are prepared in advance rather than written on the day.

Velociraptor covers what Live Response does not, and it is free for any use: many hosts at once, and hosts without the Defender agent, through an offline collector that can be run from removable media. Both collectors are practiced in advance, which is the only way their limits stay lessons rather than surprises. A collection script that has never been run against a test host will meet its timeout, its signing requirement or a missing dependency for the first time during an incident; one that has been run in a lab, as Section 0.5 describes, meets them on a quiet afternoon.

For the web server in the capstone, a Linux host whose sensor recorded almost nothing, a Velociraptor offline collector is the practical way to gather what is on disk.

KAPE is a widely used and well-regarded triage collector, and the course deliberately does not teach it. Its free edition is licensed for non-commercial use, and use in a paid engagement or on a third-party network requires the enterprise license. Many of this course's students are consultants and managed security analysts, whose everyday work is exactly the use the free license excludes; teaching a tool most of the audience cannot use at work would send them to it at the wrong moment.

The exclusion is about licensing, not about the tool's quality. Organizations that hold the enterprise license, and analysts working on their own organization's systems under the free terms, may well use it, and nothing in the course prevents that. The course simply teaches collection with tools every student can use in the work they are paid for.

The three plans each misuse an instrument, one by its license, one by its limits, and one by leaving it out. Read them beside the terms and make the call:

The call corrects all three of the plans, and none of the corrections costs more than a few minutes. The customer laptop is collected with Live Response, or Velociraptor's offline collector if the laptop has no agent, instead of KAPE, whose free license does not cover paid customer work. The 25-minute script is split into small library scripts, memory and running processes first, each finishing inside the 10-minute limit. And the High alert gets the five queries before any containment: they take minutes, and they decide whether the alert is real and how far it reaches, after which the scorecard sets the tier the containment runs on.

The lead's review also shows why instruments matter to a team, not only to one analyst. Each plan came from a competent person working quickly, and each would have failed in a different way: a license breach on a customer's machine, a collection that stopped halfway, a containment on an unvalidated claim. The instruments are what let a lead review three plans in a minute and see the same things every time.

Each correction is a habit rather than a rule to look up. Check a tool's license and limits before the incident; run the pack before acting on any alert; let the card, not the detector, set the priority. The course builds each habit in its own module and uses it in every module after.

The steps fit a card for choosing an instrument at each point:

The fifth row is the one this sub adds to the rest of the course, and the one easiest to postpone. Every other instrument is taught in full later in the course; checking a tool's terms before you need it is the habit to start with.

Practice

The instruments are practiced from the first incident module onward, and the pack can be tried right now.

If step four finds a gap in the license at all, it is better found now than in the middle of a customer's incident.

That completes the orientation. Module 1 begins with the first of the five decisions: whether an alert is real.