Mitigation techniques, chosen for the vulnerability in front of you

Objective 2.5 in this course covers mitigation techniques — CompTIA's scope note for it uses segmentation, access control, configuration enforcement, hardening, isolation and patching. This is the last lesson in Domain 2 and the domain's capstone: everything the previous nine lessons described as a threat or a vulnerability gets answered here.

Why this matters

The exam's question shape for this objective is consistent: a scenario describes a weakness, and four mitigations are offered. All four are real controls. Only one addresses that weakness. Marks are lost by picking a good control that solves a different problem.

There is also a strong preference the exam expresses and candidates miss. CompTIA will usually take the mitigation that removes the exposure over the one that watches it, and the mitigation that is enforced automatically over the one that relies on someone remembering.

The lesson

Segmentation, and the blast radius it is bought to limit

Segmentation divides a network so that compromise of one part does not grant access to the rest. It is bought for one purpose — limiting blast radius — and it should be judged on that alone.

The forms, roughly by granularity:

• Physical separation, including a true air gap, where there is no network path at all. The strongest and the most operationally painful, and the one people quietly defeat with a USB drive.
• VLANs and subnets with routing controlled by ACLs or firewalls.
• Screened subnet (the term that replaced "DMZ") — a zone for internet-facing services, reachable from outside but unable to freely reach the internal network.
• Microsegmentation — policy applied per workload rather than per subnet, so two servers on the same VLAN still cannot talk unless policy allows it. This is the zero trust idea from Domain 1 realised on the network.

Segmentation is the correct answer when the scenario is about lateral movement, a flat network, a system that cannot be patched, or two populations of very different sensitivity sharing infrastructure — IoT and corporate, guest Wi-Fi and staff Wi-Fi, OT and IT.

It is not the answer when the attacker has valid credentials and is using them where they are supposed to work.

Access control lists and permissions as a mitigation, not just a setting

Access control appears here as a mitigation because most real exposure is excess permission rather than missing controls.

• ACLs on network devices and firewalls decide which traffic may pass.
• Permissions on files, shares, databases and objects decide who may read or change what.
• Least privilege is the principle: each identity gets exactly what its function requires and nothing more.
• Separation of duties splits a sensitive action so no one person can complete it alone — the person who raises a payment is not the person who approves it.

The failure mode the exam tests is permission creep: people accumulate access as they change roles and nothing is ever removed, so an account compromised years later has the combined rights of four previous jobs. The control is access review — a periodic recertification where a manager confirms each person still needs each right. That is a Domain 5 governance activity and it is the correct answer to "how do we prevent accumulated access?".

Least privilege is also what limits the damage of everything in the previous lessons. A macro that runs as a standard user can do far less than one that runs as a local administrator, which is why removing local admin rights is one of the highest-value single changes an organisation can make.

Application allow lists, isolation, and least privilege in practice

Application allow listing permits only approved software to execute and blocks everything else by default. It is enormously effective — it stops unknown malware regardless of signature, which answers the fileless and zero-day cases that detection struggles with — and it is operationally demanding, because every legitimate new application needs an entry.

Note the direction, because CompTIA tests it: an allow list is default-deny and is the stronger control; a deny list (blocklist) is default-allow and can only stop what is already known. If both appear as options and the scenario is about unknown or novel threats, the allow list is the answer.

Isolation confines something rather than removing it:

• Sandboxing runs untrusted code in a constrained environment — how email attachments are detonated before delivery, and how browsers contain tabs.
• Containment during an incident isolates an affected host from the network while keeping it running for investigation.
• Quarantine holds a suspicious file or device apart from production.
• Isolating an unpatchable system on its own segment with tightly restricted access is the compensating control pattern from Domain 1, and it is the correct answer whenever the scenario says the system cannot be patched or replaced.

Configuration enforcement, decommissioning and hardening

Configuration enforcement is the difference between having a standard and having compliance with it. A baseline that is applied once drifts: people change settings, software reinstalls defaults, new machines are built from an old image. Enforcement means the configuration is applied continuously and automatically — Group Policy, a configuration management tool, a desired-state system — so drift is corrected rather than discovered.

This is why the exam prefers enforcement to documentation. "Update the standard build document" does not change any running machine. "Deploy the setting by policy" does, and it keeps doing it.

Decommissioning is mitigation by removal, and it is under-used. The service nobody uses, the server whose project ended, the account of someone who left, the firewall rule opened for a migration two years ago — each is attack surface being carried for no benefit. Proper decommissioning includes removing access, removing DNS entries and rules, sanitising or destroying the data, and updating the inventory. Domain 4's asset management lesson covers the data destruction side.

Hardening is reducing what a system exposes and what it permits: remove unnecessary software and services, close ports, change default credentials, disable legacy protocols, apply a secure baseline, enable host firewall and logging. Domain 4 covers the per-platform detail; here it is enough to recognise hardening as the general answer to "the system was installed with defaults".

Patching, and why 'patch it' is sometimes the wrong exam answer

Patching is the mitigation that actually removes vulnerabilities rather than containing them, and it should be the default answer when a known vulnerability has a fix available and can be applied.

It is the wrong answer in four situations the exam constructs deliberately:

1. There is no patch. A zero-day, or an end-of-support product. The answer is a compensating control — isolate, restrict, monitor, virtual-patch at a WAF or IPS.
2. The patch cannot be applied now. A legacy application breaks, or the system is medical, industrial or otherwise cannot take downtime. Same answer, plus a recorded risk acceptance with a review date.
3. The problem is not a vulnerability. Weak passwords, over-permissive access, a misconfigured bucket, a user who was phished — patching changes nothing. Match the mitigation to the cause.
4. The question asks what to do first in an active incident. Containment precedes remediation; patching a machine an attacker is currently on does not remove them.

And one caution: patching is change, so it goes through change management. A patch that takes down a production service has traded a security risk for an availability one, which is why staging and maintenance windows from Domain 1 matter here.

Choosing the right mitigation, as a table

What to take into the exam

• Segmentation limits blast radius; it does nothing about valid credentials used where they are allowed.
• Allow list is default-deny and beats a deny list against unknown threats.
• Configuration enforcement beats configuration documentation, every time.
• Isolation plus monitoring is the standard answer for anything that cannot be patched, and it comes with a documented risk acceptance.
• "Patch it" is wrong when there is no patch, when it cannot be applied, when the cause is not a vulnerability, or when the incident is still active.