What Is Already Deployed

Introduction

The previous section said this course assumes a deployed estate. That is a real dependency rather than a disclaimer, and this section makes it checkable.

Four things have to be true before any reading in this course returns something meaningful: sensors reporting, telemetry retained for long enough to answer a question, policy actually applied rather than merely authored, and somebody holding the roles that let them act. Each has a reading that takes minutes.

Those four are not a maturity model and there is no score at the end. They are the inputs that decide whether a given question is answerable on your estate, and each of them fails quietly: none produces an error, and all four produce a result that looks like a clean one.

Establish them before you need them rather than during the first incident, because an incident is the worst time to discover that a question is unanswerable and the worst time to be reading configuration. An hour spent on the four now is an hour that is not spent, under pressure and badly, later.

They are also worth re-establishing on a cadence rather than once. All four drift: devices stop reporting, retention gets changed during a cost review, policy assignment changes when groups are restructured, and people who held roles leave. A set of answers from eight months ago is a description of an estate that no longer exists, which is exactly the trap the scenario above describes.

You will finish able to establish all four on your own estate, and to say which of them is a gap rather than assuming the whole thing is either fine or broken.

A device that completed onboarding and a device that is currently sending telemetry are different things, and the gap between them is where most surprise findings live. Onboarding is an event that happened once; reporting is a condition that is true today or is not.

The reading that separates them is a last-seen timestamp rather than an onboarding status.

// Devices that are onboarded and have gone quiet
DeviceInfo
| where Timestamp > ago(30d)
| summarize arg_max(Timestamp, OnboardingStatus, DeviceType, OSPlatform) by DeviceName
| where OnboardingStatus == "Onboarded"
| where Timestamp < ago(7d)
| project DeviceName, OSPlatform, DeviceType, LastSeen = Timestamp
| sort by LastSeen asc

Read the oldest rows first. A machine last seen five weeks ago is either decommissioned and still listed, or it is running and no longer talking, and those two have very different consequences for a hunt you run tomorrow.

The query deliberately uses a last-seen timestamp rather than a health field. Health is a self-report: it is the sensor saying it believes it is well, which is useful and is not the same as evidence that data arrived. A machine whose agent has failed in a way that stops it reporting will frequently keep reporting healthy right up until it stops reporting anything at all, and the timestamp is the field that notices.

That is a general principle worth carrying into the rest of the course. Prefer a reading that requires the thing to have worked over a reading that asks the thing whether it is working. Data arriving is evidence; a status field is a claim, and the two diverge exactly when it matters.

The same principle picks the query above over the device list in the portal. A list is generated from records the platform holds about devices, and a device that stopped talking still has records; the timestamp on those records is the part that moved. Reading the list tells you the device is known, and reading the timestamp tells you the device is present.

The number that matters is not the count of quiet machines but their shape. Ten quiet laptops in a fleet of 865 is attrition and somebody should tidy the inventory. Three quiet servers is a coverage gap in the population where a compromise costs the most, and it will not announce itself, because a query across an estate returns rows from the machines that are talking and says nothing about the ones that are not.

The count of quiet machines is the least interesting thing in that result. Their shape is what tells you what happened, and the two populations mean opposite things.

Sort by platform as well as by date the first time you run it. The quiet machines cluster, and the cluster names the cause: a group of Linux hosts that stopped together points at an agent update or a kernel that the sensor no longer supports, where scattered single laptops point at people leaving. One of those is a ticket and the other is a project.

Set a threshold you can defend rather than using seven days because the query does. A laptop fleet with traveling users legitimately goes quiet for a fortnight and a server that misses a day is a finding, so one number across the whole estate produces noise in one population and silence in the other. Two thresholds, one per population, is the smallest version of this that works.

Write the two numbers down with the reason beside each. A threshold with a reason attached survives a review and gets adjusted deliberately; a threshold that is just a number gets widened the first time somebody finds it noisy, and widening it is indistinguishable from switching it off.

There is a second reason to establish this before anything else in the course. Every hunt you run from here on is implicitly a hunt across the reporting estate rather than the whole one, and the difference between those two numbers is the size of the blind spot every result carries. Knowing it is 12 machines is very different from suspecting it might be some.

Every question in this course has a time range in it, and the range you can actually ask about is decided by retention rather than by the query. That sounds obvious and it is routinely forgotten, because a query with a range longer than retention does not error. It returns fewer rows and looks like a finding.

Write the numbers down as you read them. Three sources, three windows, one page, and it takes about ten minutes.

Retention differs by where the data sits, which is the part worth internalizing. Advanced hunting tables hold a rolling window measured in days. A SIEM holds what you paid to keep, in a tier you chose, and the archive tier is cheaper and slower to query rather than instantly available.

The diagram also shows why discovery time is the number that decides an investigation's scope. An intrusion found on day three is entirely inside every retention window you have. The same intrusion found on day forty is partly outside the shortest one, and the part that is outside is usually the beginning, which is the part that answers how they got in.

Which is why time to detect is a retention question as much as a detection one. Halving the time to detect does not only reduce damage; it moves the whole investigation window inside the tier you can query quickly, and that changes an investigation from an archive job measured in days to a console job measured in hours.

Establish your own three numbers now and write them somewhere you will find them during an incident. The single most expensive discovery in endpoint operations is learning your retention window on the day you need more of it, and it is a discovery that costs nothing to make in advance.

Two details make the difference between a number and a usable number. The first is that retention is per table rather than per product on some platforms, so a single figure for the whole console can be wrong for exactly the table you need. The second is that the archive tier is a different query path with a different latency, so an answer that exists there is available in hours rather than seconds, and an incident running on a one-hour clock cannot wait for it.

There is a third detail that catches people out during an investigation rather than during planning. Retention is measured from ingestion rather than from the event's own timestamp, so a device that was offline for three weeks and then reconnected delivers old events into a window that is about to expire. Those events are inside retention for days rather than for the month you would expect.

Neither of those is a reason to buy more retention. They are reasons to know, before an incident, which questions your estate can answer quickly, which it can answer slowly, and which it cannot answer at all.

It is also the number to quote when somebody asks for an investigation of something that happened last quarter. Answering with the retention window rather than with an attempt is faster, more honest, and occasionally the thing that gets the retention extended.

Keep a record of the times it has cost you something. A single instance reads as bad luck and a list of four reads as a pattern, and the list is what gets a budget conversation started. That is a small piece of documentation with a better return than most.

A policy written and assigned is a statement of intent. A policy applied to a device is a condition on that device. Between them sit assignment scope, a sync cycle, a device that has to be online, and a conflict that may resolve against you.

The first page tells you where assignment is failing across the estate. The second tells you what one machine actually has, which is what you need when a control did not fire.

For an operator the practical form of this is simpler than it sounds: never infer a device's configuration from a policy you have read. Read the device.

The third line is the only one that is a fact about the machine, and it is also the only one that requires access somebody may not have granted you. Where you cannot read the device directly, a platform-side assessment across the fleet is the substitute, and it is worth knowing which one you are looking at when somebody quotes a coverage figure.

Coverage figures deserve one more question in general, and it is the denominator. Ninety-six per cent of what? Of devices in the management platform, of devices in the directory, of devices on the network, or of devices the organization owns? Those four numbers differ, and a percentage quoted without its denominator is a statement about the easier populations rather than about the estate.

The gap between the first and the last of those four is where unmanaged machines live, and they are the population an attacker reaches first precisely because nothing is watching. A coverage figure computed against the management platform cannot see them by construction: a device absent from the platform is absent from both the numerator and the denominator, so adding it would lower the percentage and leaving it out keeps the number flattering.

The distinction matters most when a control fails to fire. An analyst who assumes a policy is applied treats a missing detection as a detection problem and starts rewriting a rule that was never going to run. An analyst who reads the device first finds the configuration gap in a minute and hands it to the team that owns it.

The reverse error is cheaper but still worth avoiding. Assuming a control is missing when it is applied leads to a request for something the estate already has, which costs a conversation and some credibility. Both errors come from reasoning about a machine from a document rather than from the machine.

That is the general shape of a great deal of endpoint operations work: establishing whether the thing you are investigating is a detection problem, a configuration problem or a collection problem, before spending a day on the wrong one.

Those three have different owners in most organizations, which is the practical reason to categorize before acting. A detection problem is yours. A configuration problem belongs to whoever runs the management platform. A collection problem may belong to both of you plus whoever holds the budget. Naming which one it is at the start of the conversation saves the loop where each team investigates it as though it were their kind of problem.

There is one reading that separates the three faster than anything else, and it is worth learning early. Ask whether the event exists in the raw table. If it does and no alert fired, it is a detection problem. If it does not exist and the device is reporting, it is a configuration problem, because something is not being recorded. If the device is not reporting at all, it is a collection problem. Three outcomes from one query, and it takes a minute.

Run it in that order rather than starting with the alert. Starting from the alert means starting from the one layer you can see, and the two layers underneath it are where the answer usually is. Starting from the raw event means you establish what the estate recorded before you form any view about what it should have done with it.

The fourth assumption is that somebody can act. Every response action in this course, isolating a device, running a live response session, collecting an investigation package, pulling an artifact, is gated behind a role that was granted during a deployment and has frequently never been exercised.

A role that has never been used is indistinguishable from a role you do not have, until the moment it matters. The difference is discovered under time pressure, by whoever is on call, on the worst night of the quarter.

Test it deliberately and on an ordinary afternoon. Take the least destructive action available against a machine you own, confirm it completes, and note who could have done it and who could not. That is a fifteen-minute exercise and it converts an assumption into a fact.

That scoping detail is the one discovered at the worst possible moment. A person who can isolate a workstation may be unable to isolate the server the intrusion moved to, which is a fact readable in an afternoon and otherwise found during an incident.

Record who else holds it while you are there. Response roles are frequently granted to one or two people during a deployment and never extended to the rota, which means the estate has a containment capability available during office hours and not at the times an intrusion is most likely to be noticed. That is a rota problem rather than a permissions problem, and it is invisible until somebody looks.

The same applies to the reverse case. A role granted broadly during a project and never reviewed is a set of people who can isolate machines and no longer need to, which is worth raising for its own reasons.

Both directions come from the same cause. Roles are granted to get a deployment finished and are then inherited by an operation that has different people and different hours, and nothing in the platform notices the mismatch because a role is a static grant rather than a rota.

It is worth checking how the roles are scoped as well as who holds them. A response role scoped to a device group covers the machines in that group and no others, so a person who can isolate a workstation may be unable to isolate the server the intrusion moved to. That is discovered at the worst possible moment and it is readable in an afternoon.

Read them against the rota rather than against the org chart. The question is not who should be able to isolate a machine; it is whether somebody who can is awake at every hour the estate is being watched.

Live response deserves a separate check from isolation, because the two are frequently granted apart. Isolation is a single action with an obvious effect and it tends to be granted widely. A live response session is an interactive connection to a machine, it is the capability that collects an artifact before somebody rebuilds the host, and it is the one most often held by two people who were on the deployment project.

Both are also worth testing against the populations you actually have rather than against a laptop. Isolating a workstation is a well-trodden path; isolating a server has consequences that somebody will want to have agreed in advance, and a live response session against a Linux host or a Mac may behave differently from the Windows case everybody has tried. Establish which of your populations the capability has been exercised against, because the answer is frequently one.

Establish both, note the count of people holding each, and compare that count against the hours the estate is covered. A capability held by fewer people than the rota has shifts is a capability the estate has on paper.

Run the four in the order they are listed rather than the order that looks urgent. Reporting decides whether the retention question is worth asking, retention decides which questions are answerable, configuration decides what is in the data, and roles decide what you can do about any of it. Each narrows what the next is about, and answering them out of order produces facts you cannot yet interpret.

Those four readings are the whole of this section. This turns them into an afternoon on your own estate.

One more property is worth naming before the practice. All four readings are things you can take without changing anything, which means none of them needs a change window, an approval or anybody's permission beyond read access. That matters on a first month, when the useful work is establishing what is true rather than altering it, and it is why this section is a set of queries rather than a set of recommendations.

The next section takes the first of those four, the telemetry that is arriving, and asks what is actually in it and who reads it.