ES0.6 The NE Endpoint Landscape

· Module 0 · Free

Operational Objective

Endpoint security engineering begins with an honest assessment of where you are today. Not where the compliance report says you are. Not where the vendor dashboard says you are. Where you actually are — measured by which controls are enforced (not just deployed), which telemetry is being collected (not just available), and which gaps an attacker would exploit if they compromised a user account right now. This subsection walks through Northgate Engineering's actual endpoint security posture: 865 endpoints with MDE onboarded on 90%, every other control at default, and the specific gaps that each subsequent module in this course addresses. Your environment will have different numbers but the pattern will be familiar — a deployed product with an unconfigured security stack.

Deliverable: A gap analysis methodology applied to NE's endpoint security posture, identifying the specific controls that are missing or misconfigured, mapped to the modules in this course that close each gap.

Estimated completion: 25 minutes

Figure ES0.6 — NE's current endpoint security posture. MDE is deployed but not engineered. Every gap maps to a specific module in this course. The journey from 2/10 to 8-10/10 is the work of Modules ES1 through ES15.

The current state: deployed but not engineered

Northgate Engineering has M365 E5 licensing for all 810 staff. Defender for Endpoint P2 is included. Intune is enrolled. The endpoint security products are available. The gap is between available and configured.

MDE onboarding: 780/865 (90%). The initial onboarding push hit 90% of the fleet. The remaining 85 devices include: 45 devices that are co-managed with SCCM and were not included in the Intune EDR profile, 22 BYOD devices that are enrolled in Intune but the EDR profile targets only corporate-owned devices, 12 devices that have been offline for more than 30 days (employees on leave, retired hardware still in the asset register), and 6 devices where the MDE sensor failed to install due to conflicting third-party AV software (legacy McAfee agent from a previous security product). The last 10% is always the hardest. Module ES2 covers the troubleshooting and onboarding completion process.

AV configuration: default. Defender AV is running on all MDE-onboarded devices. Cloud protection is at the default level (not High or High+). Block at First Sight is enabled (it is on by default). Real-time protection is on. But the cloud protection level determines how aggressively the cloud ML models analyse unknown files — default level provides basic cloud lookups, while High+ provides extended analysis time and blocks files that the cloud has not seen before. The difference matters for zero-day and targeted attacks.

ASR rules: zero in block mode. No ASR rules have been configured through Intune or GPO. NE has the prevention capability that could block Office from spawning PowerShell, block LSASS credential theft, block persistence through WMI subscriptions — and none of it is active. This single gap means that the prevention layer (Layer 2 from ES0.3) is operating at minimum capacity.

Expand for Deeper Context

Compliance policies: exist but do not enforce. Intune compliance policies are configured and assigned. Devices are evaluated against the policy requirements (BitLocker, firewall, minimum OS version, AV enabled). Devices that fail are marked “non-compliant” in Intune. But no conditional access policy references the compliance state. A non-compliant device — with BitLocker disabled, an outdated OS, or AV not running — can still access all M365 resources. The compliance policy is a measurement tool, not a security control. Module ES3 connects compliance to conditional access, turning measurement into enforcement.

Custom detections: zero. The Advanced Hunting console is available. The DeviceEvents tables are populated with telemetry from 780 devices. But no custom detection rules have been created. NE depends entirely on Microsoft’s built-in MDE alerts for detection. These built-in alerts are good for commodity malware and known attack tools but do not cover NE-specific patterns, environment-specific baselines, or the targeted techniques used in the CHAIN attack scenarios.

Forensic readiness: minimal. Windows audit policies are at default — process creation auditing is not enabled, command-line logging is not captured, object access auditing is off. PowerShell ScriptBlock logging is not configured. Sysmon is not deployed on any endpoint. KAPE and Velociraptor are not pre-staged. If an incident occurs tomorrow, the IR team will find limited telemetry on the endpoint — MDE’s DeviceEvents tables provide some data, but the detailed event log evidence that a forensic investigation requires is not being generated.

Server and Linux coverage: gaps. The 12 Windows servers are partially covered — 8 are onboarded to MDE through the unified agent. The remaining 4 (including 2 domain controllers) have the legacy MMA agent and limited MDE functionality. The 8 Linux servers (6 RHEL, 2 Ubuntu) are not onboarded to MDE at all. The mdatp agent has not been installed. These servers have no endpoint security monitoring beyond their local AV configuration.

Hardening: BitLocker only. BitLocker is the single hardening control deployed across the fleet, driven by the Cyber Essentials Plus requirement. CIS benchmarks have not been applied. LAPS is not deployed — every endpoint shares the same local administrator password. Credential Guard is not enabled. The hardening layer is effectively absent.

What an attacker sees

An attacker who compromises an NE user account (through phishing, credential spray, or session hijacking) encounters this endpoint security posture:

The phishing payload executes without ASR interference — no rules block Office from spawning child processes or scripts from launching downloaded content. The LOLBin chain (mshta → PowerShell → rundll32) runs unimpeded. The cloud AV at default level performs a basic check but the in-memory execution bypasses file-based scanning. The attacker is on the endpoint with code execution.

Privilege escalation succeeds because Credential Guard is not enabled and the LSASS ASR rule is not in block mode. The attacker dumps LSASS via comsvcs.dll and obtains NTLM hashes for every user who has logged into the machine.

Lateral movement is straightforward because LAPS is not deployed. The local administrator hash obtained from LSASS is valid on every endpoint. The attacker uses pass-the-hash to access 865 machines. No custom detection rule alerts on the lateral movement pattern.

The investigation team arrives to find default audit policies that did not capture the command lines used during the attack, no PowerShell ScriptBlock logs to reconstruct the scripts executed, and no Sysmon events to trace process chains. MDE’s DeviceEvents tables contain some telemetry, but the detailed forensic evidence is missing.

This is not a theoretical scenario. This is the operational reality of most M365 E5 environments that have deployed but not engineered their endpoint security stack. The CHAIN-ENDPOINT attack at NE exploited exactly these gaps.

Decision Point

You have completed the gap assessment and identified 15 controls that need configuration. Your management asks for a timeline. Do you (A) commit to configuring all 15 in the next 30 days, or (B) propose a 90-day phased deployment starting with the highest-impact controls? Option B is correct. Deploying all controls simultaneously creates an unmanageable blast radius — if 6 different policy changes are applied in the same week and users start reporting problems, you cannot isolate which change caused the issue. The phased approach in Module ES0.7 deploys visibility controls first (audit mode, monitoring), then prevention controls (ASR in graduated deployment), then detection (custom rules), then forensic readiness (Sysmon, audit policies). Each phase has success criteria that must be met before advancing.

Try it: build your own gap assessment

Open a document and create three columns: Control, Current State, Target State. For each control below, record your environment’s status:

Onboarding: Total devices in the fleet. Devices onboarded to MDE. Percentage. Gap devices by reason (co-managed, BYOD, offline, conflicting software). ASR: Number of rules in block mode. Number in audit mode. Number not configured. AV: Cloud protection level (default / high / high+ / zero tolerance). Block at First Sight (on/off). PUA detection mode. Compliance: Policies exist? Connected to CA? Devices non-compliant count. Consequence of non-compliance (nothing / notification / CA block). Detection: Custom detection rule count. Last hunting query executed (date). Sentinel MDE connector status. Forensic readiness: Audit policy configuration (default / partial / full). PowerShell ScriptBlock logging (on/off). Sysmon (deployed / not deployed). Collection tools pre-staged. Hardening: LAPS (deployed / not deployed). Credential Guard (enabled / not enabled). CIS baseline applied. Security baselines assigned. Servers and Linux: Windows servers in MDE (count). Linux servers in MDE (count). Server-specific AV exclusions configured.

Save this document. You will reference it as you progress through each module, checking off controls as you configure them.

Compliance Myth: "We passed our security audit, so our endpoint security is adequate"

The myth: The auditor checked that AV was running and current, devices were enrolled in management, and compliance policies existed. The audit passed. Therefore, endpoint security meets the required standard.

The reality: Most security audits check for the existence of controls, not their effectiveness. An auditor verifies that AV is running — not that cloud protection is at High+ instead of default. An auditor verifies that compliance policies exist — not that they enforce conditional access. An auditor verifies that MDE is deployed — not that ASR rules are in block mode or that custom detection rules are written. NE would pass a standard audit today: AV running (yes), devices managed (yes), compliance policies (yes), EDR deployed (yes). NE would fail a real-world attack: no ASR prevention, no custom detection, no forensic readiness, no LAPS. The audit measures the checkbox. The attacker measures the configuration.

Troubleshooting

“Our gap list is too long — we cannot resource all of these changes.” Prioritize by impact. The three highest-impact changes for most environments: (1) ASR rules from not-configured to audit mode on all devices — zero blast radius, immediate visibility. (2) LSASS ASR rule from audit to block — high prevention impact, low false positive rate. (3) AV cloud protection from default to High+ — immediate improvement in unknown malware detection, no user impact. These three changes can be deployed in a single sprint and provide measurable improvement across the prevention layer.

“Our IT team pushes back on security configuration changes because they break things.” This is why the audit-first methodology exists. Deploy ASR rules in audit mode first. Collect 2-4 weeks of data. Analyse the audit events to identify which legitimate applications would be affected. Build exclusions for those applications. Then move to block mode. The data-driven approach eliminates the “it might break things” objection — you have the data showing exactly what it will affect.

Operational Artifact — Endpoint Security Gap Assessment Template

The gap assessment has four columns per control: Control Name, Current State (not configured / audit / partial / enforced), Target State, and Course Module. For NE, the assessment shows 15 gaps across the five layers. Your environment will have its own gaps. The template structures the assessment so that every gap maps to an actionable configuration task covered by a specific module in this course. Maintain this document as a living tracker — update the Current State column after each configuration change. When all rows show “enforced” or “configured,” the endpoint security architecture is complete.

NE's gap assessment shows: MDE onboarded on 90% of devices, default AV, zero ASR rules in block mode, zero custom detections, compliance policies not enforcing CA, no Sysmon, no LAPS. Which single gap represents the largest immediate security risk, and why?

10% of devices not onboarded to MDE — because those devices have no EDR monitoring. While true, the 90% that ARE onboarded have a misconfigured security stack. Fixing the 10% gap adds monitoring. Fixing the prevention gaps on the 90% adds actual protection.

No Sysmon deployed — because the IR team has no forensic evidence. Sysmon is important for forensic readiness but has zero impact on prevention or detection. It is a Layer 5 gap, not a Layer 2 gap.

No LAPS deployed, combined with zero ASR rules in block mode. LAPS is the single control that prevents credential reuse during lateral movement. Without LAPS, every endpoint shares the same local admin password. Without the LSASS ASR rule in block mode, the attacker can dump that shared password from any compromised endpoint. Together, these two gaps mean: compromise one endpoint → dump one hash → access all 865 endpoints. The compound risk of these two gaps enables a single-endpoint compromise to become an environment-wide breach with zero additional effort from the attacker.

Compliance policies not enforcing CA — because non-compliant devices can access M365 resources. This is a real gap but affects the identity layer more than the endpoint security layer. A compromised endpoint with CA enforcement still has a compromised endpoint — CA protects cloud resources, not the endpoint itself.

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← Previous Next →