Module Summary

What you learned in this module

EO0 was about the estate rather than about technique, because every module after it acts on data that either exists or does not, and knowing which decides whether the technique accomplishes anything.

Here is what you can now establish, on a real estate, with read access and no permission from anybody.

Say which of the two endpoint jobs a piece of work is (0.1). Engineering decides what the estate does; operations decides what the organization does about what the estate reports. They share a console and almost no skills, and the handover between them is usually a date rather than a conversation. You can trace an alert back to the five decisions that produced its outcome and notice that three of them were taken months earlier by people who were not thinking about it.

Establish four facts that every later module assumes (0.2). Reporting rather than onboarded, retention per table, applied rather than authored, and roles that somebody has actually exercised. All four fail quietly, none produces an error, and you know to prefer a reading that requires the thing to have worked over a reading that asks the thing whether it is working.

Read the signal your estate collects and where it goes (0.3). Seven tables, established by querying for them rather than reading a list, and you saw a union of seven return six rows because image loads were never enabled. Thirty days of interactive retention measured per table rather than quoted, and three destinations that price the same event differently.

Read a queue as something somebody shaped (0.4). Tuning runs before correlation, so a suppression decision decides whether evidence can be joined into an attack story at all. You can compute the two ratios nobody reports, and you know that four of the five measures in a typical pack move together whenever one tuning rule ships.

Recognize four failures that produce no error (0.5). A detection that cannot fire, a hunt asking the wrong question, a decision nobody can reconstruct, and evidence never collected. You can separate the three reasons a rule never fires, and you know that no alert with no rows is a data problem while no alert with rows is a logic problem, and they go to different people.

Work against a concrete estate and know where it stops (0.6). Northgate in full, including the five identity machines that sit outside the endpoint inventory, and the distinction that governs everything after it: an inventory is what the management platform knows about, and an estate is everything an adversary can reach.

Tell detection, hunting and triage apart by time position (0.7). A hunt has exactly three honest endings, two of which look like failure, and a hunt with no output has been abandoned rather than finished. You know that hunting loses to triage for the same people, and that the only reliable source of hunting time is a smaller triage load.

State a detection time that describes the adversary (0.8). Three measurements wear that name and most packs report the one that measures their own queue. You can run the suppression test down any pack and count how much of it moves when you filter rather than when you improve.

Read an intrusion with no malware in it (0.9). Around 82 per cent of detections involve no malicious file, so hash, signature and reputation all report legitimate, and what remains is parentage, argument shape, sequence and account context. You know where the endpoint is strong and where it is blind, and you can write that boundary down.

Say what each module hands the next (0.10). The order is dependency rather than difficulty, and the two orderings that were wrong were wrong because urgency tracks visibility. Before writing any detection you know to ask what already does this thing here, starting with your own security tooling.

Recognize all of it in a working week (0.11). One intrusion, found three days late by a hunt rather than by the four alerts that had been firing about it since Monday, and six of the seven things that went wrong were configuration or process rather than skill.

The readings this module taught

Eleven sections, and between them a short list of things you can now take on any estate without changing a setting.

Which tables return rows, and for how long. Which devices are onboarded and no longer reporting, split by population rather than counted. What a control says on a device against what the policy says about it. Who holds each response role and at what scope. Which custom detections have never fired, and why each one has not. What the queue costs by alert type rather than by count. Which parent and child process pairs appear on three hosts or fewer. And what your estate cannot answer at all, written down where somebody else can read it.

None of those requires a change window. All of them produce a number rather than an impression, and the page they add up to is the most useful thing a new operator can produce in a first fortnight.

What EO1 assumes

The next module is the telemetry itself: what the sensor collects on each platform, which tables carry it, and what the data model means when you query it. It assumes the estate readings rather than establishing them, which is what lets it spend its length on the data.

Take the page of facts from this module with you. Every module after this one asks questions of an estate, and the answers depend on numbers you now have and most operators do not.