ES0.3 The Endpoint Security Stack

Layer 1: Hardening — reduce the attack surface before the attacker arrives

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 that the endpoint presents to the world.

In the Microsoft ecosystem, hardening includes: CIS Benchmarks for Windows (disabling unnecessary services, restricting network protocols, configuring local security policies), Intune security baselines (Microsoft’s recommended configurations for Windows, Edge, and MDE), compliance policies (requiring BitLocker, requiring firewall, requiring minimum OS version), Windows LAPS (randomizing local administrator passwords to prevent credential reuse during lateral movement), and Credential Guard (isolating LSASS secrets in a virtualization-based security container to prevent credential theft).

The hardening layer has a unique characteristic: it is entirely preventive but not actively so. It does not detect attacks, respond to incidents, or preserve evidence. It simply 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 with default configurations. The attacker must find a way around each hardening measure before they can proceed, and each additional measure costs them time and increases the probability of detection.

Layer 2: Prevention — block known attack techniques at execution time

The prevention layer actively blocks attack techniques as they execute. This is where most organisations focus their endpoint security effort — and where most organisations stop. The prevention layer includes: ASR rules (blocking specific high-risk behaviors like Office spawning child processes, scripts launching downloaded content, LSASS access by non-system processes), Defender Antivirus with cloud protection (scanning files and script content against cloud ML models), AMSI (intercepting script content before execution), network protection (blocking connections to known malicious domains), exploit protection (enforcing process-level mitigations like DEP, ASLR, and CFG), WDAC (restricting which executables are allowed to run), and Controlled Folder Access (preventing unauthorized modifications to protected directories).

The prevention layer’s strength is immediacy — it blocks the attack in real time before damage occurs. Its limitation is that it can only block what it is configured to block. An ASR rule in audit mode prevents nothing. AV at the default cloud protection level misses threats that High+ would catch. WDAC that is not deployed provides zero application control. The gap between “prevention controls available” and “prevention controls enforced” is the operational reality this course addresses.

The prevention layer also has a fundamental constraint: 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 LOB applications that launch helper processes from Office. 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 the allowed list. Module ES4 teaches the audit-first methodology that manages this constraint — deploy in audit mode, analyse the false positives, build exclusions, then enforce.

Layer 3: Detection — find what prevention missed

The detection layer identifies attacks that bypass or evade the prevention layer. No prevention layer is complete — determined attackers will find techniques that are not blocked. The detection layer exists to catch these bypasses through continuous behavioral analysis and pattern correlation.

In the Microsoft ecosystem, the detection layer includes: MDE’s EDR engine (continuous telemetry collection and behavioral correlation), built-in MDE alerts (Microsoft’s detection models for known attack patterns), custom detection rules (KQL queries scheduled in Advanced Hunting that alert on organisation-specific patterns), hunting queries (proactive analyst-driven searches for indicators of compromise), and Sentinel integration (cross-workload correlation of endpoint data with identity, email, and cloud signals).

The detection layer’s effectiveness scales with engineering investment. Out of the box, MDE generates alerts for common commodity malware patterns, known exploitation techniques, and documented attack tools (Mimikatz, Cobalt Strike default configs, common webshells). These built-in detections catch the attacks that most organisations face most of the time. But targeted attacks — where the adversary uses custom tooling, modifies known tools to evade signatures, or operates entirely through LOLBins — require custom detection rules written for your specific environment. The detection engineering work in Modules ES8 and ES9 is where MDE transforms from a product into a platform.

Layer 4: Response — contain confirmed incidents

The response layer provides the tools and procedures for containing confirmed incidents. Detection identifies the attack. Response stops it from spreading. In the Microsoft ecosystem, response capabilities include: device isolation (severing network connectivity while maintaining the MDE cloud channel), live response (remote command execution for evidence collection and immediate remediation), automated investigation and response (AIR — Microsoft’s automated investigation and remediation engine), custom indicator blocking (blocking specific file hashes, IP addresses, URLs, or certificates across the fleet), and investigation packages (automated collection of forensic artifacts from the compromised endpoint).

Response is the layer where speed matters most. A ransomware detection means nothing if the response action — isolating the affected device — takes 30 minutes to execute. At that point, the ransomware has encrypted the local drives and is moving laterally. Automated response — where a high-confidence detection triggers immediate device isolation without human approval — reduces response time from minutes to seconds. But automation has its own blast radius: a false positive detection that triggers automatic isolation takes a production machine offline, potentially disrupting business operations. Module ES7 covers the confidence-based automation matrix that determines which detections can safely trigger automatic response and which require human approval.

Layer 5: Forensic readiness — ensure evidence exists when the investigation team arrives

The forensic readiness layer is the most frequently neglected layer in the endpoint security stack — and the one that determines whether an incident investigation succeeds or fails. Forensic readiness means configuring the endpoint to generate and retain the evidence that investigators need before the incident occurs. This includes: advanced audit policies (enabling process creation auditing with command-line logging, logon event auditing, privilege use auditing), PowerShell logging (ScriptBlock logging that captures the content of every PowerShell script executed, Module logging, Transcription), Sysmon (enhanced process, network, and file system monitoring with Event IDs 1, 3, 7, 8, 10, 11, 12, 13), Windows Event Forwarding (centralizing event logs to prevent loss if the endpoint is compromised), and pre-staged collection tools (KAPE targets and Velociraptor agents ready to execute when needed).

The forensic readiness layer 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 an alert and the response layer contains the incident, the investigation team has the evidence they need to determine scope, identify the attacker’s actions, and validate that containment was complete. Without forensic readiness, the investigation team arrives to find default audit policies that did not log the process command lines they need, no PowerShell ScriptBlock logs to reconstruct the attacker’s scripts, no Sysmon events to trace process-level activity, and no centralised event log backup to recover events the attacker cleared.

Layer interdependencies: what breaks when a layer is missing

The five layers are not independent — they have dependencies that create cascading failures when a layer is absent.

Missing hardening (Layer 1): Prevention and detection must compensate for a larger attack surface. Every default configuration that hardening would have closed is now a potential attack path that prevention must block or detection must find. Without LAPS, a single compromised local admin hash grants access to every endpoint — the detection layer must now detect lateral movement across hundreds of machines instead of one.

Missing prevention (Layer 2): Detection must handle the full volume of attacks. Every technique that prevention would have blocked now executes, generating endpoint activity that the detection layer must triage. Alert fatigue accelerates because the detection layer is seeing attack techniques that should have been blocked before they executed. The SOC team spends time investigating attacks that a configured ASR rule would have prevented.

Missing detection (Layer 3): Response has nothing to trigger. Attacks that bypass prevention execute successfully and are never identified. The organisation does not know it has been compromised. Response capabilities sit idle because nobody has detected the incident that requires response.

Missing response (Layer 4): 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 mechanism to stop the attack beyond manually contacting IT to pull network cables.

Missing forensic readiness (Layer 5): Response contains the incident but the investigation fails. 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 determine what data was accessed because object access auditing was not enabled. The incident is contained but never fully understood — the organisation cannot confirm whether data was exfiltrated, which regulatory notification obligations were triggered, or whether the attacker has additional persistence mechanisms that were not discovered.

Troubleshooting

“We don’t have budget for all five layers — which do we prioritize?” You already have the tools for all five layers in your M365 E5 license. MDE provides prevention (ASR, AV, network protection), detection (EDR, custom rules), and response (isolation, AIR, live response). Intune provides hardening (compliance policies, security baselines). Windows provides forensic readiness (audit policies, PowerShell logging). Sysmon is free. KAPE is free. The investment is engineering time, not licensing. Prioritize: prevention first (ASR rules, AV cloud protection — Module ES4-ES5), then detection (custom rules — Module ES8), then forensic readiness (audit policies, Sysmon — Module ES11), then response optimization (AIR tuning — Module ES7). Hardening integrates throughout.

“Our MSSP says they handle detection and response — so we only need prevention.” Your MSSP handles detection and response using the telemetry your configuration generates. If your audit policies are at default, your MSSP cannot see the evidence they need. If your custom detections do not exist, your MSSP’s alert queue does not contain the alerts they should be triaging. If your forensic readiness is not configured, your MSSP’s investigations produce incomplete findings. You own the configuration. They operate on it.