0.2 Triage and Incident Response: The Handoff Point

Introduction

Triage and incident response work on the same incident with different goals. Triage decides, in the first hour and from partial evidence, what the incident is and what must happen now; incident response then works out everything that happened, removes the attacker and fixes what failed. The handoff is the point where one becomes the other, and it is where many incidents lose time or information. This sub sets the two jobs side by side, places the handoff on the incident's timeline, lists what must cross it, and then shows the two ways it goes wrong at Northgate: a domain compromise held at the wrong rung for 30 hours while its analyst chased the full picture, and an intrusion that would have been handed on as a server problem with a cloud backdoor still running. By the end you'll be able to say when an incident you are triaging should be handed on, and what has to go with it.

The same incident looks different from the two sides of the handoff, because each side is asking different questions on a different clock:

Neither job is more important than the other, and neither can be skipped. Triage without response leaves an incident decided but not resolved: the attacker contained for now and still inside, the cause unknown. Response without triage starts late, from the alert, with nobody having checked whether the thing was real or how far it reached. Each depends on the other doing its own job and not the other's.

The two jobs are often done by different people, and at many organizations by different companies. A security operations team or a managed service provider triages; an internal incident response team or an outside firm takes serious incidents on. Northgate works that way: its Level 1 analysts triage, the incident response lead decides, and a retained response firm is brought in for incidents that need forensics. The handoff is then also a handoff between organizations, with contracts, engagement terms and access to arrange, which is one more reason it cannot wait until the end.

Even where one team does both, the two jobs stay distinct from each other. The same analyst who triages an incident at noon may investigate it in the afternoon, but the decisions made at noon still have to be written down and passed on, if only to that analyst's later self and to whoever covers the next shift.

The failure the course cares most about is triage quietly doing response's job. It feels like diligence, and it is usually meant as diligence: an analyst who keeps an incident to understand it fully is working hard on it. But the incident is waiting for decisions the analyst cannot make, and every hour spent reconstructing is an hour its containment and escalation did not happen. The response team, when it finally receives the incident, gets a detailed account of the past and a present nobody has acted on.

The reverse failure is triage handing on too soon, before its five questions are answered. The response team then receives an incident that has not been validated, scoped or scored, and has to do the triage itself, usually more slowly, since it is not set up for speed.

The two failures have the same root: treating the handoff as an event at the end rather than a decision made on evidence. Asked as a question, is this incident ready to hand on, and if not, does it need handing on anyway, the handoff becomes something an analyst checks for rather than stumbles into.

The course treats the handoff as a decision in its own right, taught in Module 10 and applied in every incident module. This sub sets out where it falls.

The handoff falls at the point when triage's decisions have been made, or earlier if the incident needs something triage cannot give it. On the incident's timeline it sits after the report:

Two things in the diagram are worth noticing before the handoff itself. Preservation starts in triage and runs on after the handoff, because evidence capture begun in the first hour is completed by the response team's forensic work. And containment is split: triage takes the first actions that stop the harm, and response completes the containment, removes the attacker and recovers. The handoff sits between the two halves of both.

The line also moves earlier for some incidents, whatever stage the triage has reached. A domain compromise, a regulator's clock, a suspected insider or a need for outside forensics each means the incident needs people and authority beyond the triage analyst's, and it is escalated and handed on as soon as that is clear, with the triage continuing alongside rather than before.

What the line never waits for, in any incident, is completeness. Triage ends with open questions, and Module 10 treats them as part of the handoff rather than a reason to delay it. A handoff with five open questions, each with an owner, is a good handoff.

The point of the handoff is also a point in time that should be recorded. The incident record shows who held it before and who holds it after, with the time of the change, so that a later reader can see how long triage held the incident and whether that was reasonable. An incident whose owner field simply changes, with no note, looks the same as one reassigned by mistake.

The domain compromise's own records show what waiting costs:

union
    (SecurityAlert | where CompromisedEntity has "DC01" or AlertName has "DCSync"
        | project Time = TimeGenerated,
            Record = strcat("alert: ", AlertName, " (", AlertSeverity, ")")),
    (SecurityIncident | where Title has "domain"
        | project Time = CreatedTime, Record = strcat("incident created: ", Title))
// the domain compromise: its alerts, and when it became an incident
| order by Time asc

(sourcetype="ms365:defender:incident:alerts"
        (CompromisedEntity="*DC01*" OR AlertName="*DCSync*"))
    OR (sourcetype="ms365:defender:incident" Title="*domain*")
| eval Record=if(sourcetype="ms365:defender:incident",
    "incident created: " + Title, "alert: " + AlertName + " (" + AlertSeverity + ")")
| eval Time=coalesce(CreatedTime, _time)
| table Time, Record
| sort Time

Six rows. High alerts on the domain controller on 19 and 20 February and on 27 February, with no domain incident raised until mid-March; a DCSync alert at 03:18 on 14 March; and the incident created at 05:30 that morning. The incident then sat with a Level 1 analyst for 30 hours, until the lead took it at noon on 15 March. Section 10.2 measured that delay; here it is the shape of a handoff that did not happen.

The earlier alerts matter to the handoff as well. A response team taking the incident on will want to know whether the February alerts on the same domain controller were the first signs of the same attack. That is an open question for the package, not a reason for triage to hold the incident until it is answered, and it is exactly the kind of question the response team's forensic work on the domain controller can settle and triage's records cannot.

A handoff is a package of material, not a message saying the incident is being handed on. Section 10.7 set out its contents: the Triage Report, the evidence register with every item's hash and holder, the containment state route by route, the open questions with their owners, the decisions already made and by whom, and the people already told. Without them, the response team starts from the alert and repeats the triage.

What the month's closed incidents carry shows how rare that is:

SecurityIncident
// what the month's closed incidents carry for whoever reads them next
| where Status == "Closed"
| summarize Closed = count(),
    WithComment = countif(tostring(Comments) !in ("", "[]")),
    WithReason = countif(isnotempty(ClassificationReason))

sourcetype="ms365:defender:incident" Status="Closed"
| eval HasComment=if(Comments!="" AND Comments!="[]", 1, 0)
| eval HasReason=if(ClassificationReason!="", 1, 0)
| stats count as Closed, sum(HasComment) as WithComment, sum(HasReason) as WithReason

One row. 85 incidents were closed over the month; 62 carry a classification reason; none carries a comment. Whoever reads any of them later, a reviewer, an auditor or the response team following up on a related incident, gets a label and nothing about how the decision was reached. A closed incident is a handoff to the future, and these handed on almost nothing.

The cost shows up later. When the spray reached r.scott's account on 2 March, anyone checking her history found an impossible-travel alert closed as a false positive on 19 February with no comment, and had to redo the analysis to know whether it had been an early sign. Section 11.3 found the closure was right, and nothing on the record said so.

Evidence is the other thing a late handoff loses, and it loses it silently. Each incident's first records have a shelf life:

union
    (SigninLogs | where IPAddress == "185.234.72.18" and UserPrincipalName != ""
        | summarize FirstRecord = min(TimeGenerated)
        | extend Incident = "phishing compromise"),
    (SigninLogs | where IPAddress == "91.215.85.201"
        | summarize FirstRecord = min(TimeGenerated)
        | extend Incident = "password spray"),
    (CommonSecurityLog | where SourceIP == "45.137.21.88"
        | summarize FirstRecord = min(TimeGenerated)
        | extend Incident = "edge-to-identity intrusion"),
    (CommonSecurityLog | where SourceIP == "45.137.21.9"
        | summarize FirstRecord = min(TimeGenerated)
        | extend Incident = "multi-stage intrusion")
// when each incident's first evidence leaves a thirty-day store
| extend LeavesThirtyDayStore = FirstRecord + 30d
| order by FirstRecord asc

(sourcetype="azure:monitor:aad" category="SignInLogs"
        (src_ip="185.234.72.18" OR src_ip="91.215.85.201"))
    OR (sourcetype="pan:traffic" (src_ip="45.137.21.88" OR src_ip="45.137.21.9"))
| eval Incident=case(src_ip="185.234.72.18", "phishing compromise",
    src_ip="91.215.85.201", "password spray",
    src_ip="45.137.21.88", "edge-to-identity intrusion", 1=1, "multi-stage intrusion")
| stats min(_time) as FirstRecord by Incident
| eval LeavesThirtyDayStore=strftime(FirstRecord + 2592000, "%Y-%m-%d %H:%M")
| sort FirstRecord

Four rows, one per incident. The phishing compromise's first attacker sign-in leaves a thirty-day store on 29 March; the spray's on 31 March; the two intrusions' on 11 and 13 April. A response team that receives the phishing compromise in the last week of March has days to export its earliest evidence, and a handoff that does not say so leaves them to find out when a query comes back empty.

Each of the package's parts answers a question the response team would otherwise have to ask. The report says what happened and how sure anyone is. The register says what evidence exists and where. The containment state says what is already stopped and what is not. The open questions say where to start. The decisions and the people told say what has already been committed to on the organization's behalf, which matters most when a regulator or a customer has been told something.

The package is what makes the handoff quick, and its absence is exactly what makes most real handoffs slow. With it, the response team can start work within the hour; without it, the first day goes on reconstructing what the triage already knew.

The domain compromise's analyst was doing careful, competent work, and the draft note shows it. The questions in the draft note, which accounts were replicated and how the attacker reached the domain controller, are exactly the ones the response team will need answered. The problem is who should answer them and when:

The resolution turns on what the incident needed at noon that it was not getting from anyone. A domain compromise needs decisions a Level 1 analyst cannot make, such as resetting the domain's most privileged accounts and deciding whether to rebuild domain controllers, and it needs forensic work on those controllers that triage is not equipped for. Every hour it stayed at Level 1 was an hour those decisions were not made.

It is worth being clear about why the analyst held on, because the reason is common and understandable. Handing on an incident one has not fully understood can feel like admitting failure, and a Level 1 analyst may reasonably worry about being seen to pass problems up. The fix is a culture in which early escalation is the expected behavior for certain incident types, set out in Section 10.1's thresholds, so that handing on a domain compromise at once is simply the rule rather than a judgment the analyst has to defend.

The same thresholds also protect the senior staff's limited time. An escalation rule that fires on the incident type, not on the analyst's discretion, sends the lead the incidents that need a lead and not the rest.

The handoff does not discard the analyst's work. The replication and entry questions become open questions in the package, with the analyst's findings so far and the queries behind them, and the analyst stays on the incident as a source for the people now running it. Handing on is not handing off responsibility for what one knows.

The response firm, for its part, needs the analyst's reasoning just as much as the findings. Which queries were run, which accounts were checked and cleared, which leads were followed and dropped: all of it saves the firm from repeating work, and none of it survives a handoff that consists of a status line. The analyst's working notes go into the package as they are, marked as notes rather than findings.

The rule the course draws from this case is simple to state, and harder to follow under pressure. When an incident needs someone the triage analyst is not, the handoff happens now, with what is known; the full picture is what the handoff is for.

The opposite failure is harder to see, because from the outside it looks decisive and efficient. An analyst who validates an alert, contains the obvious thing and hands on has done something, and the queue shows the incident moving. But if scope was never done, the response team receives an incident smaller than the real one.

The capstone's first scope, in Section 12.4, is the clearest example in the course. It named one host, the web server, and nothing in the cloud. Handed on at that point, the incident would have gone to the response team as a server compromise with a password to reset:

Handed over: WEB-NGE-MCR-02 compromised.
Password reset done. Over to you.

Handed over with scope: server, account,
app with tenant-wide mail read. Open: 5.

The left-hand handoff, which looked complete to anyone reading it, would have left an application with read access to every mailbox in the tenant running, because nobody had followed the account out of the server into the cloud. The response team, starting from a server problem, would have investigated the server. The right-hand handoff took twenty minutes longer and carried the whole reach of the incident.

The balance between the two failures is the five questions. A handoff before they are answered, to the level the decision needs, hands on an incident that is not yet understood; a handoff long after they are answered holds an incident that needed other people. Most handoffs go wrong on one side or the other, and knowing which way an analyst leans is part of knowing their work.

The early handoff also has a cost that falls on the response team later. Receiving a server compromise, the team plans a forensic examination of one host; discovering a tenant-wide cloud backdoor two days later, it has to re-plan, re-engage and often re-notify. The twenty minutes the triage saved at the handoff are spent many times over afterwards, and the application kept reading mail in the meantime.

The early handoff has a quieter variant: closing an incident rather than handing it on. An analyst who validates an alert, finds the obvious cause and closes the incident has handed it to nobody, and if the scope was wrong, the incident is simply lost until something else finds it. The same five questions apply before a closure as before a handoff, and a closure comment that says which were answered is what lets a reviewer check.

The response team can also push back. A package without a scope, a score or a containment state is returned to the triage with the missing line named, which is faster than accepting it and discovering the gap later.

The draft note would have kept the domain compromise at Level 1 until the end of the day at least. Read it beside the records and make the call:

The call is to hand over now, at noon, not at the end of the day. The domain compromise goes to a senior owner and the response firm today, with the package: the report with its confidence marked, the evidence register, the containment state, the analyst's questions as open items with the analyst as their owner, the decisions already taken and the people already told. The handoff is recorded on the incident with its time and receiver, so the record is not a draft note in someone's mailbox.

The handoff itself is short work for the analyst to do. The report and the register exist or can be produced in under an hour from what the analyst has; the open questions are the draft note's own contents, written as questions; the containment state is one line, since nothing has been contained yet, which is itself the most urgent thing the response firm needs to know.

The same handoff also fixes the month's pattern. Every incident closed from now on carries a comment saying what was decided and why, which costs a minute and turns 85 labels into 85 records someone can read. And every package now states which of its evidence leaves its store first, so the phishing compromise's 29 March deadline is in front of the response team rather than behind it.

The steps fit a card for any incident triage is holding:

The second row is the one the domain compromise failed, and it fails most often in practice. The five questions were not fully answered, and the incident needed a senior owner anyway; that alone was reason enough to hand on.

Practice

Handoffs are best practiced on incidents that are already closed, where the records show what was handed on.

If step three finds anything, it names the line the next package should carry, and the handoff it came from is the one to fix first.

Section 0.3 turns to the clock that runs through all of this: how fast each decision has to be made.