The Estate You Are Operating

Introduction

Every reading, hunt and investigation you do is against an estate, and almost none of them are informative unless you know what that estate contains.

This section is about establishing that. Not an inventory in the asset-management sense, which somebody else already maintains, but the operational picture: which populations exist, which of them are counted by another team, what each is worth, and where the edges are.

Knowing the edges matters more than knowing the total, because a query returning nothing is only informative if you know what should have been there. You will finish able to produce that picture for your own estate in an afternoon, and to say what any empty result from it is worth.

the organization is an 810-staff engineering firm running Microsoft 365 E5, with the identity, endpoint and SIEM stack that implies. Two sites carry most of it: Manchester as the main office and Birmingham as the secondary, with a small number of staff working from further afield.

// The estate as the platform sees it, and the edge it cannot describe.
// Managed devices on the left, network-discovered ones with no sensor
// on the right: the second set is the part no coverage figure counts.
let Window = 7d;
let Managed =
    DeviceInfo
    | where Timestamp > ago(Window)
    | summarize arg_max(Timestamp, OSPlatform, DeviceType, MachineGroup,
                        OnboardingStatus) by DeviceId
    | summarize Managed = count() by OSPlatform, DeviceType,
                Onboarded = OnboardingStatus == "Onboarded";
let Discovered =
    DeviceNetworkInfo
    | where Timestamp > ago(Window)
    | summarize arg_max(Timestamp, DeviceCategory, OnboardingStatus) by DeviceId
    | where OnboardingStatus != "Onboarded"
    | summarize Unmanaged = count() by DeviceCategory;
Managed
| summarize ManagedTotal = sum(Managed), Enrolled = sumif(Managed, Onboarded)
    by OSPlatform, DeviceType
| union (Discovered
    | project OSPlatform = "unmanaged", DeviceType = DeviceCategory,
              ManagedTotal = Unmanaged, Enrolled = 0)
| extend Coverage = iff(ManagedTotal == 0, 0.0,
                        round(100.0 * Enrolled / ManagedTotal, 1))
| sort by ManagedTotal desc

Run that first on any estate. It gives you the populations rather than the hostnames, and the populations are what every later statement about coverage has to be measured against.

The estate below is the first of those and the course spends its time on the second. Read it for the populations rather than the hostnames: which groups exist, which is small, and which sits at the edge.

Count the identity machines separately whenever you state a server total for this estate, and expect to have to explain why. Twelve general-purpose servers plus five identity machines is seventeen boxes, and the reason to split them is that a read-only controller and a certificate authority are not servers in the sense a capacity conversation means, while being exactly the machines a security conversation is about.

The split also survives the question it invites, which is whether it is a way of making a coverage number look better. It is the opposite: separating them makes the identity population visible as its own line rather than diluted into a total, and a line reading five machines with no endpoint telemetry is considerably harder to ignore than a percentage of seventeen.

The two web servers are the other detail worth marking now. They are the only internet-facing hosts in the estate, they run a different operating system from the rest of the Linux fleet, and they sit in their own network segment. Every one of those three properties makes them behave differently in a query, and all three are the kind of thing that gets forgotten in a hunt written for the general case.

The Birmingham machines carry a similar warning. A file server and a database replica sit at the second site, which means any hunt filtered by a Manchester network range or by a naming convention that assumes the primary site will quietly miss two hosts. Multi-site estates are the normal case and single-site queries are the normal mistake.

Neither of those is exotic. They are the two shapes almost every real estate has, which is why they are in this one: a small population that differs from the majority, and a remote site that is easy to filter out by accident.

The macOS population is the third. Around forty machines in an estate of 865 is under five per cent, which is small enough to be forgotten in a hunt and large enough to matter when one of them belongs to an engineer with access to source. Small populations are dangerous precisely because their absence from a result never looks wrong.

A useful habit follows from all three. When a hunt returns results, group by platform and by site before drawing a conclusion, even when the question has nothing to do with either. Two seconds of grouping tells you whether the answer came from the whole estate or from the majority population only, and it catches the case where a filter you did not think about excluded a fifth of the machines.

The same grouping is the fastest way to find a collection gap you were not looking for. A platform that contributes no rows to a query it should have contributed to is a coverage problem announcing itself, and the announcement only happens if you grouped.

Investigations in this course name people, because real ones do and because a hunt result is a list of accounts before it is anything else. Learning the six below is worth the two minutes: several exercises turn on knowing whose machine you are looking at, and a name that means nothing to you is a row you will skim past.

Three of the four share one approver, which is worth knowing before the night it matters rather than during it.

Three activities and one approver. Establishing that once, before an incident, is the difference between a twenty-minute delay and a decision nobody is authorized to make at two in the morning.

Six names recur through the course, and it is worth learning them by what they decide rather than by their titles.

The last row is the one to remember. A great deal of endpoint operations work needs somebody outside the security team to agree to it, and on this estate that is the IT director. Validating a detection by executing a technique, collecting an artifact from a machine somebody is using, changing what the sensor records: all three are his to approve, and none of them is a security decision from where he sits.

That is not an obstacle to route around. It is the ordinary structure of the job, and the practitioners who get things done are the ones who arrive with the reason, the blast radius and the rollback already worked out.

The two analysts matter for a different reason. Most of what this course teaches will be executed by somebody at their level rather than by whoever designed it, so a detection they cannot action, a hunt they cannot repeat and a playbook they cannot follow at three in the morning are all failures regardless of how well reasoned they are. Writing for the analyst and the second analyst rather than for yourself is a discipline, and it is the one that decides whether the work survives you leaving.

The shape above is one estate. Yours will differ in its numbers and resemble it in its structure, because the structure follows from how organizations buy and manage machines rather than from anything specific to a sector. A workstation fleet, a smaller server population, a handful of machines somebody else administers, and a set of appliances that will never run an agent is the shape almost everywhere.

Producing your own version starts with a single query, and the value is in what you do with the result rather than in running it.

// The estate as the platform sees it, which is not the whole estate.
// Read it for populations, not for hostnames.
let Window = 30d;
DeviceInfo
| where Timestamp > ago(Window)
| summarize arg_max(Timestamp, OSPlatform, OSVersion, DeviceType,
                    MachineGroup, JoinType, OnboardingStatus, IsAzureADJoined)
    by DeviceId, DeviceName
| summarize
    Devices      = dcount(DeviceId),
    Onboarded    = countif(OnboardingStatus == "Onboarded"),
    NotOnboarded = countif(OnboardingStatus != "Onboarded"),
    Versions     = dcount(OSVersion),
    OldestSeen   = min(Timestamp)
  by OSPlatform, DeviceType, MachineGroup
| extend Coverage = round(100.0 * Onboarded / Devices, 1)
| sort by Devices desc

Read it as a small number of rows rather than a device list. Each row is a population you will make statements about for the rest of this course, and the two columns worth pausing on are the version count and the coverage figure.

A population spanning many operating system versions will behave inconsistently in every later query, because sensor capability follows the build. A population where coverage is below a hundred per cent has machines nobody enrolled, which is a different problem from machines that stopped reporting and belongs to a different person.

The afternoon's work is naming what the query cannot: which populations another team owns, which have no agent by design, and which are worth more than their count suggests. That naming is the estate picture, and no console produces it.

Do the naming with somebody who runs the infrastructure rather than alone. Half the rows will have an explanation you could not derive from the data, a group that exists for a licensing reason or a device type that was renamed during a migration, and an hour with the right person is faster than a week of inference.

Write the result down as populations with counts, owners and a sentence each. Twelve rows is a realistic length for an estate of a few thousand machines, and that page is what every later statement about coverage is measured against.

Expect it to be wrong in one or two places and correct it when a query contradicts it. A picture you revise when the data disagrees is a working document; one you defend is the same mistake as an inventory nobody has checked against reality.

An intrusion is not one event in one table. It is a sequence that crosses tables, and knowing which table could hold each stage is what stops you hunting for a phase in a place that was never going to record it.

Four chains cover most of what an endpoint operator meets, each ending somewhere different, and each touching a different set of tables on the way.

That split is the honest picture of the job. An endpoint operator who only reads endpoint tables will investigate the second half of half the intrusions they meet, arriving at a compromised workstation with no way to establish how the session that reached it was obtained.

It also explains an experience almost every endpoint analyst has had, which is being handed an incident that starts in the middle. The alert fires on execution, the investigation establishes what ran and where it went, and the question of how the adversary got there stays open because the answer lives in a table the endpoint operator never opened. That is not a knowledge gap so much as a habit of scope, and it costs a great deal in incident reviews.

The fourth chain is the one to work first if you work them out of order. Pre-encryption activity is dense, it is unambiguous once you know what to look for, and it is the case where the difference between finding it at the staging stage and finding it afterwards is the entire value of the function.

The password spray is the opposite and is worth working second for that reason. It is a chain where almost every individual event is unremarkable and the finding exists only in the aggregate, which is a different reading skill from following a process tree and one that a lot of endpoint practitioners never develop because their tables rarely demand it.

The mail-borne chain is the one that will feel outside your remit, and it is the one where an endpoint operator adds the most unexpected value. The endpoint holds the evidence of what the token was subsequently used to do, and the identity tables hold the evidence of how it was obtained, and nobody who reads only one of those two can describe the intrusion.

Work them in any order, and work all four before the capstone. Each teaches a different reading and the capstone assumes all four, which is deliberate: an operator who can follow a process tree and cannot read an aggregate is as limited as one who can do neither, they just fail on different days.

The exercise below is the device inventory as the platform reports it, against the roster above. The onboarding project closed at 96 per cent and nothing has been raised since.

Read it against the reference block rather than on its own. The whole exercise is a comparison between two lists, and the findings are in what one contains and the other does not, which is invisible if you assess the inventory as a standalone document.

The identity machines are the finding that matters most and the one easiest to accept as normal. A separate team onboarding a separate population is an ordinary organizational arrangement, and its consequence is that every hunt in this course, run against that inventory, silently excludes the machines an intrusion is trying to reach.

Fixing it is rarely a technical problem. The machines are being managed, somebody is looking at them, and the gap is that their telemetry does not arrive where yours does. That is a conversation about routing rather than a project, and it is worth having early because every hunt you run before it is settled carries the same silent exclusion.

Ask what the arrangement is rather than assuming it is an oversight. Domain controllers are frequently onboarded differently on purpose, with a tighter change process and a separate approval chain, and there may be a good reason the telemetry lands elsewhere. The finding is not that somebody was careless; it is that the SOC's hunts do not cover them and nobody had noticed that consequence.

Until it is settled, state the exclusion in writing on every result. A hunt reported as covering the estate is wrong; the same hunt reported as covering 873 devices excluding the identity infrastructure is accurate, costs one clause, and makes the gap visible to everybody who reads the finding rather than only to you.

That habit is worth more than the fix in one respect. The gap will be closed eventually and a different one will open, because estates change, and a team that writes down what its results did not cover will notice the next one considerably faster.

EO0.4 said that asset criticality feeds incident prioritization and depends on the platform knowing which assets matter. the estate is the ordinary case: almost nothing is classified, so that input contributes almost nothing.

There are four criticality tiers, from very high down to low, and three ways an asset acquires one. Predefined classifiers assign automatically against a catalog that already covers file servers, domain controllers and databases holding sensitive data. Custom rules let you write your own against real asset properties such as a tag, a role membership or a resource type. And an asset can be tagged by hand in the inventory. Where several rules apply to one asset, the highest level wins.

the estate uses the third of those and only the third, which is why four file and print servers are classified and 869 devices are not. Enabling the automatic classifiers is the cheapest available improvement to queue quality on this estate, and it needs no rule writing at all.

There is a trap in the enthusiasm that follows, and it is worth naming before you go and classify things. Classifying only servers models about half of a real attack surface, because the identities and the cloud resources are assets too, and an intrusion frequently reaches a critical server through an account rather than through another server. A criticality map that stops at the machines is a map of where the damage lands rather than of how it is reached.

There is also a review step people skip. Automatic classification will flag assets it is confident about and leave others pending a human decision, and a pending queue nobody works is a classification program that stops halfway with the easy cases done. Check it on a cadence, because the assets that did not meet the automatic threshold are frequently the interesting ones: the unusual machine, the service account with more permission than its name suggests, the box somebody built for a project and never decommissioned.

The gap between those two is where this course spends most of its uncomfortable moments. Every empty result you get is empty with respect to the inventory, and the estate is what you are actually responsible for.

Building the second list is unglamorous and takes a few conversations rather than a tool. The management platform gives you one view, the directory gives you another, the network team can tell you what has an address, and the finance or procurement record knows what was bought. Four sources that disagree, reconciled once, produce a list nobody in the organization currently has, and the disagreements themselves are the findings.

Do it early on any estate and keep it. It is the artifact that lets you answer the only version of the coverage question that means anything, which is what proportion of the things we own are we watching.

the zero in the very high tier is the finding those four would surface here. Predefined classification would place both domain controllers there without anybody deciding anything, and it cannot, because those machines are absent from the inventory the classifier reads. Two gaps compounding: the population that is missing is also the population that would have been ranked highest.

The estate above is described. This is how you establish it for yourself, against data where you already know the answer.

One closing observation about why the estate is fictional at all. A real environment cannot be published, so a course built on one either shows you sanitized fragments or asks you to imagine. This one gives you every hostname, every account and every row, which means an exercise can have a right answer and you can be told when you have not found it. That is the whole reason for the construction, and it is why the roster above is worth a few minutes rather than a skim.

The next section separates the three activities this estate is worked with, which are constantly confused and need different things from it.