Mitigation Techniques

What Is Mitigation?

Mitigation is the process of reducing the impact — and where possible, the likelihood — of a security event. Mitigation techniques operate before, during, and after incidents: before by eliminating known vulnerabilities and protecting data; during by limiting the blast radius of an active attack; after by ensuring evidence is preserved and residual access is removed.

The six core mitigation techniques in this chapter form a layered defensive posture:

• Patching — eliminate known exploitable vulnerabilities before attackers reach them
• Encryption — ensure stolen data cannot be read without the key
• Monitoring — maintain visibility to detect attacks in progress
• Least privilege — limit what any single compromised account can access
• Configuration enforcement — prevent non-compliant devices from joining the network
• Decommissioning — ensure data cannot be recovered from retired equipment

No single technique is sufficient alone. The value of layering is that each technique addresses failure modes the others cannot cover: an unpatched system protected by monitoring is still exploitable; a fully patched system with no monitoring gives attackers dwell time; both are undermined if decommissioned drives are discarded without sanitization.

Mitigation Technique 1 — Patching

Patching is the single highest-impact preventive mitigation technique available. The vast majority of successful exploitation events — including the most damaging breaches of the last decade — targeted known vulnerabilities for which patches had already been released. The attacker did not need a zero-day; the target was simply unpatched.

Patch categories and their operational characteristics:

Auto-update: a nuanced decision. For home users and small organizations, auto-update is strongly preferred — the risk of running unpatched software far exceeds the risk of a rare incompatibility. For large organizations, auto-update on production systems is often disabled: patches are tested against the specific application stack in a staging environment before broad deployment. A patch that causes a critical business application to crash is itself a service disruption. The enterprise workflow: receive patch → test in staging → approve → deploy via centralized patch management (WSUS, SCCM, endpoint management platform) → verify.

Emergency patches and the zero-day window. When a critical vulnerability is being actively exploited in the wild and a patch is released, the window between patch release and deployment is extremely dangerous. Attackers reverse-engineer patches to understand the vulnerability and immediately target unpatched systems. Emergency patches must bypass normal testing timelines — the risk of running an untested patch against a production system is lower than the risk of running a system with an actively exploited vulnerability.

Mitigation Technique 2 — Encryption

Encryption protects data at rest by ensuring that even if an attacker gains physical or logical access to storage media, the data is unreadable without the encryption key. It is a mitigation for storage theft, decommissioning failures, unauthorized database access, and backup media exposure. Three deployment levels exist:

Full Disk Encryption (FDE)

Encrypts the entire storage volume — operating system, application files, user data, swap space, and temporary files. Everything on the drive is ciphertext. The encryption key is typically protected by a TPM chip, a PIN, or both. An attacker who removes the drive from a lost or stolen laptop and connects it to another machine reads only ciphertext.

• Windows: BitLocker (integrated into Windows Pro/Enterprise/Education). Protects system drives and data drives. TPM 2.0 required for automatic unlock; PIN adds a second factor.
• macOS: FileVault 2. Encrypts the entire drive; recovery key is escrowed to iCloud or a local administrator account.
• Linux: LUKS (Linux Unified Key Setup) via dm-crypt. Full disk or partition-level encryption at the block device layer.

FDE is the standard deployment for all laptops and mobile workstations. A laptop left in a taxi without FDE is a data breach; the same laptop with FDE is a hardware loss with no data exposure.

File-Level Encryption

Encrypts individual files or folders without encrypting the entire drive. Provides granular protection for specific sensitive data while leaving other system files unencrypted and accessible.

• Windows EFS (Encrypting File System): Built into Windows NTFS. Individual files or folders are encrypted with a key tied to the user's Windows account. Transparent to the user when logged in — the file decrypts automatically on access. An attacker who copies the file to another system or account cannot read it without the original user's key material.
• Use case: Protecting specific sensitive documents or database files on a shared system where FDE is not deployed, or adding a second layer of protection on top of FDE.

Application-Level Encryption

The application manages encryption of its own data, independent of the underlying file system or disk encryption. The application encrypts data before writing it to storage and decrypts it on retrieval.

• Advantage: Portable protection — the data is encrypted regardless of what operating system, file system, or storage technology is beneath it. Even if the storage layer is compromised (the database file is stolen, the backup is intercepted), the data remains ciphertext.
• Examples: Password managers (encrypted vault file), encrypted messaging apps (local message storage), database column-level encryption (specific fields like SSN or credit card numbers encrypted within the database engine).
• Exam note: Application-level encryption is the deepest defense — it survives failures of FDE and file-level encryption because it operates independently of both.

Mitigation Technique 3 — Monitoring

Monitoring provides the visibility required to detect attacks that preventive controls failed to stop. An attacker who bypasses patching (via zero-day), bypasses encryption (by stealing keys), and bypasses access controls (via credential theft) is still detectable through monitoring — because their actions generate log events, network flows, and behavioral anomalies. Without monitoring, breaches go undetected for months or permanently.

Monitoring architecture is built from two layers:

Sensors — What generates the data:

• Intrusion Prevention Systems (IPS): Inspect network traffic in real time; generate alerts on known attack signatures and behavioral anomalies.
• Firewall logs: Record every permitted and denied connection — source IP, destination IP, port, protocol, timestamp. Every network flow is traceable.
• Authentication logs: Every login and logout, success and failure, with username, source IP, and timestamp. Domain controllers, VPN gateways, and identity providers are critical sources.
• Web server access logs: Every HTTP/HTTPS request — URI, source IP, response code, bytes transferred. SQL injection and web application attacks leave characteristic patterns in these logs.
• Database transaction logs: Every query, modification, and schema change. Abnormal query patterns (mass SELECT on sensitive tables) are indicators of data staging for exfiltration.
• Email logs: Delivery, rejection, forwarding rule changes, and attachment metadata. Phishing campaigns and BEC attacks leave traces in mail server logs.
• Endpoint EDR telemetry: Process creation, file access, registry modifications, and network connections from individual endpoints — the highest-fidelity source for forensic investigation.

Collectors — Where the data goes:

• SIEM (Security Information and Event Management): Central platform that ingests logs from all sensors, normalizes formats, applies correlation rules, generates alerts, and provides a searchable historical log repository. The SIEM is the analyst's primary interface for investigation and detection. Examples: Splunk, Microsoft Sentinel, IBM QRadar, Elastic SIEM.
• Syslog servers: Protocol-agnostic log aggregation. Network devices, Linux systems, and many appliances forward logs via syslog (UDP/TCP port 514) to a central collector. Provides persistence even when the source device is compromised and local logs are deleted.
• Proprietary consoles: Vendor-specific management platforms for IPS, firewalls, and endpoint protection tools. Provide device-specific views but typically require aggregation to a SIEM for cross-source correlation.

Correlation engines. Raw log data from individual sources has limited value. A single failed login on one system is noise. 1,200 failed logins across 1,200 accounts within 45 minutes — password spraying — is only visible when logs from the authentication system are correlated against the account inventory. The SIEM's correlation engine applies rules that identify patterns spanning multiple sources and time periods, turning individual events into actionable alerts.

Mitigation Technique 4 — Least Privilege

The principle of least privilege states that every user, application, and service should be granted only the minimum permissions required to perform its specific function — and nothing more. Least privilege directly limits the blast radius of any successful attack: an attacker who compromises an account with limited permissions can only access what that account can access.

The administrative privilege problem. The most significant least privilege failure is users running with administrative privileges on their own workstations. When a user has local admin rights, any malware that executes in their user context has admin rights too — the malware can install drivers, modify system files, disable security software, and persist across reboots. Without admin rights, the same malware is confined to the user's profile directory and cannot perform privileged operations.

Correct model — temporary elevation:

Application least privilege. The same principle applies to services and applications. A web server process should not run as root/SYSTEM — it needs only the permissions to read its document root and write its log files. If the web server is compromised via a vulnerability, an attacker running in the web server's restricted process context has far less capability than one running as root. Database service accounts should have read/write access to specific schemas only — not DBA rights that allow schema modification, stored procedure creation, or operating system command execution via xp_cmdshell.

Scope limitation in practice. The practical impact is the difference between a breach affecting one user's files versus a breach affecting all of the company's data. An attacker who compromises a standard user account on a workstation with least privilege correctly implemented:

• Can read files the user has read access to — not all files on the system
• Cannot install persistent malware with administrative capabilities
• Cannot modify security software configurations or disable AV
• Cannot access other users' data on the same system
• Cannot modify system-level services or scheduled tasks

The same attacker on an administrator account can do all of these things. Least privilege is not a perfect defense, but it is the difference between a contained incident and a total system compromise.

Mitigation Technique 5 — Configuration Enforcement

Configuration enforcement ensures that every device connecting to the network meets a defined security baseline before it is granted access. A fully patched, properly monitored network can be undermined in minutes by a single non-compliant device joining it — an unpatched laptop brought in from home, a personal device with outdated AV, or a contractor system with no endpoint protection. Configuration enforcement addresses this by making network access conditional on security posture.

The posture assessment process occurs each time a device attempts to connect:

Quarantine VLAN — remediation holding pen. A device that fails the posture assessment is not simply denied access and disconnected. It is placed in a restricted network segment — a quarantine VLAN — that provides just enough access for the device to remediate itself: access to the Windows Update server, the antivirus update server, and the remediation portal. The device has no access to production systems, shared drives, or the internet while in quarantine. Once remediation is complete, the device resubmits for posture assessment. If it now passes, it moves to the production network.

What the certificate check verifies. Beyond patch level and endpoint protection, the certificate check answers a question the other checks cannot: is this device a corporate-managed asset? A personal device can have its OS fully patched and AV installed, but if it does not hold a machine certificate issued by the corporate PKI, it is not a known, managed device. The certificate provides cryptographic proof of organizational ownership — an attacker cannot fabricate it without access to the corporate CA's private key.

Mitigation Technique 6 — Decommissioning

Decommissioning is the final phase of an asset's lifecycle — the point at which a device is retired from service. Without a formal decommissioning process, sensitive data on retired storage media can survive for years in storage rooms, resold on eBay, or in recycling bins — readable by anyone who finds it. The data doesn't know the device is decommissioned.

Why the risk is underappreciated. Modern hard drives and SSDs retain data until explicitly overwritten or destroyed. Simply deleting files removes the filesystem pointer to the data — the data blocks themselves remain on the drive until overwritten. Formatting a drive removes the filesystem structure but leaves data blocks intact. A deleted or formatted drive purchased secondhand can yield all of its previous data using free data recovery tools within minutes.

Storage media types requiring secure handling:

• Hard Disk Drives (HDDs): Magnetic platters retain data. Multiple-pass overwrite (DoD 5220.22-M or NIST SP 800-88 clear) or physical shredding.
• Solid-State Drives (SSDs): Flash cells — standard overwrite tools are less reliable due to wear leveling and over-provisioning areas. Manufacturer-provided secure erase (ATA Secure Erase command), cryptographic erase (destroy the encryption key if FDE was enabled), or physical destruction is required.
• USB drives: Flash-based, same SSD considerations apply. Lower-value targets but often contain sensitive data from portable use.
• Backup tapes, optical media, SD cards: Must be included in the decommissioning policy — data doesn't only live on the server's primary drives.

Disposal decision tree:

Formal decommissioning policy requirements. The process must be documented: asset tag, drive serial number, method of sanitization, technician who performed it, date, and chain of custody. Certificate of destruction must be obtained from any third-party recycler or destruction vendor. A device removed from service without this documentation is a compliance violation and a potential data breach waiting to be discovered.

The Mitigation Layering Principle

The six techniques form a layered defense where each layer compensates for failures in the others: