A stolen laptop with FDE is a hardware loss. A phished user with FDE is still a data breach. These are different threat models.
Full disk encryption is frequently misunderstood as a general-purpose data protection solution. The exam exploits this by pairing FDE with scenarios where it provides no protection — and asking which control would help.
FDE's threat model is physical: an attacker who removes the drive and connects it to another machine. Without the TPM-bound key, the drive's contents are ciphertext. This is the scenario FDE completely defeats.
FDE provides zero additional protection against:
- Account compromise: An attacker who obtains the user's login credentials (via phishing, credential stuffing, or keylogger) and logs in sees decrypted files — the OS decrypts transparently for the authenticated session. FDE cannot distinguish a legitimate login from an attacker login.
- Malware running under the user's session: Ransomware executing as the logged-in user can read and encrypt every file the user can access — FDE has already decrypted the volume for the running OS.
- Insider threat: An employee with valid credentials sees all their authorized data whether or not FDE is present.
The correct layered answer: FDE covers physical theft. Least privilege + MFA + monitoring cover account compromise. No single control covers all scenarios.
NIST 800-88 multi-pass overwrite is the HDD standard. For SSDs, it's unreliable — wear leveling hides data from overwrite tools.
The exam will present decommissioning scenarios and ask which sanitization method is appropriate for a specific media type. The most common trick is listing "multi-pass overwrite" as a correct answer for SSDs — it's the right answer for HDDs, but wrong for SSDs.
Why overwrite fails for SSDs: NAND flash storage uses wear leveling to distribute writes evenly across memory cells and extends drive life. When an overwrite tool writes to a logical block address, the SSD's controller may write to a different physical cell than the one that previously held the data — the old physical cell still contains the original data, invisible to the overwrite tool. Over-provisioned cells (spare capacity that the OS cannot address) can retain data permanently through a software overwrite.
The correct SSD sanitization path:
- If FDE was deployed from day one: Cryptographic erase — destroy the encryption key. All ciphertext becomes permanently irrecoverable regardless of what's physically on the NAND. Instant, effective, preferred.
- If FDE was not deployed: ATA Secure Erase command (manufacturer-level) or physical destruction (shredding). Manufacturer-level commands instruct the SSD's controller to erase all cells including over-provisioned areas.
- For classified or highly sensitive data: Physical destruction — most certain method for any media type.
For an actively exploited critical vulnerability, the risk of running unpatched is almost always greater than the risk of deploying an untested patch.
Exam questions about emergency patching are designed to test whether candidates understand when normal process should be suspended. The distractor is the "safe-sounding" answer: wait for the normal testing cycle to ensure stability. This answer is wrong for actively exploited critical vulnerabilities.
The key framing: once a patch is publicly released, threat actors immediately reverse-engineer it to understand the underlying vulnerability. Within hours of release, exploit tools exist. Within days, those tools are integrated into automated scanners that probe every internet-facing system on the planet. An organization that waits three weeks to deploy is running three weeks of known-vulnerable exposure against active, automated exploitation.
The risk comparison for CVSS 9.8 unauthenticated RCE:
- Risk of NOT patching: Full server compromise by any attacker with an internet connection and automated tools. Probability: HIGH. Impact: CRITICAL. Duration: length of normal deployment cycle.
- Risk of deploying untested: Possible application compatibility issue or brief service disruption. Probability: LOW (vendor tests critical patches). Impact: MODERATE. Duration: one maintenance window.
The distractor answers ("follow normal process," "wait for Patch Tuesday," "test for the full two weeks") would all be reasonable for routine monthly patches. They are wrong for actively exploited critical vulnerabilities.
Least privilege does not prevent a user from being compromised. It limits what the attacker can do with the compromised account.
Exam distractors frame least privilege as a perimeter control — as if a standard account prevents phishing or initial compromise. It does not. Least privilege is a containment control: it limits the damage that results from a successful compromise, not the probability of that compromise occurring.
Understand the two-phase attack model for endpoint compromise:
- Phase 1 — Initial access: User clicks phishing link, opens malicious attachment, or visits a drive-by-download site. Least privilege has no effect here — the user is the one performing the action, and the malware executes in the user's context immediately.
- Phase 2 — Post-compromise escalation: Malware attempts to install a driver, disable security software, create a persistence mechanism, or move to other systems. This is where least privilege intervenes. A standard account cannot do any of these things — the attacker's post-compromise capabilities are bounded by the account's permission set.
The exam often asks "what would have prevented the attacker from disabling the endpoint protection software?" or "what would have limited the attacker's ability to persist after compromise?" The answer is least privilege — a standard account cannot stop system services or install persistence mechanisms. The answer is NOT least privilege for questions asking about preventing the initial phishing click.
Performance Task
You are the security engineer for a mid-sized professional services firm. The following three scenarios require mitigation decisions. For each scenario, identify the appropriate mitigation technique, explain your reasoning, and describe the failure mode the technique addresses.
A penetration test reveals that an employee's workstation, when compromised during the test, allowed the tester to: (1) install a keylogger that persisted across reboots; (2) stop and disable the EDR service; (3) access and exfiltrate files from a shared network drive the employee's account had access to. The employee runs as a local administrator on their workstation, which is the default configuration for all 200 employees at the firm.
Questions: What single configuration change addresses items (1) and (2)? What additional control limits item (3)? What is the failure mode each control addresses?
Control for items (1) and (2) — Least Privilege (remove local admin):
Convert all 200 employee accounts from local administrator to standard user. A standard user cannot install drivers (keylogger persistence requires a kernel-mode driver), cannot stop or modify system services (EDR runs as a protected system service), and cannot write to system directories where persistent malware typically installs. The tester was able to perform both actions because the compromised account had admin privileges that the malware inherited.
Implementation: Use Group Policy to remove Domain Users from the local Administrators group. Provide a separate local admin account (or LAPS-managed account) for IT staff who need to perform admin tasks. Standard users who need occasional elevation use UAC prompts with IT-provided credentials — they do not carry admin privileges in their daily login session.
Failure mode addressed by least privilege: Post-compromise privilege abuse. Least privilege does not prevent the initial compromise (the tester still got in). It limits what the attacker can do with the compromised account — the blast radius shrinks from "full system takeover" to "user-accessible files only."
Control for item (3) — Need-to-know access control on shared drives:
Review and tighten file share permissions. Not all 200 employees need access to all shared drives. Implement role-based access: the marketing team gets access to marketing shares; finance gets access to finance shares; neither gets access to the other's data. A compromised employee account can only exfiltrate data the account is authorized to read — reducing the scope of the shared drive permissions reduces the maximum exfiltration volume from any single compromised account.
Failure mode addressed: Excessive access scope. The attacker didn't need special privileges to access the shared drive — the account had standing read access that was broader than necessary. Least privilege applied to file share permissions (not just local admin) limits what can be reached after a standard-account compromise.
The firm is replacing 30 laptops used by financial analysts. The old laptops contain financial models, client account data, salary information, and cached credentials. The IT team proposes: delete all user files, perform a Windows Quick Format on each drive, wipe the BitLocker recovery keys from the Azure AD portal, then donate the laptops to a local charity.
Questions: Which steps in the proposed process are insufficient? What is the correct sanitization approach given that BitLocker was enabled from deployment? What documentation is required? What would happen if FDE had not been enabled?
Steps that are insufficient:
- Deleting user files: Deletion removes file system entries but leaves the actual data on the drive sectors. Any free data recovery tool recovers the files within minutes.
- Windows Quick Format: Quick Format rebuilds the file system tables and marks all sectors as available but does not overwrite the data. All files are recoverable with free tools. Even a full format on an SSD doesn't guarantee sector-level overwrite due to wear leveling.
- Wiping BitLocker recovery keys from Azure AD: This removes the recovery key from the portal but does not affect the key stored in the laptop's TPM — if the drive is read while still in the laptop (with the correct PIN/password), the drive still decrypts. Wiping the recovery key from the portal only removes one recovery path, not the primary decryption path.
Correct approach — Cryptographic Erase (because BitLocker was deployed from day one):
- In the BitLocker management tool (or PowerShell:
manage-bde -forcerecoveryfollowed by key deletion), destroy the BitLocker key on each device. Without the key, all ciphertext on the drive is permanently irrecoverable — the data was encrypted when written and there is no plaintext copy anywhere on the drive. - After cryptographic erase, the laptop can be formatted for the charity's use. The format at this point is only necessary to provide a clean OS installation — not for security purposes, since the data was already cryptographically erased.
Required documentation for each device: Asset tag, serial number, device model, BitLocker key destruction method, technician name, date of sanitization, disposition (donated to [charity name]). If a third party performs the sanitization, obtain a certificate of destruction with the same information. Keep records for the period required by applicable regulations (often 3–7 years).
If FDE had not been enabled: Cryptographic erase would not be possible — there is no encryption key to destroy because the data was never encrypted. The correct approach without FDE: NIST SP 800-88 purge-level overwrite for HDDs (multiple random-data passes covering every sector); ATA Secure Erase command for SSDs (manufacturer-level command that instructs the SSD controller to erase all cells including over-provisioned areas); or physical destruction (shredding/degaussing) for any drive containing highly sensitive data where maximum certainty is required. This is significantly more time-consuming than cryptographic erase — another argument for deploying FDE from day one.
During an incident response engagement, forensic analysts determine that an attacker had persistent access to the firm's network for approximately 11 weeks before detection. The attacker's initial foothold was a compromised employee account obtained via phishing. The analysts find that: (a) no SIEM was in place; (b) each department managed its own logs independently; (c) the Windows Event Logs on the compromised systems had been partially cleared; (d) the attacker had moved laterally to 6 additional systems using the compromised credentials. No monitoring alert was generated at any point during the 11 weeks.
Questions: What monitoring infrastructure would have detected this attack earlier? Which specific SIEM capability addresses each of the four findings? What retention policy would have preserved evidence the attacker tried to destroy?
Monitoring infrastructure that would have detected this attack:
A SIEM with centralized log aggregation from all endpoints, identity providers, and network devices. The SIEM would have received log data from each system in near real time, normalized it into a common format, and applied correlation rules to detect the attack pattern across the 11-week timeline.
SIEM capability addressing each finding:
(a) No SIEM in place: Without centralized aggregation, no single person or tool had visibility into the complete picture. Each department's local logs showed only their own slice of the attack. The SIEM's log aggregation function — collecting from all sources into a single searchable repository — is what enables cross-source detection. A single analyst working from the SIEM can see events from all 7 compromised systems simultaneously.
(b) Each department managed logs independently: SIEM normalization translates vendor-specific log formats from different systems (Windows Security Event Log format, Linux syslog format, Cisco ASA format, Azure AD sign-in log format) into a common schema. Only after normalization can the SIEM correlate events — compare a Windows login event to a firewall connection event to a database query event and recognize they all involve the same account at the same time. Independent management in department silos makes normalization and correlation impossible.
(c) Windows Event Logs partially cleared: SIEM remote log storage. The SIEM ingests log events as they occur and stores them in a remote, write-protected repository. When the attacker cleared the Windows Event Log locally (which generates Event ID 1102 — "The audit log was cleared"), the SIEM had already stored the preceding events. The attacker's cleanup affected only the local copy. Additionally, Event ID 1102 itself is a high-value indicator — a correlation rule that fires on log-clear events during off-hours would have generated an alert the moment the attacker attempted to cover their tracks.
(d) Lateral movement to 6 additional systems: SIEM correlation. Lateral movement generates authentication events across multiple systems in a short time period — the same account authenticating to 7 different machines within hours or days is an anomalous pattern. No individual machine's local log shows this pattern (each sees only its own authentication events). The SIEM, which aggregates authentication logs from all systems, applies a correlation rule: "same account authenticating to N distinct hosts within T hours" generates a lateral movement alert. This rule would have fired within the first week of the attacker's lateral movement.
Log retention policy to preserve evidence: Implement a minimum 12-month log retention policy in the SIEM (90-day hot storage for fast search, 12-month cold storage for forensic access). The 11-week dwell time means the earliest attack events were 77 days old at the time of detection — a 90-day retention window would have preserved all of them. A shorter retention window could have destroyed the earliest evidence before the incident was discovered. For regulated industries, retention requirements may extend to 1–3 years depending on the applicable standard (PCI-DSS, HIPAA, SOX).