The Signal You Inherit

Introduction

The previous section established that telemetry is arriving. This one is about what is in it, how long it stays, and where it goes, because those three are decided independently and an operator inherits whatever combination somebody chose.

The sensor produces more than any single destination keeps. What reaches the console, what reaches the SIEM and what reaches neither are three different sets, and every question you are asked this year is answerable or not on the strength of that split.

You will finish able to establish which tables your estate holds, for how long, in which tier, and to say for any given question whether it is answerable, expensive, or gone.

The endpoint sensor writes into a small set of tables, each carrying one class of activity, and knowing which answers which question is the first working skill of this course.

It is a short list and the fastest way to learn it is to see what each holds on your own tenant rather than to read a description of it.

// One row per table: how much it holds, and how varied its contents are
union withsource = Table DeviceProcessEvents, DeviceNetworkEvents,
      DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents,
      DeviceImageLoadEvents, DeviceEvents
| where Timestamp > ago(1d)
| summarize Rows = count(), Kinds = dcount(ActionType) by Table
| sort by Rows desc

Predict the output before revealing it. You named seven tables in that union, so the useful question is how many rows come back.

Table                    Rows   Kinds
DeviceProcessEvents    161244       2
DeviceFileEvents        99804      11
DeviceNetworkEvents     71129       4
DeviceEvents            13692      41
DeviceRegistryEvents     9421       6
DeviceLogonEvents        3187       5

Six rows returned and the union named seven tables. Image loads are absent entirely, which on this tenant means the table was never enabled rather than that no library was loaded yesterday, and a hunt for side-loading against it would have returned nothing and read as a clean result.

That is the shape of most collection gaps. Not an error, not a warning, just a table that quietly contributes no rows to every query that touches it.

Run it with a one-day window rather than thirty the first time. A short window makes an absent table obvious, because a table that is merely quiet still produces something over a month and one that is switched off produces nothing at any range. It also returns in seconds, which matters when you are going to run it repeatedly.

The names are worth committing to memory in the order the output returns them, because that ordering is roughly the order you will use them. Process events answer what ran and what spawned it. File events answer what changed on disk. Network events answer what a process talked to, which is the thing a firewall cannot attribute to a process. Registry events answer what persisted. Logon events answer who was on the host and how they got there.

Learn them as a routing question rather than as a schema. When a ticket arrives, the useful first thought is which of these would have recorded the thing being asked about, and the answer is usually one table with a second as corroboration. An analyst who reaches for process events for every question will answer about half of them and will not know which half.

Build the corroboration habit now. A finding drawn from one table is a finding from one sensor path, and sensor paths fail independently: a process that appears in the process table and makes no connection in the network table either did not communicate or was not observed communicating, and telling those apart is the difference between a closed ticket and a wrong one.

Five of those tables are event streams where a row is a thing that happened on a machine. Two behave differently, and misreading them is the most common early mistake in this course.

Look at the Kinds column in that output. Miscellaneous device events carries forty-one distinct action types against process creation's two, because it is not recording what the machine did at all. It is where every security control writes what it decided: antivirus verdicts, attack surface rules, exploit protection, tampering attempts. It answers what your own stack did rather than what happened to the host.

One reading demonstrates the difference in a way no description does:

// Counting a snapshot table naively, and correctly, side by side
DeviceInfo
| where Timestamp > ago(7d)
| summarize Rows = count(), ActualDevices = dcount(DeviceName)

On a fleet of 865 machines that returns roughly 145,000 rows and 865 devices, because each device writes a heartbeat repeatedly. The first number is meaningless and looks authoritative, which is exactly the failure mode worth building a reflex against.

Almost every query in this course that touches that table therefore reduces it to the latest row per device before doing anything else. Once you have seen why, the pattern stops looking like ceremony and starts looking like the only correct way to read a snapshot.

The device information table is the other one, and it is a state snapshot rather than a stream. A row there is what the platform believed about a device at a moment, so counting its rows counts heartbeats and produces a number that is large, plausible and meaningless. Every query in this course that touches it reduces to the latest row per device first.

Both are worth learning now because they are the tables that make a finding defensible. The event streams tell you something happened; these two tell you what was watching and what the machine was at the time.

The security control table has a limit worth stating rather than discovering. A control that has been successfully disabled stops writing, so the record ends rather than reporting its own defeat, and what you look for is the gap and the last entry before it. Absence carries as much information as presence in that table, which is not true of the others.

There is a practical habit that follows from the pair. Read them alongside the event streams rather than instead of them: a verdict with no corresponding process row means the control acted on something the process table did not record, which is unusual enough to be worth understanding and is one of the few signals that a collection gap exists on a specific host rather than across a population.

Read the row counts in that output as a ranking rather than as figures, because the ordering holds on almost every estate and it predicts several things.

Process events dominate. File events are close behind and cost the most to retain, because ordinary software writes constantly. Logon events are two orders of magnitude smaller and answer the question that decides an investigation's scope, which is whether the intrusion reached a second machine.

Cheap tables are not less useful, they are less frequent. That matters when somebody proposes reducing ingestion cost by dropping a table: the saving is concentrated in the two high-volume tables and the investigative loss is concentrated in the small ones, so the tables that look attractive to cut are rarely the ones worth cutting.

The ratio also tells you what your estate is doing. A fleet where file events do not dominate is a fleet where something is not being recorded, and a sudden change in the ordering is a configuration change nobody announced.

Run it monthly and keep the results. The comparison is the point: coverage drift is invisible in any single run and obvious across two.

Split the counts by platform the first time. Windows, Linux and macOS produce very different volumes per host, and a fleet-wide average conceals a Linux population contributing almost nothing. Knowing your own per-platform baseline is what lets you notice later that one of them has stopped.

Exclude the servers from the workstation figure while you are there. A handful of busy servers carries enough volume to distort an average in either direction, and the two populations answer different questions anyway.

Take the median rather than the mean when you establish your own version, because a single busy host distorts an average badly and the question is what an ordinary machine of each platform produces.

Keep the result. Three numbers, one per platform, are the baseline you compare against the first time a population looks quiet, and without them you have only an impression that something seems low.

One more reading is worth taking from the same output, which is events per host rather than events in total. A table with a healthy total and a low device count is a table being fed by a few machines, and on a uniform fleet that is a collection problem wearing the appearance of a working one.

Advanced hunting holds thirty days. Not thirty hot days with an archive behind them: thirty days and nothing after, which is the entire interactive window for every table above.

That figure is a property of the license rather than a setting somebody tuned, and it is the single most consequential fact about endpoint telemetry. Every question you can ask in the portal is a question about the last month.

Measure it rather than quoting it, because the answer is per table and the measurement takes one query.

// The oldest row each table still holds. This is your real retention.
union withsource = Table DeviceProcessEvents, DeviceNetworkEvents,
      DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents, DeviceEvents
| summarize Oldest = min(Timestamp), Newest = max(Timestamp) by Table
| extend DaysHeld = datetime_diff("day", Newest, Oldest)
| sort by DaysHeld asc

The DaysHeld column is the answer, and it is worth reading down rather than glancing at, because the tables do not all agree.

Table                    Oldest                DaysHeld
DeviceFileEvents      2026-08-09T02:11:40         29
DeviceProcessEvents   2026-08-08T09:14:02         30
DeviceNetworkEvents   2026-08-08T09:14:02         30
DeviceRegistryEvents  2026-08-08T09:14:05         30
DeviceLogonEvents     2026-08-08T09:14:02         30
DeviceEvents          2026-08-08T09:14:04         30

Twenty-nine days on the highest-volume table and thirty on the rest. That is not rounding: file events arrive faster, the window fills sooner, and the table most likely to answer a staging question is the one that expires first.

Two consequences follow. A hunt has to be repeated rather than run once, because a hunt that found nothing describes a month rather than an estate. And anything worth keeping from a hunt has to be extracted while it is still in the window.

It also sets a hard boundary on what the console can contribute to a slow intrusion. An adversary present for six months is visible in the last thirty days of their activity and invisible for the first five, from this source, which is not an argument against the console but the reason an investigation of any age reaches for a second one.

Write the numbers down where the on-call rota can find them. The most expensive discovery in endpoint operations is learning your retention window on the day you need more of it, and it costs nothing to make that discovery in advance.

Quote it when somebody asks for an investigation of something from last quarter. Answering with the window rather than with an attempt is faster, more honest, and occasionally the thing that gets the retention extended, because a refusal with a number in it is a different conversation from a search that found nothing.

Telemetry can go to three places and most estates use more than one without anybody having compared them.

The console holds it for thirty days at no additional cost, because that is what the license includes. A SIEM connector forwards selected tables into the analytics tier, which is the expensive one and is priced on ingestion. And a streaming export sends events to an event hub or storage account, where you pay for the pipe and for whatever consumes it.

Every retention decision is forward-looking only. A table enabled today begins collecting today, and the month you needed is not retrievable at any price, which is why the red line at the bottom of that figure costs organizations more than any other sentence in this section.

There is a middle path that gets left out when the choice is presented as console or SIEM. Cheaper long-term tiers hold the same tables at a fraction of the ingestion cost in exchange for slower queries, which is exactly right for an audit request and exactly wrong for a hunt.

The question to take to whoever owns the workspace is therefore not how long you keep things, but how long you keep each thing and at what speed. Those are two questions with two answers per table, and asking them separately turns a budget argument into a design one.

Read the destination list before the table list on that page. A destination with no consumer makes every table selection underneath it irrelevant, and it is quicker to find that way round.

Note the date each configuration was last changed if the page shows it. A routing decision made at tenant creation and never revisited is a different thing from one adjusted last quarter, and the second tells you somebody is paying attention to this and is worth talking to.

Note also who can change these pages. Editing an export is a tenant-level action and the people who can take it are frequently not the people who depend on the data, which is how a table selection changes without the security team hearing about it. Knowing that list tells you who to ask when a query that worked last month returns nothing.

None of this section required changing anything, which is deliberate. Routing is one of the few parts of an endpoint estate an operator can fully understand with read access alone, and understanding it is what turns the next several modules from exercises into work you can do on your own estate.

That is enough to read a routing configuration properly, which is the exercise below. Nothing in it is broken and every component is doing what it was told.

Work it before reading the explanation. Four things mean a question the team will be asked this quarter is unanswerable or unnecessarily expensive, and two things that look wrong are correct, which is the ratio a real review tends to have.

The two that are correct matter as much as the four that are not. An operator who raises everything unusual is ignored quickly, and a review flagging the standard thirty-day position as a misconfiguration tells the reader that the reviewer does not know what standard looks like.

Being right about what is fine is what makes the findings land. A review returning six findings from six items has not been read carefully and will be received as an attack on whoever built it; one that names the two good decisions first gets believed on the four that follow.

The four that are wrong also differ in how fixable they are, which is worth separating when you write them up. An export with no consumer can be switched off this afternoon. A missing tier is a budget conversation. And a table that was never forwarded is the one with no remedy at all for the period already gone, which makes it the one to raise first.

A routing configuration is a set of answers to questions nobody had asked yet. It looks like infrastructure and behaves like a scope decision about what your team will be able to establish, taken by whoever happened to be configuring a connector.

It is worth being fair about why they end up this way. A connector is configured during a deployment, by somebody measured on getting data flowing, with no ticket history to test the selection against. Everything forwarded is defensible at that moment and the cost only becomes visible a year later, by which point the person who chose has moved on.

Which makes the review a useful piece of work rather than an audit of somebody's mistake. You have the thing they did not: a quarter of real questions to test the routing against. Do it with the ticket history open, sort twenty closed tickets into answerable, expensive and gone, and the third column is the case.

The signal has consumers beyond you and each pulls in a different direction, so knowing which exist on your estate tells you which arguments about retention you can win.

The alert queue wants yesterday in seconds and the console serves it. A hunt wants thirty days, interactive and iterative, and the console serves that too. An investigation wants as far back as the intrusion goes, which the SIEM serves only if the table was forwarded. An audit or legal request wants one specific month, once, slowly. A compliance control wants proof the collection happened at all. And finance wants the bill, which is decided by wherever the other five landed.

The queue and the investigation are the pair that cannot share a setting. One needs seconds of latency over a day of history and the other needs months and does not care how long a query takes, so a single tier chosen for both is too slow for one and too expensive for the other. That is the real argument for tiering rather than a vendor's framing of it.

Both halves of that argument are gettable as numbers, which is what makes it winnable.

Put that page beside the count of tickets your team could not answer last quarter and the trade states itself in two figures rather than as a principle against a price.

Bring a third figure if you can get it, which is what the cheaper tier would have cost for the same data. A proposal with a price attached is a decision somebody can take; one without is a request that gets deferred until the next incident makes it urgent, at which point the data still does not exist.

Establish which consumers actually exist before proposing anything. A team with no audit obligation and no legal hold does not need a cheap deep tier, and proposing one is how a good idea gets rejected on cost with no case behind it.

The next section takes the first of those consumers, the alert queue, and asks what an endpoint alert actually becomes before anybody sees it.