This chapter covers compensating controls for unpatched vulnerabilities, a critical topic in vulnerability management (Objective 2.3 of the CS0-003 exam). You will learn how to apply alternative security measures when patching is not feasible, including isolation, access control lists, virtual patching, and configuration hardening. Approximately 10-15% of exam questions in the Vulnerability Management domain touch on compensating controls, often presenting scenarios where patching is delayed or impossible. Mastery of this topic is essential for the CySA+ exam and real-world security operations.
Jump to a section
Imagine a large office building with a state-of-the-art sprinkler system (the primary control). One day, a water main break forces the sprinklers offline. The building can't be evacuated, so they install temporary, high-capacity fire extinguishers at every exit and in every hallway. These extinguishers are compensating controls: they don't fix the sprinkler system, but they provide an alternative means of fire suppression. Each extinguisher is inspected daily, staff are trained to use them, and the building's fire alarm is reconfigured to alert the fire department immediately upon any smoke detection (increased monitoring). The extinguishers are placed to cover the same risk areas (fire) but with a different mechanism. Once the sprinklers are repaired, the extinguishers are removed. This mirrors how compensating controls work in cybersecurity: they are temporary or permanent alternative safeguards that mitigate risk when the primary control (like a patch) cannot be implemented, and they often involve additional monitoring, isolation, or manual processes to achieve an equivalent level of protection.
What Are Compensating Controls?
Compensating controls are alternative security measures implemented when a primary control (such as a security patch) cannot be applied due to operational, technical, or business constraints. They do not eliminate the vulnerability but reduce the risk of exploitation to an acceptable level. The key principle is that the compensating control must provide a level of security equivalent to or greater than the original control. For example, if a critical patch cannot be installed on a legacy server, a compensating control might involve placing the server behind a firewall with strict access controls, enabling enhanced logging, and deploying a host-based intrusion detection system (HIDS) to monitor for exploitation attempts.
Why Compensating Controls Are Needed
In an ideal world, all vulnerabilities would be patched immediately. However, real-world constraints include:
Patch incompatibility: A patch may break critical legacy applications.
Change management windows: Patches may require downtime that conflicts with business operations.
End-of-life systems: Vendors no longer provide patches for outdated software.
Regulatory compliance: Some environments require formal risk acceptance before patching.
Testing requirements: Patches must be validated in a staging environment before production deployment.
Compensating controls provide a risk mitigation path when patching is delayed or impossible. The CS0-003 exam expects you to identify appropriate compensating controls given a scenario.
Types of Compensating Controls
#### 1. Network Segmentation and Isolation
Placing vulnerable systems on a separate network segment with restricted access reduces the attack surface. For example, an unpatched web server can be moved to a DMZ with firewall rules that only allow necessary inbound traffic (e.g., TCP/80, TCP/443) and block all outbound connections to internal networks. This prevents lateral movement if the server is compromised.
Implementation details:
Use VLANs or separate physical switches.
Configure firewall rules to allow only specific source/destination IPs and ports.
Deny all traffic by default; permit only what is required.
Consider using a jump box for administrative access.
#### 2. Access Control Lists (ACLs)
ACLs on routers, firewalls, or host-based firewalls can restrict which IP addresses or users can reach the vulnerable service. For example, if a database server has an unpatched vulnerability in its management interface, an ACL can restrict access to only authorized administrative workstations.
Example ACL on a Cisco router:
access-list 100 permit tcp host 192.168.1.100 host 10.0.0.5 eq 1521
access-list 100 deny tcp any host 10.0.0.5 eq 1521
access-list 100 permit ip any any#### 3. Virtual Patching
Virtual patching uses a network or host-based intrusion prevention system (IPS/IDS) to detect and block exploit attempts targeting the unpatched vulnerability. It does not modify the vulnerable application but intercepts malicious traffic at the network layer.
How it works:
The IPS inspects packets for known exploit signatures (e.g., SQL injection patterns, buffer overflow payloads).
When a signature matches, the IPS drops the packet or resets the connection.
Virtual patches are often provided by security vendors (e.g., Snort, Suricata rules, or commercial IPS signatures).
Example Snort rule for a hypothetical vulnerability:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"Exploit Attempt"; content:"|41 42 43|"; sid:1000001; rev:1;)#### 4. Configuration Hardening
Disabling unnecessary services, changing default credentials, and reducing privileges can mitigate the risk of exploitation. For example, if a web server has an unpatched vulnerability in a specific module, disable that module or restrict its functionality.
Checklist:
Remove unused accounts.
Change default passwords.
Disable unused ports and services.
Enable logging and auditing.
Apply the principle of least privilege.
#### 5. Enhanced Monitoring and Logging
Increase the verbosity of logs and set up alerts for suspicious activity related to the vulnerability. This does not prevent exploitation but enables faster detection and response.
Implementation:
Enable detailed logging on the vulnerable service.
Forward logs to a SIEM (e.g., Splunk, ELK).
Create alert rules for known exploit indicators.
Set up automated incident response playbooks.
#### 6. Application Whitelisting
Only allow known good applications to execute. If an exploit attempts to drop a malicious binary, the whitelisting policy blocks it. This is particularly effective against zero-day exploits.
Example: Use Windows AppLocker or Linux SELinux to enforce execution policies.
#### 7. Multi-Factor Authentication (MFA)
If a vulnerability allows unauthorized access, MFA adds an additional authentication factor, reducing the likelihood of successful exploitation.
Selecting Compensating Controls
The CS0-003 exam emphasizes that compensating controls must be equivalent or better than the missing primary control. Consider:
Risk reduction: Does the compensating control reduce risk to an acceptable level?
Cost and complexity: Is it feasible to implement?
Operational impact: Does it affect system performance or usability?
Duration: Is it temporary (until patching) or permanent?
Documentation and Approval
Compensating controls must be formally documented and approved by management. The documentation should include:
The vulnerability and why patching is not feasible.
The compensating control implemented.
How the control mitigates the risk.
Testing results showing effectiveness.
A timeline for eventual patching (if temporary).
Common Pitfalls
Over-reliance on a single compensating control: Layering multiple controls is more effective.
Ignoring the human factor: Training users about the vulnerability and compensating controls is essential.
Failing to monitor: Compensating controls must be monitored continuously to ensure they remain effective.
Exam Focus
The CySA+ CS0-003 exam may present a scenario where a system cannot be patched and ask which compensating control is most appropriate. Look for keywords like "legacy," "end-of-life," "downtime not allowed," or "patch breaks application." The correct answer often involves isolation, ACLs, or virtual patching. Be prepared to distinguish between compensating controls and other risk management strategies like risk acceptance or risk transference.
Identify unpatched vulnerability
Begin by identifying a vulnerability that cannot be patched. This may come from a vulnerability scan, penetration test, or security advisory. Document the CVE identifier, CVSS score, affected systems, and the reason patching is not feasible (e.g., no patch available, operational constraints). For example, CVE-2023-1234 affects an internal web application that cannot be taken offline. This step sets the scope for compensating control selection.
Assess risk and impact
Evaluate the likelihood of exploitation and the potential impact on confidentiality, integrity, and availability. Consider factors like exposure to the internet, user privileges required, and whether exploit code is publicly available. For a critical vulnerability with a CVSS score of 9.0 and public exploit code, the risk is high. This assessment justifies the need for compensating controls and helps prioritize resources.
Select compensating controls
Choose one or more compensating controls that reduce risk to an acceptable level. For example, if the vulnerable system is a legacy database accessible only from internal IPs, implement ACLs on the firewall to restrict access to only authorized admin workstations. Additionally, enable detailed logging and set up SIEM alerts for any access attempts. The selection must be documented with rationale and expected risk reduction.
Implement and test controls
Deploy the compensating controls in a test environment first. For ACLs, configure the firewall rules and verify that legitimate traffic is allowed and unauthorized traffic is blocked. For virtual patching, test the IPS rules against known exploit payloads to ensure they detect and block without false positives. Document the testing results and adjust as needed. Once validated, implement in production during a change window.
Monitor and maintain
After implementation, continuously monitor the compensating controls. Review logs daily for any attempted exploitation. Ensure the IPS rules are updated to cover new variants. Periodically reassess the risk if the vulnerability becomes more critical (e.g., exploit code released). If a patch becomes available later, plan to apply it and remove the compensating controls. Document the entire process for audit and compliance.
Enterprise Scenario 1: Legacy ERP System
A large manufacturing company runs an ERP system from a vendor that went bankrupt. A critical remote code execution vulnerability (CVE-2022-1234) is discovered, but no patch exists. The system handles production scheduling and cannot be taken offline. The security team implements a compensating control by isolating the ERP server in a separate VLAN with a strict firewall rule allowing only the specific IP addresses of the scheduling workstations (TCP/1433 for SQL traffic). They also deploy a host-based IPS (e.g., OSSEC) on the server to monitor for exploit patterns and block suspicious outbound connections. Logs are forwarded to a SIEM with an alert for any connection attempts from unknown IPs. This reduces the attack surface significantly. The compensating control is documented and approved by the CISO. The system remains operational while the company transitions to a new ERP system over the next 18 months.
Enterprise Scenario 2: End-of-Life Web Server
A financial services firm has an end-of-life web server (Windows Server 2008) that hosts a critical customer portal. The server cannot be upgraded due to a legacy application dependency. The vulnerability scanner reports multiple critical vulnerabilities with no patches available. The team implements a compensating control by placing the server behind a web application firewall (WAF) with custom rules to block known exploit patterns (e.g., SQL injection, directory traversal). They also enforce strict network segmentation: the server is in a DMZ, and outbound traffic is limited to only required updates to a specific internal patch server. Additionally, they implement application whitelisting to prevent unauthorized executables. The server is monitored 24/7 with automated alerts for any anomaly. The compensating controls are tested quarterly to ensure effectiveness. After two years, the legacy application is retired and the server is decommissioned.
Common Issues
Performance impact: Virtual patching can introduce latency; ensure the IPS is sized appropriately.
False positives: Overly broad rules may block legitimate traffic; fine-tune rules based on baseline traffic.
Configuration drift: Compensating controls may be inadvertently removed during maintenance; enforce change management.
Lack of monitoring: Even the best compensating control is useless if not monitored; assign responsibility for daily log review.
The CS0-003 exam tests compensating controls under Objective 2.3: 'Given a scenario, implement compensating controls for unpatched vulnerabilities.' Expect scenario-based questions where patching is not an option due to legacy systems, operational constraints, or end-of-life software. The most common wrong answer is 'apply the patch anyway' or 'ignore the vulnerability' — these violate the scenario premise. Another trap is selecting 'risk acceptance' when a compensating control is specifically required; risk acceptance is a management decision, not a technical control.
Key terms to know: - Virtual patching: Using IPS/IDS to block exploit traffic. - Network segmentation: Isolating vulnerable systems. - ACLs: Restricting access by IP/port. - Application whitelisting: Allowing only approved executables. - Configuration hardening: Disabling unnecessary services.
Exam loves to test the difference between compensating controls and other risk responses. For example, if a critical vulnerability exists and patching is delayed, the correct answer might be 'implement an ACL to restrict access to the vulnerable service' rather than 'accept the risk' or 'transfer the risk via cyber insurance.'
Also be aware of PCI DSS requirement for compensating controls: they must be 'generally as secure as or more secure than the original requirement.' While not explicitly on CySA+, this principle is implied.
Numbers: CVSS scores above 7.0 are considered high/critical; compensating controls are often required for such scores. The exam may ask about default ports for services (e.g., TCP/3389 for RDP) when configuring ACLs.
Edge cases: When a vulnerability is in a third-party component (e.g., OpenSSL), patching may require vendor coordination; compensating controls like WAF rules are appropriate. For zero-day vulnerabilities with no patch, virtual patching is often the only option.
Eliminate wrong answers by asking: Does this control reduce risk? Is it feasible given the scenario constraints? Does it directly address the vulnerability? For example, 'encrypting data at rest' does not compensate for a remote code execution vulnerability — it does not prevent exploitation.
Compensating controls are alternative safeguards when patching is not possible.
They must provide equivalent or better security than the missing patch.
Common types: network segmentation, ACLs, virtual patching, configuration hardening, enhanced monitoring, application whitelisting, MFA.
Document all compensating controls with rationale, testing results, and approval.
On the exam, select compensating controls that directly reduce the risk of the specific vulnerability.
Risk acceptance is not a compensating control; it is a management decision.
Virtual patching uses IPS/IDS to block exploit traffic without modifying the vulnerable application.
Network segmentation is often the most effective compensating control for legacy systems.
Compensating controls must be continuously monitored and maintained.
Temporary compensating controls should include a plan for eventual patching.
These come up on the exam all the time. Here's how to tell them apart.
Virtual Patching
Blocks exploit traffic at the network layer using IPS signatures.
Does not require changes to the vulnerable system.
Can be deployed quickly and updated easily.
May introduce latency and false positives.
Effective for known exploits but not zero-day variants.
Network Segmentation
Isolates the vulnerable system to a separate network segment.
Reduces attack surface by limiting connectivity.
Requires network reconfiguration and possibly new hardware.
Minimal performance impact on the vulnerable system.
Effective against all attacks by limiting access.
Mistake
Compensating controls are only temporary.
Correct
While often temporary, compensating controls can be permanent if the vulnerability cannot be patched (e.g., end-of-life systems). The key is that they provide equivalent security.
Mistake
Any security control can serve as a compensating control.
Correct
Compensating controls must specifically address the risk of the unpatched vulnerability. For example, adding a firewall does not compensate for a SQL injection vulnerability unless the firewall includes a WAF or ACL that blocks malicious input.
Mistake
Risk acceptance is the same as a compensating control.
Correct
Risk acceptance is a management decision to tolerate the risk without implementing additional controls. Compensating controls actively reduce risk. The exam distinguishes between these responses.
Mistake
Virtual patching eliminates the vulnerability.
Correct
Virtual patching does not fix the underlying code; it only blocks known exploit patterns. New exploit variants may bypass it. It is a mitigation, not a remediation.
Mistake
Compensating controls are always less secure than patching.
Correct
In some cases, compensating controls can provide equal or greater security. For example, isolating a legacy system behind a strict firewall may be more secure than applying a patch that introduces new bugs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A remediation fixes the vulnerability (e.g., applying a patch). A compensating control does not fix the vulnerability but reduces the risk of exploitation (e.g., blocking access to the vulnerable service). Remediation is preferred, but compensating controls are used when remediation is not feasible. On the exam, if the scenario says 'cannot patch,' choose a compensating control, not a remediation.
Yes, many compliance frameworks (e.g., PCI DSS, HIPAA) allow compensating controls if the primary control cannot be met. However, the compensating control must be documented and approved, and it must provide equivalent security. For example, PCI DSS Requirement 6.2 (patch management) allows compensating controls if patching is not possible.
If a web application has an unpatched SQL injection vulnerability and the code cannot be fixed immediately, a compensating control could be a web application firewall (WAF) with rules to block SQL injection patterns (e.g., 'OR 1=1'). Alternatively, input validation at the network level could be implemented. This does not fix the code but prevents exploitation.
Consider effectiveness, cost, operational impact, and duration. For a critical vulnerability exposed to the internet, network segmentation plus virtual patching is stronger than just logging. The exam expects you to select the most appropriate control based on the scenario. Look for keywords like 'internal system' (ACLs may suffice) or 'internet-facing' (WAF or IPS).
No. Risk acceptance is a management decision to accept the risk without implementing additional controls. Compensating controls actively reduce risk. The exam will test this distinction. If the scenario says 'implement a compensating control,' risk acceptance is not a valid answer.
Documentation should include: the vulnerability (CVE, CVSS), reason patching is not feasible, the compensating control implemented, how it reduces risk, testing results, approval from management, and a timeline for eventual patching (if temporary). This is important for audits and compliance.
Yes. If a vulnerability allows arbitrary code execution, application whitelisting prevents unauthorized executables from running. This is an effective compensating control for zero-day exploits. For example, Windows AppLocker can block execution of malware dropped by the exploit.
You've just covered Compensating Controls for Unpatched Vulnerabilities — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?