Vulnerability Mitigation

The Gap Between Finding and Fixing

Every organization runs vulnerability scans. Most produce reports that run to hundreds of pages. The scan is not the hard part. The hard part is deciding what to fix, in what order, with what urgency, and what to do when patching is not an option.

A vulnerability scanner tells you what is wrong. Vulnerability management tells you what to do about it — and in what order.

CISSP exam objective 3.5 focuses on assessing and mitigating vulnerabilities in security architectures. ISC2 expects you to understand vulnerability types across different technology domains, know the management lifecycle, and — most importantly — recognize when a compensating control is the right answer because patching is not available, not practical, or not safe.

Vulnerability Assessment

A vulnerability assessment identifies weaknesses in systems, applications, and configurations. It differs from a penetration test in a critical way: assessments identify vulnerabilities, while penetration tests attempt to exploit them.

Types of vulnerability assessments:

• Network-based scanning — Identifies open ports, running services, missing patches, and misconfigured protocols across network-connected devices
• Host-based scanning — Runs on individual systems with agent-based or credentialed access, providing deeper visibility into local configurations, file permissions, and registry settings
• Application scanning — Tests web applications, APIs, and custom software for injection flaws, authentication weaknesses, and business logic errors
• Database scanning — Evaluates database configurations, default accounts, excessive privileges, and unpatched database engines

Credentialed scans provide significantly more accurate results than uncredentialed scans. Without credentials, the scanner sees what an external attacker would see. With credentials, it sees what is actually running, installed, and configured — which is what matters for remediation decisions.

Common Vulnerability Types

Web Application Vulnerabilities (OWASP Top 10)

The OWASP Top 10 represents the most common web application security risks. For CISSP purposes, you need to understand the categories and their risk implications, not memorize exploit syntax:

• Broken Access Control — Users accessing resources or functions beyond their authorized permissions. This is the number one risk category because it represents a failure of the authorization model.
• Cryptographic Failures — Sensitive data exposed due to weak, missing, or improperly implemented encryption. Transmitting credentials over HTTP, storing passwords in plaintext, or using deprecated algorithms like MD5 for password hashing.
• Injection — Untrusted data sent to an interpreter as part of a command or query. SQL injection, LDAP injection, and OS command injection all share the same root cause: insufficient input validation.
• Insecure Design — Flaws in the architecture itself, not just the implementation. A password reset mechanism that relies solely on security questions is insecure by design, regardless of how well it is coded.
• Security Misconfiguration — Default credentials, unnecessary services enabled, verbose error messages, missing security headers. The easiest category to prevent and yet one of the most common.
• Vulnerable and Outdated Components — Using libraries, frameworks, or software with known vulnerabilities. Software composition analysis tools track these dependencies.
• Authentication and Session Management Failures — Weak passwords permitted, session tokens exposed in URLs, lack of multi-factor authentication for sensitive operations.

Client-Based Vulnerabilities

Client-side vulnerabilities exist on endpoints — workstations, laptops, browsers, and desktop applications:

• Browser vulnerabilities — Unpatched browsers, malicious extensions, cross-site scripting (XSS) rendering, and drive-by download exposure
• Email client vulnerabilities — Rendering of malicious HTML, attachment handling, link preview exploits
• Local privilege escalation — Misconfigurations or unpatched local services that allow a standard user to gain administrative access
• Third-party application flaws — PDF readers, office suites, media players — any software that processes untrusted input from external sources

Server-Based Vulnerabilities

Server-side vulnerabilities tend to have higher impact because servers typically process data for many users simultaneously:

• Unpatched services — Web servers, application servers, and middleware running with known vulnerabilities
• Misconfigured access controls — Administrative interfaces exposed to the internet, default credentials on management consoles
• Kernel vulnerabilities — Operating system flaws that enable remote code execution or privilege escalation at the system level
• API vulnerabilities — Broken object-level authorization, excessive data exposure, missing rate limiting on authentication endpoints

Database Vulnerabilities

Databases are high-value targets because they store concentrated collections of sensitive data:

• SQL injection — Still the most common database attack vector. Parameterized queries and stored procedures are the primary defense.
• Excessive privileges — Application accounts with DBA-level access when they only need read access to specific tables
• Unencrypted data at rest — Sensitive data stored without Transparent Data Encryption (TDE) or column-level encryption
• Default configurations — Default ports, default accounts, sample databases left in production environments
• Unaudited access — No logging of who queries what data, making it impossible to detect data exfiltration or unauthorized access patterns

Mobile Vulnerabilities

Mobile platforms introduce unique vulnerability categories:

• Insecure data storage — Sensitive data stored in plaintext on the device, accessible if the device is rooted/jailbroken or physically compromised
• Insecure communication — Applications that do not validate TLS certificates, allowing man-in-the-middle interception on untrusted networks
• Jailbreaking and rooting — Bypassing OS security controls exposes all application data to the device owner and any malware present
• Sideloading — Installing applications from outside official app stores bypasses the vetting process and introduces malware risk
• Excessive permissions — Applications requesting access to contacts, location, camera, or microphone without business justification

IoT and Embedded System Vulnerabilities

Internet of Things devices and embedded systems present some of the most difficult vulnerability management challenges:

• Default credentials — Many IoT devices ship with hardcoded or well-known credentials that owners never change
• No patch mechanism — Some devices have no firmware update capability, meaning vulnerabilities discovered after deployment cannot be fixed
• Weak or absent encryption — Many IoT protocols transmit data in cleartext or use deprecated cryptographic implementations
• Physical accessibility — Devices deployed in public or semi-public locations can be physically tampered with or removed for analysis
• Long deployment lifecycles — Industrial control systems and building automation devices may run for 15–20 years, far beyond the vendor’s support window
• Constrained resources — Limited CPU, memory, and storage prevent running security agents, endpoint protection, or complex encryption

The management challenge with IoT is that traditional vulnerability management workflows assume you can scan, patch, and reboot. Many IoT and OT devices cannot tolerate any of those actions without impacting the physical process they control.

The Vulnerability Management Lifecycle

Finding vulnerabilities is step one. Managing them over time requires a repeatable process:

1. Discover — Identify all assets and their configurations. You cannot assess what you do not know exists. Asset inventory (Module 15) feeds directly into vulnerability management.
2. Assess — Scan for vulnerabilities using automated tools, and supplement with manual testing where automated tools are insufficient (business logic flaws, for example).
3. Prioritize — Not all vulnerabilities are equal. Prioritization considers the CVSS score, the asset’s exposure (internet-facing vs. internal), the sensitivity of data processed, whether an exploit exists in the wild, and the business impact of the affected system.
4. Remediate — Apply patches, reconfigure systems, remove unnecessary services, or implement compensating controls. The remediation method depends on the vulnerability type and operational constraints.
5. Verify — Confirm that remediation was effective through re-scanning or targeted testing. A patch applied is not the same as a vulnerability fixed — configuration changes or reboots may be required.
6. Report — Communicate risk posture to management. Metrics should include time to remediate, percentage of critical vulnerabilities closed within SLA, and trending over time.

Patching Strategies

Patching is the primary remediation method for known vulnerabilities, but it is never as straightforward as “install the update.”

• Risk-based prioritization — Patch critical, internet-facing systems first. A CVSS 9.8 on an internal development server is lower priority than a CVSS 7.5 on a production web server.
• Testing before deployment — Patches can break functionality. A staged approach (test → pilot group → broad deployment) prevents organization-wide outages from a bad patch.
• Patch windows — Scheduled maintenance windows balance security urgency with business continuity. Emergency patches for actively exploited vulnerabilities may require accelerated timelines outside normal windows.
• Rollback planning — Every patch deployment should include a rollback plan in case the patch introduces instability or breaks critical functionality.
• Virtual patching — When a software patch is not yet available, web application firewalls (WAFs) or intrusion prevention systems (IPS) can block the specific exploit pattern while waiting for the vendor fix.

Compensating Controls

Sometimes patching is not possible. The system may be end-of-life with no vendor support. The patch may break a critical application. The device may not support updates. In these cases, compensating controls reduce the risk without addressing the underlying vulnerability:

• Network segmentation — Isolate the vulnerable system on a restricted network segment that limits who and what can reach it
• Enhanced monitoring — Increase logging and alerting for the vulnerable system to detect exploitation attempts
• Access restriction — Tighten access controls so only essential users and services can communicate with the vulnerable system
• Application-layer filtering — WAFs, IPS rules, or proxy-based filtering to block known exploit patterns
• Increased scan frequency — Scan the vulnerable system more frequently to detect any changes in its exposure or configuration
• Documented risk acceptance — When all compensating options are insufficient, management formally accepts the residual risk with a defined review timeline

The exam regularly presents scenarios where patching is not an option and asks for the best alternative. The answer is almost always the compensating control that most directly reduces the exploitability of the specific vulnerability.

Pattern Recognition

Vulnerability mitigation questions on the CISSP follow recognizable patterns:

• “Which vulnerability should be prioritized?” — Look for the combination of highest exploitability, most sensitive data, and greatest exposure (internet-facing wins over internal).
• “The vendor has no patch available” — The answer is a compensating control, not waiting. Network segmentation and enhanced monitoring are the most common correct answers.
• “What type of vulnerability is this?” — Map the described behavior to the category: input validation failure = injection, authorization bypass = broken access control, cleartext transmission = cryptographic failure.
• “Legacy/OT system cannot be patched” — Segmentation is nearly always the first step. These systems need to be isolated, not ignored.

Trap Patterns

Watch for these wrong answers:

• “Apply all patches immediately without testing” — Even critical patches need at minimum a compatibility check. The exam values a controlled process over speed.
• “Accept the risk until the vendor releases a patch” — Passive acceptance without compensating controls is almost never the right answer. Do something in the interim.
• “Replace the system immediately” — System replacement is a long-term strategy, not a mitigation response. The question usually asks for the immediate or first action.
• “The CVSS score alone determines priority” — Context matters. A CVSS 10 on an isolated test system may be lower priority than a CVSS 7 on a production system processing regulated data.

Scenario Practice

Question 1

A manufacturing company runs a SCADA system on Windows Server 2012 R2, which reached end of support in October 2023. The SCADA vendor states their application is not certified to run on any newer operating system. Vulnerability scans show 47 unpatched critical vulnerabilities on the server.

What is the BEST immediate mitigation strategy?

A. Replace the SCADA system with a vendor that supports current operating systems
B. Isolate the SCADA server on a dedicated network segment with strict firewall rules, enhanced monitoring, and restricted access
C. Apply the Windows patches despite lack of vendor certification
D. Shut down the SCADA system until a patching solution is available

Question 2

A vulnerability scan of a web application reveals SQL injection vulnerabilities. The development team estimates that a proper fix using parameterized queries will take three weeks. The application processes credit card data and is internet-facing.

What should the security team recommend while the code fix is in progress?

A. Take the application offline until the fix is deployed
B. Deploy a web application firewall rule to detect and block SQL injection attempts as a virtual patch
C. Notify customers that the application may be insecure and offer alternatives
D. Increase the frequency of vulnerability scans to weekly

Question 3

During a risk assessment, the security team identifies 1,200 vulnerabilities across the environment. Sixty are rated Critical, 300 are High, and the remainder are Medium and Low. Management asks how to allocate the limited patching resources for the month.

What approach should the security team recommend?

A. Patch all 60 Critical vulnerabilities first, then work through High vulnerabilities in order of CVSS score
B. Focus on the 60 Critical and 300 High vulnerabilities that affect internet-facing systems processing sensitive data first, then address internal systems
C. Distribute patching evenly across all severity levels to show consistent progress
D. Defer all patching until the next quarterly maintenance window to minimize business disruption

Key Takeaway

Vulnerability mitigation is a management problem wrapped in technical details. The exam does not test whether you can run a Nessus scan or write a WAF rule. It tests whether you can prioritize based on business risk, select the right mitigation when patching is not available, and build a lifecycle process that moves from discovery through verification without leaving gaps. When a scenario presents a system that cannot be patched, start with segmentation and monitoring. When it asks about prioritization, think exposure and data sensitivity before CVSS score.