0.4 Where This Shows Up

Four situations account for nearly all of it, and they want different things from the same method. Knowing which one you are in decides how much time the item deserves and what the deliverable is.

The alert queue

The unglamorous majority. Your email gateway quarantined an attachment, the EDR blocked something, a download was flagged. Nothing is on fire and somebody has to say whether each one matters.

The deliverable here is a disposition and a closed ticket, and the constraint is volume rather than depth. Most items resolve in minutes: a file identified as a known commodity family with a strong reputation signal and no evidence it executed does not need capability analysis.

What makes this case hard is not the difficult samples. It is that the method has to be cheap enough to apply to everything, so the discipline lives in stopping early on the ordinary items and having enough left to spend on the one in forty that is not ordinary.

Stopping early is a skill rather than a shortcut, and it has a stated basis. Closing an item because three cheap sources agree and nothing contradicts them is a decision you can write down. Closing it because it looked routine is not, and the difference shows up when somebody asks six weeks later why 0413 was closed in a minute.

ITEM   SOURCE            FIRST READ                      DISPOSITION
0412   mail gateway      known family, high detections   closed, 4 min
0413   mail gateway      same family, same campaign      closed, 1 min
0414   EDR block         signed installer, legit vendor  closed, 6 min
0415   user report       unsigned, packed, 0 detections  ESCALATED
0416   mail gateway      known family                    closed, 2 min
#
Four items in 13 minutes. The fifth is where the day goes.

That table is the argument for the whole cost ordering in this course. Spending twenty minutes each on 0412 through 0416 means never reaching 0415 properly.

Notice what closed 0413 in a minute. It was the same campaign as 0412, so the work had already been done and the second item inherited it. Recognizing that two items are the same thing is one of the cheapest wins available in a queue, and it is the reason Module 7 spends a section on how a queue is organized rather than only on how an item is worked.

The user report

Somebody forwards a file and asks whether it is safe. Lower volume, higher stakes, and a different failure mode.

The stakes are higher because a user report often means the control did not catch it. If the gateway had flagged it, it would have been in the queue instead. So the base rate is different from the queue: these are disproportionately the things your tooling did not know about.

That inversion is worth holding onto. In the queue, most items are ordinary and the rare one is interesting. In user reports, the filter that removed the ordinary ones has already run, so the proportion that deserve real attention is higher even though the volume is lower.

The failure mode is that a clean reputation result on an unknown file reads as reassurance and is close to no information. This is the exact case where the first fit-check scenario applies, and it is the commonest way a targeted sample gets closed.

There is a second-order effect worth expecting. A user who reports something and is told it is fine, in a way that turns out to be wrong, stops reporting. A user who is told it is fine with a reason they understood keeps reporting, and that reporting is a detection source you do not otherwise have.

The deliverable includes something the queue case does not: an answer for the person who asked, in language they can use. "Not detected by any engine" is a technical fact that a user will read as "safe", so the sentence you give them matters as much as the verdict you record.

The incident where a file is one piece of evidence

An investigation is running, a file has been recovered from a host, and the incident lead needs to know what it does so they can scope the rest.

Here triage is a service to somebody else's timeline, and it is the case where speed and clarity matter more than completeness. The lead does not need a family attribution. They need to know whether it persists, whether it steals credentials, whether it moves laterally, and what to hunt for on the other machines.

Capability analysis earns its place hardest here, because it answers exactly those questions from the binary itself, often before a sandbox has finished.

It also answers them in a form the lead can act on. A capability profile mapped to ATT&CK translates directly into hunt queries somebody else on the team already knows how to write, which is a more useful handoff than a description of what the program does.

The trap in this case is scope creep in the other direction: the file is one input to an investigation and the triage verdict is not the incident scope. What the sample can do and what actually happened on that host are separate claims, and the second one needs endpoint evidence rather than sample evidence.

The wording that keeps them apart is simple enough to adopt: say what the sample is capable of, and say separately what was observed. A verdict that reads "this steals browser credentials" will be quoted as though credentials were stolen, where "this is capable of reading browser credential stores; whether it did on this host is an endpoint question" survives being repeated.

The intelligence question

Somebody outside your team asks whether an advisory applies to you, or a partner shares a sample, or a vendor report names a family and leadership wants to know if it is present.

The work here runs backwards from the other three. Instead of a file needing a verdict, you have a description needing to be turned into something checkable: which of the advisory's indicators are durable, which are specific to one build, and what a negative result across the estate would actually establish.

That last part is the one most often overstated, and Module 6 covers it directly. A hunt for the published hashes coming back empty says a specific thing, and it is not "we are not affected".

This situation also has a timing property the others do not. The advisory arrives when it arrives, usually with attention already on it, and the pressure is to answer within the hour rather than within the day. That pressure is precisely what produces the overstated negative, because the careful sentence takes longer to write than the confident one.

What each one wants from the method

SITUATION        SCARCE THING     DELIVERABLE            WHERE IT FAILS
alert queue      time per item    disposition            depth on ordinary items
user report      reputation data  an answer they can use "no detections" = "safe"
live incident    the lead's time  capability + indicators verdict read as scope
intel question   the sample       a checkable claim      absence overstated

The method does not change. What changes is which step you spend the time on and what you are willing to leave unresolved, which is why this course teaches the reasoning rather than a fixed sequence.

A fixed sequence would be easier to learn and would fail in all four situations for different reasons: too slow for the queue, too technical for the user, too late for the incident, and answering the wrong question entirely for the intelligence case.

The case nobody schedules

There is a fifth situation and it is worth naming because it never appears on anybody's list of duties: somebody in the organization is about to run something and asks first.

An engineer wants to use a tool they found. A finance team received an unexpected update from a supplier. A contractor brought a utility. These arrive informally, often in a chat message, and the honest answer is frequently that the file is fine and the process that produced it is not.

Triage handles the file question quickly. The value is in noticing that the same route will produce another file next month, which is a conversation with somebody outside security and the sort of finding that prevents work rather than reacting to it.

These also tend to arrive without a ticket, which means the work is invisible and the finding has nowhere to live. Getting them into the queue even retrospectively is worth the friction, because a pattern across five informal requests is a real finding and five chat messages are not.

Why the situation matters more than the sample

Two analysts can examine the same file, reach the same verdict, and one of them has done the job while the other has not.

The difference is whether the output matched what the situation needed. A thorough capability analysis on a queue item that should have closed in four minutes is a queue that does not get cleared. A one-line disposition on a file recovered from a live incident is an incident lead making scoping decisions without the information you had.

That judgment, which item deserves what, is the thing the modules build alongside the technique. It is also why Module 7 is about running a triage function rather than about triaging.

The practical version is a question worth asking before starting any item: who is waiting for this, and what will they do with the answer. A disposition for a ticket, a sentence for a worried user, a scope for an incident lead, and a checkable claim for leadership are four different products, and the examination that produces them is the same.