How This Course Is Ordered

Introduction

Courses are usually ordered by difficulty, easiest first. This one is ordered by dependency, because in endpoint operations the easy thing and the first thing are not the same thing, and doing them in the wrong order produces work that has to be redone.

That is worth a section of its own rather than a line in a syllabus, because the same ordering applies to the job. A team's first ninety days on an inherited estate has the same dependencies as this course's first four modules, for the same reasons.

Each module supplies something the next one needs. Telemetry decides what a hunt can ask. A hunt supplies the baseline a detection needs to be narrow. Readiness decides what an investigation will be able to establish. Get the sequence wrong and you write detections against data you do not have, or investigate with evidence nobody collected.

None of that is a claim that you must read in order. It is a claim about what you are borrowing if you do not, and the last section of this sub gives you the check to run for each starting point. A dependency map is more useful than a rule, because it tells you what to verify rather than merely what to do. It is also more honest about the fact that estates differ: the check is the same everywhere and the answer is not.

You will finish able to say what each module supplies the ones after it, which matters if you read out of order, and it tells you what you are missing when you do.

The order is not arbitrary and it is not difficulty. Each module produces an input the following one consumes, and naming those inputs is more useful than naming the topics, because the input is the thing you are missing if you skip a step.

Drawn out, the chain shows what each module consumes as well as what it produces, and the arrow that runs backwards is the one that makes it a loop rather than a line.

Two of the seven produce something that outlives the course, which is worth knowing before you start. The baseline from hunting and the collection posture from readiness are both artifacts your organization keeps, and they are the two that make everything after them cheaper. The others produce skills and rules; those two produce documents somebody else can use.

The dashed arrow matters as much as the straight ones. An incident is the best-evidenced input a detection library ever receives, so the last module in the sequence supplies the third, and a team that closes incidents without producing detection candidates has broken the loop at its most valuable point.

A concrete version of that is worth adopting regardless of how you read this course: every confirmed incident produces at least one detection proposal before it is closed. Not a rule, a proposal, because the engineering may not be worth doing and that is a decision somebody should take deliberately. What matters is that the question gets asked while the evidence is fresh and somebody still remembers the shape of it.

Six weeks later nobody will write that rule. The technique is documented in a closed ticket, the person who understood it has moved on, and reconstructing what made it detectable costs more than the original investigation did.

This course was reordered before publication, and both changes are worth explaining because they are the same mistake made twice.

Detection engineering originally came before the hunting module. That put the module whose third section is about writing detection queries ahead of the module that teaches the query language, and it forward-referenced three sections of the module after it. More importantly, it asked students to write a rule before they had any way to establish what normal looks like on the estate the rule runs against.

The forward references are the detail that makes it undeniable rather than a matter of opinion. A module referring to three sections of the module after it is a module built on material it precedes, and that is checkable rather than arguable. Structural problems like that are usually visible in the cross-references before anybody notices them in the teaching.

Forensic readiness originally came after triage. That put the module about deciding what to collect after the module that consumes what was collected, which is exactly backwards: collection decided during an incident is collection you did not get, and that is the module's own argument.

There is a reasonable case for the other order and it is worth stating, because it is the case that produced the original sequence. You cannot know what to collect until you know what an investigation asks for, so teaching triage first tells you what readiness is for. That argument is real and it loses to a simpler one: a student who learns to investigate and then discovers their estate collects none of it has spent a module learning to want things they do not have.

Both inversions share a cause worth naming: the step that felt urgent depended on the step that felt like preparation, and urgency won.

The dependency that matters most is the one between hunting and detection, because it is the one skipped most often and the one with the most expensive consequences.

Before a line of detection logic is written, a short list of questions about your own estate has to be answered. They are not theoretical and each one changes whether the rule fires twice a week or four hundred times a day.

The first question is the one that catches people, and it is not obscure: endpoint security products themselves access the process they protect. A rule written from a published technique description, without asking that question of your own data, will fire on your own security tooling across the entire fleet.

It generalizes past that one case. Backup software touches files everywhere, management agents create scheduled tasks and services, deployment tools execute remotely, and monitoring reads process lists constantly. Every category of legitimate infrastructure software performs something an attack technique also performs, which is the whole reason a baseline exists.

The published technique description is not wrong; it is describing the technique rather than your estate. It cannot know what else does that here, and the gap between those two is where a shippable rule is made.

The last question is the cheapest and the most diagnostic. Running the rule's own query over the retention window, before shipping it, tells you what it will produce. Nobody has to speculate about false positives when the data to measure them is already there.

Read the result as a distribution rather than a total. Four hundred rows from one host is a single misconfigured machine and a narrow exclusion; four hundred rows spread evenly across four hundred hosts is the rule matching normal behavior and needs different logic. The same count means opposite things and the grouping takes one extra clause.

Group by the initiating process as well as by host. That second grouping is what identifies the legitimate software producing the rows, and it turns the exclusion from a guess about a path into a statement about a named product doing a known job. An exclusion somebody can explain is one that survives a review two years later.

Where the number is genuinely small, that is a result too. A rule returning eleven rows in thirty days, all explainable, is a rule you can ship today with a documented baseline attached, and knowing that before deployment rather than after is the entire point.

Keep that baseline with the rule rather than in a separate note. A rule carrying the eleven rows it matched during review, with each explained, is a rule the next person can evaluate without repeating the work, and it is the difference between a library that accumulates understanding and one that accumulates rules.

The exercise below is the scenario at the top of this section. The query is right. Read the not-established block before the query, because that is the part a real review would spend its time on.

Most detection reviews look at the logic, because the logic is the part that resembles code and the part a reviewer feels qualified to judge. The logic is rarely where rules fail. They fail on volume, on scope, on an exclusion nobody reasoned about and on an action nobody agreed to, and none of those is visible in the query text.

That suggests a review checklist rather than a review conversation, and a short one. What does this return over the retention window. What legitimately does this here. What population is it scoped to. What action does it take and who agreed. Four questions, none of them about the query, and a rule that answers all four is a rule that will still be trusted in a year.

Put the four in the template so nobody has to remember them. A submission form that asks for the volume figure will get the volume figure, and the author will have run the query, which is most of the value before anybody reviews anything.

That is the general shape of a good process control: make the useful thing the path of least resistance rather than an instruction people have to remember under pressure.

The fix in that case is not a better query. It is half an hour of reading the estate the rule will run against, which is the step this course puts between the hunting module and the detection module and the step that most programs skip.

It is worth being clear that the author did nothing careless. They found a technique, understood it, wrote correct logic and tested that it fires, which is more rigor than a great many shipped rules receive. The gap is a step nobody told them existed, and that is a process problem rather than a competence one.

Reviews that treat it as a competence problem produce engineers who stop submitting rules. The useful review says the logic is right, here are the five readings this needs before it ships, and here is the query that takes the first four minutes of it.

Most people will not read seven modules in sequence, and that is reasonable. The order is a dependency map rather than a rule, so reading out of order is fine provided you know what you are assuming.

Wherever you start, one check converts the assumption you are making into a fact before you build on it.

None of those checks takes long, and each one converts an assumption into a fact before you build on it. That is the same pattern as EO0.2, applied to the course rather than to the estate.

The most common real starting point is not on that list, which is somebody arriving because an incident happened and they need to investigate it now. Start at EO5 in that case, work the incident, and come back to EO4 afterwards while the memory of what you could not establish is still sharp. That is the wrong order and it is the right decision, and the readiness module reads very differently after a week where the evidence was missing.

Write down what you could not establish during the incident rather than afterwards. In the moment it is obvious and specific; a week later it compresses into a general sense that the logging was poor, which is not actionable and does not survive a budget conversation.

The reason the sequence matters is that a detection library is a body of code rather than a collection of artifacts, and code has a lifecycle the ordering above is the first half of.

Mature programs treat rules the way good teams treat software: there is a backlog, a review before deployment, a test suite, version control and a deprecation policy. The result is content that gets sharper over time rather than merely broader, which is the difference between a library of forty rules that work and a library of four hundred nobody trusts.

Each of those five has an obvious counterpart in this course. The backlog is the detection candidates from incidents and hunts. The review is the estate questions above. The test suite is the validation runs from EO0.5. Version control is a repository rather than a portal. And the deprecation policy is the retirement discipline: a rule producing only false positives is training analysts to ignore the platform, and one that cannot fire is occupying attention for nothing.

Adopt them in that order too, because each is cheaper once the one before it exists. A backlog without a review process just queues unexamined work; a test suite without version control has nothing stable to test against. Teams that try to introduce all five at once generally end up with a repository containing rules nobody deploys from.

The measure that follows is the one worth adopting early. The output of a detection program is not the number of rules deployed; it is the number of incidents detected, with rule lifecycle treated as a first-class measure alongside it. Counting rules rewards breadth, which is precisely the thing that produces four hundred rules nobody trusts.

It is also the measure that makes retirement possible. A team judged on rule count cannot delete anything, because every deletion is a visible reduction in the number it is measured by, so libraries only ever grow. Change the measure and retiring a broken rule becomes an improvement rather than a loss, which is the mechanical reason the deprecation policy and the metric have to change together.

Detections also have a half-life. An adversary technique that produced a reliable signal three years ago may be obsolete, and the environment underneath a rule changes even when the technique does not. That is why validation is a cadence rather than an event, and it is the argument for the retirement discipline in EO0.5.

Two different clocks are running on any rule, which is worth separating when you review one. The technique clock is the adversary adapting, and it is slow and largely outside your control. The environment clock is your own estate changing under the rule, and it is fast and entirely within your organization: a new deployment tool, a renamed service account, an operating system update, a schema change. Most rules die of the second rather than the first, which is encouraging because the second is observable from inside.

The dependency order is not only how to read this course. It is a defensible plan for the first three months on an estate you have inherited, and it is worth having one because the alternative is being pulled entirely into the queue.

The last line is the part that gets skipped by people keen to be useful. Arriving and immediately changing detections is how a new person becomes the reason something broke, and the six weeks of establishing costs less than one badly reasoned change and buys the credibility to make good ones.

There is one exception worth naming, because a rigid rule here would be silly. If the establishing work turns up something actively dangerous, an automatic isolation rule scoped to everything or a filter hiding an entire severity, raise it immediately rather than waiting for week seven. The plan is about the ordinary case, and the ordinary case is that nothing found in the first fortnight needs fixing this afternoon.

Show the page of facts to somebody in week two. It is the most valuable thing a new operator produces and it is invariably the first time anybody has written those numbers down.

Expect some of it to be received badly, and prepare for that rather than softening the page. A count of rules that have never fired, a retention window shorter than people assumed and a list of populations nobody is watching are all uncomfortable, and all three were true before you arrived. The framing that works is that these are the estate's facts rather than anybody's performance, which is both true and the only version of the conversation that goes anywhere.

Date it and repeat it at ninety days. The comparison is what turns a document into evidence of a program, and the second version takes an afternoon because the queries are already written.

Date the page of facts and repeat it at ninety days. The comparison is what turns a document into evidence of a program, and the second version takes an afternoon because the queries are already written.

The order above is a claim about dependency. This tests it against one rule from your own library.

One observation to close on, because it is the reason this section exists at all rather than being a note in a syllabus. Every failure this module has described is a sequencing failure rather than a knowledge failure. The detection author knew the technique. The hunt team knew how to query. The person who set the retention understood retention. In each case somebody competent did a step before the step it depended on, and the result was work that had to be redone or evidence that was never collected.

That is worth carrying into your own estate more than any individual query in this course. When something is not working, the useful first question is frequently not what is wrong with this, but what was supposed to happen before this.

The next section takes one week on the queue at Northgate and works it end to end, naming which module addresses each thing that goes wrong.