0.6 What This Course Builds

Introduction

A course about security operations can be about many things: products, techniques, attacks, careers, certifications. Most are a mix, and the mix decides what you can actually do when you reach the end. This one is about work, specifically the work of running detection and response in a Microsoft environment, and it's built so that each module leaves you with something you can use in that work: a detection, a playbook, a record, a query. This sub sets out what those things are, module by module, and how they fit together. It also describes where the course ends, which isn't an exam or a final case but a Project you complete in your own environment, because the point of learning the work is doing it somewhere real.

The diagram groups the thirteen modules by what they produce, not by the order you read them in, though the two are close, since the modules follow the pipeline too. Read top to bottom, the groups follow the pipeline from Section 0.5: foundations first, then the detections that raise alerts, then the investigations that decide what alerts mean, then the response and hardening that act on what's found, and finally the operation that keeps all of it measured and improving. Every arrow ends at the Project, because every group contributes something to it.

Everything the course produces, from the first module to the last, falls into three kinds, whatever the module and whatever its subject, and it's worth knowing which kind a module is building while you read it, because each kind is judged differently.

The three kinds also map neatly onto the two seats from Section 0.1: detections and the operation are mostly the engineer's work, investigations mostly the analyst's, and each seat needs the other's output. Detections are judged by what they find and what they cost: how many real attacks they catch, how many false alarms they raise, and how much data they need. Investigations are judged by whether they reach the right answer and leave a record someone else can follow. An operation is judged by whether it keeps both working over time, which means whether its records are complete, owned and read, the test Section 0.4 used to place a SOC.

Set out as tests, the three kinds look like this, and each test is one you can apply to your own SOC's output as well as to the course's.

The three kinds depend on each other in the same loop as the four functions from Section 0.2. Detections feed investigations; investigations produce verdicts that tune detections; the operation measures both and decides what to change. A course that taught only detections would leave you with rules that decay; one that taught only investigations would leave you working a queue you couldn't improve. The course teaches all three because the job needs all three.

Each kind also has a different shelf life. Detections need tuning within weeks of deployment; playbooks need revising whenever an investigation finds something they missed; operation records need reading on the schedules the packs set. The course builds each with its maintenance in mind, which is why so many modules end with a section on keeping their output current.

The course starts with two modules that everything else rests on. They're short on attacks and long on the mechanics a SOC runs on, and later modules assume both.

Neither module needs any experience to read, and neither assumes you've used Microsoft's tools before; both introduce the portal and the tables as they go. Module 1 is about the queue: how incidents arrive, how they're triaged by severity and priority, how work is handed over between shifts and escalated when it's beyond the first analyst, and which numbers a SOC is judged by. Every later module that mentions an incident's owner, status or classification is using Module 1's vocabulary. Module 2 is about detection as engineering: a rule has a purpose, a specification, a test, a tuning history and eventually a retirement, and the module teaches each step with Northgate's own rules.

Module 1's vocabulary is also the vocabulary of the records, not a separate set of terms. The incident followed through the pipeline in Section 0.5 shows every term in one row.

SecurityIncident
| where IncidentNumber == 83098
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| project IncidentNumber, Title, Severity, Status,
    Owner = tostring(parse_json(Owner).assignedTo), Classification

Severity, status, owner, classification: each is a column, each is defined in Module 1, and each is read by some module after it. The title carries the alert kind and the account, which is how several later queries tell incidents apart without joining to the alerts at all. Both modules are deliberately general. Module 1 would apply to any SOC's queue, and Module 2 to any detection platform's rules. The Microsoft specifics arrive in the modules that follow, built on top of these, which means a reader who knows another platform can still read the first two modules and recognize the work.

If you're new to security operations, these two modules are where the course's vocabulary is set: incident, alert, owner, classification, severity, rule, specification, tuning. Every one is defined where it first appears and used the same way for the rest of the course.

The four detection modules are organized by where the evidence lives, because that decides which tables a detection reads, which attacks it can see, and which product raises the alert. Northgate's month holds a great deal of evidence in each domain, and counting the rows shows how much.

union withsource = T SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs,
    EmailEvents, EmailUrlInfo, DeviceProcessEvents, DeviceNetworkEvents,
    CloudAppEvents, OfficeActivity, Syslog, CommonSecurityLog
| summarize Rows = count() by Domain = case(
    T in ("SigninLogs", "AADNonInteractiveUserSignInLogs", "AuditLogs"), "identity",
    T in ("EmailEvents", "EmailUrlInfo"), "mail",
    T in ("DeviceProcessEvents", "DeviceNetworkEvents"), "endpoint",
    "cloud, network and servers")
| sort by Rows desc

Over a hundred thousand rows across the four domains in a single month, and each is large enough that a detection has to be precise to be useful. The query itself is worth noticing: a union across eleven tables, with a label for each row's source, grouped into domains. That pattern, reading several tables at once and keeping track of which row came from where, is one the detection modules use constantly, because attacks rarely stay in one table. Mail is the largest, because every message and every link in it is a row. Identity is smaller but denser: each sign-in carries the account, the address, the device, the application and the Conditional Access result, which is why so many attacks are caught there first.

Each detection module covers its domain's common attacks, taught from the attacks Northgate's month actually contains.

The modules are independent of each other, though not of Module 2: a reader interested only in mail can go straight to Module 4, and a reader whose SOC has no firewall logs can skim Module 6's network sections. Every detection in these modules is built with the method from Module 2: what it's for, what it reads, what it should and shouldn't fire on, how it was tested against the month, and how it would be tuned. By the end of Module 6 you'll have a library of detections that together cover the attacks in Northgate's month, each with a specification someone else could maintain.

A library of detections is the most visible thing the course produces, and the easiest to overvalue once it's written. The library matters less than what happens to it afterwards, and the difference is easy to see side by side.

A detection library
  written in one month
  tested against that month
 
Left alone for six

The same library
  tuned from verdicts
  measured monthly
  retired when stale
 
Still finding attacks

The right-hand pane is why Modules 2 and 11 both return to tuning. The modules also teach the limits of detection honestly. Some attacks in the month were caught by Microsoft's own products and needed no custom rule; some were visible only by joining two domains; and some, like the password spray in Section 0.5, can't be detected earlier without firing wrongly. Knowing which is which is as much a part of detection engineering as writing the rules.

Detections raise alerts; investigations decide what alerts mean. Module 7 teaches investigation through playbooks, each a fixed sequence of steps that moves from an alert to the records around it, and each worked end to end against one of the month's real attacks.

The three playbooks cover the three kinds of attack a Microsoft SOC sees most, and between them they reach every domain. The first follows a stolen session through the finance user's sign-ins and mailbox; the second follows ransomware from its arrival on a laptop to its first contact with its server; the third follows an intruder from the network edge through an administrator's account into the cloud. Each playbook is built to be reused on the next incident of its kind, not only this one, and Module 7 ends with how playbooks are maintained as attacks change.

Module 8 is about what an investigation leaves behind. An investigation that reached the right answer and recorded nothing is lost the moment the analyst moves on; Section 0.5 found incident 83098 closed with a verdict and no reasoning at all. The module teaches the incident record, the technical timeline, evidence handling, executive summaries, notification decisions and the post-incident review, and it ends with the first of the course's packs, the report pack, which puts them together.

What a finished case contains can be stated as four rungs, and the two modules cover them between them.

Together the two modules take an alert to a finished case: understood, contained where needed, and written down so that someone who wasn't there can follow it.

Investigation finds what happened; the next two modules act on it before and after it happens. Module 9 is about hardening, the configuration changes that make attacks harder or impossible, and it's placed here because hardening is best chosen from what investigations found. Module 10 is about automation and response: the rules and playbooks that act on incidents without a person, and the platform's own attack disruption, which Section 0.5 saw containing an account at 02:34 in the morning.

Both modules produce packs, and the pack is the course's main unit of output from here on. Module 9's pack holds the hardening baselines for identity, mail, endpoints, cloud applications, the network and collaboration, each with validation queries that show whether the baseline is still in place. Module 10's pack holds the automation: what each rule and playbook does, how each is checked, and what the platform's own disruption is allowed to do. The difference between a pack and the usual collection of documents is worth seeing plainly.

A folder of documents
  hardening notes
  automation settings
  a spreadsheet of numbers
 
Nobody knows which is current

A pack
  one record per subject
  an owner and a date on each
  a query behind each figure
 
Read on a schedule

The left-hand pane is what most SOCs have, Northgate included, which is why Module 11 starts by asking where each of the SOC's figures actually comes from, and it isn't a failing of effort: documents are what people write when nobody has said who reads them. The right-hand pane is what each remaining module builds. Module 10 starts from what Northgate's automation already did in the month, which is more than most readers expect.

The second row is the one Module 10 spends longest on, because a response that silently fails is worse than none: everyone believes it ran. A pack is a small set of records, each about one thing, each with an owner, a date and, wherever a figure appears, the query that produced it. Packs are designed to be read on a schedule rather than written once, which is what keeps them current.

The last three modules are about the SOC itself, rather than any one incident or detection. Module 11 measures it: time, backlog, verdicts, data and cost, each measure defined so that it can't mislead, the way the time-to-first-touch figure misled in Section 0.3. Module 12 brings in threat intelligence and judges it by what it matched in Northgate's own records. Module 13 covers Security Copilot and its agents, measured and checked like any other worker in the queue.

Each ends in a pack, and with them the course's packs are complete.

Six packs, one per module from Module 8 onward, each in the same shape and each small, so that reading one teaches you how to read the others. Each is small enough to own and read in an hour a week or a month, and each is built from records the earlier modules taught you to query. Together they're the operation this course means: a SOC that detects, investigates, responds and improves, and can show the records for each.

The six are designed to be read together at a monthly review of an hour or two, in the order they appear, from the cases the month produced to the agents working the queue. Each pack reads from tables you'll already have met by the time you reach it.

None of the three needs a new data source or a new product, and none of them needs a larger team; each reads records the SOC already holds, which is what makes the packs cheap to start. The packs are also where the maturity levels from Section 0.4 turn into practice. A pack with an owner and a schedule is what makes a question measured; a pack whose findings lead to checked changes is what makes it improving. By the end of Module 13, every question in Section 0.4's placement has a pack that could move it.

It helps to be clear, before starting, about what the course won't do for you, as well as what it will, because each misreading leads to disappointment somewhere in the middle of it.

The first row is the most important. The course builds the kit, detections, playbooks and packs, and teaches the habits that use them, but a SOC is people using that kit every day, and the course can't supply the people or the days. What it can do is make sure that whatever SOC you work in, you arrive knowing what records to build and read.

The third row matters for anyone working outside a company like Northgate. Every query in the course reads standard tables from Microsoft Defender XDR and Microsoft Sentinel, with standard columns; nothing depends on Northgate's names beyond the values in the examples. A query that finds a stolen session at Northgate finds one in any tenant with the same tables, which is why the Project asks you to run the course's methods on your own.

Before starting, it's worth checking that your own environment holds what the course reads.

incidents   SecurityIncident, SecurityAlert
identity    SigninLogs, AuditLogs
mail        EmailEvents, EmailUrlInfo
endpoint    DeviceProcessEvents, DeviceNetworkEvents

The gate takes a few minutes with a simple count query per table, run once, and it's worth doing before Module 1 rather than discovering a missing table in the middle of Module 4, when the module's examples stop returning rows. The second row of the strike is where many detection-focused courses stop. A detection library is worth most in the first month after it's written; after that it's worth what its triage, measures and tuning keep it worth, which is why the course spends as many modules on the operation as on the detections.

The course ends with a Project rather than a final case study, because Northgate has already been investigated end to end in Module 7, and a second investigation of the same month would teach less than a first investigation of your own. The Project asks you to apply the course's methods to your own environment.

Each part of the Project exercises one of the three things from Section 01, detections, investigations and the operation, and each is sized to be finished in a few evenings rather than a few months. The incident uses the playbooks and the report pack; the detection uses the method from Module 2 and the tuning from Module 11; the operation review uses the placement from Section 0.4 and the packs from the later modules. None of it needs a large environment: a small tenant, or a practice environment you control, is enough, as long as it has the standard tables.

Choosing the incident is the first decision the Project asks of you, before any query is run, and it's the one most readers get wrong; make the call before reading where it resolves.

The Project is also the best test of whether the course worked, for you and for anyone you show it to, a manager, a colleague or an interviewer. A finished Project is a piece of evidence of your own: an incident record, a detection specification and an operation review, each built to a stated standard and each checkable by someone else. Reading about a playbook, a detection or a pack is one thing; running one against records you didn't choose is another, and the gaps you find in your own environment are the most useful part of the course. The next sub, on the lab and how to study, covers the practice environment and how to use it before you get there.

Practice

Map what you already have against what the course builds.

Keep the list; the gaps in it are the modules to read most closely, and the ones your own Project will probably draw on.

The next sub, Section 0.7, describes the course's lab and practice environment, and how to study the course.