Security+ Vulnerability Mitigation: Segmentation, Patching, and Hardening

Introduction

This lesson completes Domain 2, Threats, Vulnerabilities, and Mitigations (22% of SY0-701), with objective 2.5: explain the purpose of mitigation techniques used to secure the enterprise. Building on threat actors and attack indicators, you now learn the Security+ vulnerability mitigation toolbox: segmentation, access control, application allowlisting, patching, encryption, monitoring, least privilege, configuration enforcement, decommissioning, and hardening techniques.

On the exam, mitigation questions usually give a problem and four plausible controls. The best answer is the control that addresses the stated weakness at the right layer and with the least disruption. This lesson gives you a method for choosing.

Learning objectives

After this lesson you will be able to:

• Explain segmentation and why it limits lateral movement.
• Apply access control concepts: access control lists, permissions, and application allowlisting.
• Describe patch management, including testing, deployment, rollback, and exceptions.
• Explain isolation, encryption, monitoring, least privilege, and configuration enforcement as mitigations.
• Describe decommissioning and hardening techniques: disabling ports and protocols, removing default accounts, endpoint protection, host firewalls, and host-based intrusion prevention.
• Choose compensating controls when the preferred control cannot be applied.

1. The mitigation mindset

A vulnerability is a weakness; a mitigation reduces the likelihood or impact of its exploitation. Mitigation is rarely about one tool. It is defense in depth: several independent layers, so that the failure of one does not mean compromise.

A reliable way to approach exam questions:

1. Identify the asset and the weakness (unpatched, exposed, over-privileged, misconfigured).
2. Ask whether the fix should prevent, detect, or contain.
3. Prefer the control that removes or restricts the cause over one that merely observes it.
4. If the preferred control is not possible (legacy system, no patch), choose a compensating control.

2. Network segmentation and lateral movement

Network segmentation divides a network into zones so that traffic between them must pass through controls such as firewalls or access control lists. Filtering constrains movement between segments, but allowed connections, stolen privileged accounts, and configuration errors can still permit compromise.

Typical segments: guest Wi-Fi, corporate users, servers, payment systems (to scope PCI DSS), management network, and operational technology (OT).

Example 1: segmentation limiting ransomware

Scenario. A hospital has one flat network of 3,000 devices. A nurse's workstation is infected with ransomware that scans for open file shares and encrypts 60 servers in an hour.

Redesign. Place clinical workstations, servers, medical devices, and guest networks in separate VLANs. Allow only specific ports from workstations to specific servers. Block workstation-to-workstation traffic. This design restricts the paths available to the infection; allowed file shares or management routes remain possible paths. Monitor inter-segment traffic and verify both permitted flows and denied workstation-to-workstation connections.

For the wider architecture, return to security controls, least privilege, and Zero Trust.

3. Access control and allowlisting

• Access control lists (ACLs) assign allow/deny permissions to resources or traffic. Ordered network ACLs commonly use first-match processing with an implicit deny; evaluation rules differ across platforms and filesystem permission models. Verify the effective policy and use a default-deny design.
• Permissions assign rights to users or groups on files, folders, and applications.
• Application allowlisting (formerly whitelisting) lets only approved programs run; everything else is blocked. Denylisting blocks known bad programs but misses new ones.

Allowlisting suits fixed-function systems with stable software. It limits unapproved execution but does not repair vulnerabilities in approved software or automatically prevent abuse of approved interpreters. Cover scripts and libraries where supported, monitor policy changes, and test compatibility before enforcement.

4. Patch management

Known, exploitable vulnerabilities create avoidable exposure when updates remain unapplied. Patch management is the disciplined process of identifying, testing, deploying, and verifying updates.

Patching applies to operating systems, applications, firmware, and third-party libraries. Emergency patching accelerates risk-based approval and testing when exploitation is active. Apply interim access restrictions where necessary; emergency handling does not mean deploying unverified changes without a recovery plan.

Connect prioritization to vulnerability scanning and remediation validation rather than treating the severity score as a complete risk assessment.

Worked example: prioritizing 400 findings

Scenario. A weekly scan reports 400 vulnerabilities: 20 critical, 80 high, 300 medium or lower. Operations can patch about 50 systems this week. Among the criticals, three are on internet-facing servers, and one of those three is listed in a government catalog of known exploited vulnerabilities.

Step by step.

1. Start with exploitation evidence: the known-exploited critical on an internet-facing server goes first, with an emergency change.
2. Next, exposure: the other two internet-facing criticals follow.
3. Then severity plus asset value: internal criticals on servers holding sensitive data, then highs.
4. Defer low-risk items into the normal monthly cycle.
5. Why not patch strictly by CVSS score? A high CVSS score on an isolated system with no exposure may be less urgent than a medium flaw under active attack on a public server. Context matters.
6. Why not wait for the maintenance window for everything? Active exploitation calls for urgent assessment, containment, and an accelerated change. There is no universally safe delay: use exposure, impact, vendor instructions, and applicable obligations.

5. Isolation, encryption, and monitoring

• Isolation: separating a risky system, whether physically or logically. Examples: quarantining an infected host, placing unsupported equipment in a restricted VLAN, running untrusted software in a sandbox.
• Encryption: select appropriate protection for stored data and network traffic. Ordinary disk encryption and TLS do not protect plaintext from an authorized or compromised running application. Protecting data during processing requires specialized designs and a defined threat model.
• Monitoring: logging and alerting (SIEM, intrusion detection) to detect misuse early. Monitoring is primarily detective; integrated response can trigger containment, which is a separate action.
• Least privilege: users, processes, and service accounts receive only the permissions they need. Includes regular access reviews and just-in-time elevation for administrators.

See encryption, signatures, and certificate trust for the guarantees and limits of cryptographic controls.

6. Configuration enforcement and baselines

A secure baseline is a documented, approved configuration for a system type. Configuration enforcement ensures systems keep to it.

• Group Policy applies policies in Windows environments; MDM manages supported Windows, macOS, and mobile settings according to each platform’s capabilities.
• Configuration management tools (such as Ansible or Puppet) define desired state as code and correct drift.
• Compliance scanning compares systems with benchmarks (CIS Benchmarks, vendor guides) and reports deviations.
• Infrastructure as code keeps configuration versioned and reviewable.

A short configuration example shows what hardening looks like on a Linux server (/etc/ssh/sshd_config):

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers deploy admin

This key-only example disables direct root login, password and keyboard-interactive authentication, and limits logins to two named accounts. It intentionally excludes keyboard-interactive MFA; adapt the policy if your environment requires it. Modern OpenSSH uses SSH protocol 2 without a Protocol 2 setting.

Before applying a similar policy, provision and test the authorized keys, preserve an administrative recovery path, and check the effective configuration, including included files and Match blocks. An administrator can check syntax with sshd -t and inspect effective settings with sshd -T. Test a new connection before closing an existing session. Enforcement should reconcile the effective policy after change review, rather than blindly rewriting a file.

7. Hardening techniques

Hardening reduces the attack surface of a system. Common techniques:

Example 2: hardening a new web server

Scenario. A company deploys a Linux web server in a DMZ. The default image has SSH on password authentication, an FTP service, a sample website, and the root account enabled for remote login.

Actions.

1. Disable FTP and uninstall the sample site (fewer services).
2. Configure SSH with key authentication and no root login.
3. Enable the host firewall to allow only ports 80/443 from the internet and 22 from the management network.
4. Install the monitoring agent and forward logs to the SIEM.
5. Apply the organization's baseline and record it as the approved build.

Each step maps directly to a hardening item the exam lists.

8. Decommissioning and compensating controls

Decommissioning removes systems safely: wipe or destroy storage, remove accounts and certificates, update the asset inventory, and revoke network access. A forgotten server still online is an easy target.

Compensating controls address the security objective when the primary control is not feasible. Assess their coverage and residual risk; they are not automatically equivalent or compliant with every external requirement. Examples:

An exception should be documented with the risk owner, the compensating control, and an expiry date.

9. Layering controls: a second worked example

Scenario. Litware Bank runs an internal HR application on a virtual machine. A penetration test shows three weaknesses: the VM is two minor versions behind on its web framework, any employee workstation can reach the database port directly, and the application's service account is a domain administrator. Leadership wants the biggest risk reduction with a two-week budget.

Step by step.

1. Rank by blast radius. The over-privileged service account is the largest multiplier: compromising the application would hand the attacker the entire domain. Reducing the account to the minimal database and file rights comes first.
2. Contain next. Add a firewall rule so that only the application server can reach the database port. This removes the direct path from workstations and is a configuration change that takes hours rather than weeks.
3. Patch third. Update the framework in a test environment, run the regression tests, then deploy during the window with a tested rollback and backup plan; a snapshot alone is not an independent backup. Patching matters, but the first two changes already reduce the damage if the flaw is exploited before the patch lands.
4. Verify and monitor. Rescan, review the rules, and forward the application logs to the SIEM, with alerts for service account logins from unusual hosts.
5. Why not buy a new intrusion detection system first? Detection does not remove the over-privileged account or the open database path. It would tell you about an attack on a flat, over-privileged design instead of preventing the damage.
6. Why not only patch? A fully patched application still runs as a domain administrator, and the next zero-day would have the same catastrophic impact.

Takeaway. Least privilege and segmentation are structural fixes that keep working when a patch is late or a zero-day appears, while patching removes a specific known weakness. The exam rewards candidates who combine them rather than relying on one.

Access control models in one table

In practice, RBAC provides least privilege at scale because you review roles instead of thousands of individual grants. ABAC adds context, such as allowing access only from a compliant, managed device during business hours.

10. Comparison: picking the right mitigation

11. Common pitfalls

• Choosing detection (monitoring, alerts) when the question asks for prevention.
• Recommending patching for systems with no available patch.
• Treating segmentation as a firewall only; without rules between segments, VLANs add little.
• Overlooking testing and rollback in patch questions.
• Confusing allowlisting (approve known good) with denylisting (block known bad).
• Hardening one system once and never verifying again; drift must be monitored.

12. Exam tips

• "Contain" or "limit lateral movement" suggests segmentation or isolation.
• "Legacy", "unsupported", or "cannot be updated" suggests a compensating control.
• "Only approved software" is allowlisting.
• "Ensure systems remain compliant with the baseline" is configuration enforcement.
• When the answer options include both a quick fix and a root-cause fix, the exam often favors the root cause if the scenario is not an emergency.

13. Mini case study

Case. Adatum Manufacturing runs a plant with a 15-year-old machine controller that cannot be patched and uses an unencrypted protocol. The plant network is connected to the office LAN, and a recent audit found that an engineer's laptop can reach the controller directly. The audit also found 45 servers with default administrator accounts enabled and no record of which servers are still in use.

Tasks. Recommend mitigations and justify them.

Solution.

1. Isolate the controller in its own OT segment, with filtering that allows necessary maintenance only from the controlled jump host and approved monitoring flows. Validate safety and vendor constraints before changes, and monitor unusual commands. This is a compensating control because patching is impossible.
2. Use a jump host with MFA for engineers, because the controller cannot support MFA itself.
3. Harden the servers by disabling unnecessary default accounts, replacing default passwords with unique managed credentials, applying the baseline, and enforcing it with configuration management. Renaming an account alone does not remove its privileges.
4. Inventory and decommission unused servers, wiping their storage and removing them from the network, because forgotten systems are unmonitored attack surface.
5. Document exceptions for the controller with an owner, a review date, and a replacement plan.

Key terms

• Segmentation / microsegmentation: dividing a network into controlled zones, at the workload level for microsegmentation.
• ACL: permissions or traffic rules whose evaluation semantics depend on the platform.
• Application allowlisting: only approved programs run.
• Patch management: inventory, prioritize, test, deploy, verify, roll back.
• Baseline / configuration enforcement: approved configuration and the mechanism that keeps it.
• Hardening: reducing attack surface by removing unnecessary services and defaults.
• Compensating control: alternative protection when the primary control is not feasible.
• Decommissioning: secure retirement of an asset.

Summary checklist

• I can explain how segmentation limits lateral movement and name the main techniques.
• I can distinguish allowlisting from denylisting.
• I can describe the patch management cycle, including testing and rollback.
• I can prioritize vulnerabilities using exposure and known exploitation, not only severity.
• I can list at least six hardening techniques.
• I can choose a compensating control for an unpatchable or unsupported system.
• I can explain why decommissioning matters for security.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objective 2.5.

• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: https://csrc.nist.gov/pubs/sp/800/40/r4/final (opens in a new tab)

• CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks (opens in a new tab)

• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (opens in a new tab)

• OpenSSH: sshd_config reference (opens in a new tab)

• OpenSSH 7.6 release notes: protocol 1 removal (opens in a new tab)

• CISA: ransomware prevention and response (opens in a new tab)