Vulnerability Management practice questions

Remediation

Why it fails: Remediation is the phase where identified vulnerabilities are actively addressed and mitigated. This involves implementing patches, reconfiguring systems, updating software, or deploying compensating controls to eliminate or reduce the risk posed by the vulnerability. Running a scan and reviewing results are preparatory steps to identify what needs fixing, not the act of fixing itself.

Discovery

Why it fails: Discovery is the initial phase in a vulnerability assessment where security analysts actively identify potential weaknesses and exposures within systems, applications, or networks. This process typically involves utilizing automated vulnerability scanners to probe targets for known vulnerabilities, misconfigurations, and outdated software, followed by a thorough review and analysis of the scan results to confirm findings.

Verification

Why it fails: Verification is the post-remediation step where security analysts confirm that the applied fixes have successfully mitigated the identified vulnerabilities and have not introduced new issues. This often involves re-running vulnerability scans or conducting targeted tests against the remediated systems to ensure the controls are effective and the original vulnerability no longer exists. It is a follow-up to remediation, not the initial discovery.

Cross-Site Scripting (XSS)

Why it fails: Reflected XSS occurs when an application receives untrusted data in an HTTP request and includes it within the immediate response without proper validation or escaping. DAST tools actively test for this by injecting payloads into input fields and observing if they execute in the browser. While historically grouped with injection, XSS remains a distinct, highly prevalent vulnerability category within modern web security frameworks.

Broken Access Control

Why it fails: Broken Access Control refers to failures in enforcing restrictions on what authenticated users are allowed to do, such as accessing unauthorized files, accounts, or administrative functions. This vulnerability involves privilege escalation or bypass of authorization checks, which is fundamentally different from the reflection of unescaped input back to a user's browser.

Security Misconfiguration

Why it fails: Security Misconfiguration occurs when security settings are not defined, implemented, or maintained correctly, such as leaving default accounts active, enabling unnecessary services, or failing to set secure HTTP headers. While missing security headers (like Content Security Policy) can exacerbate XSS, the core vulnerability of reflecting unvalidated input is a code-level flaw rather than a configuration error.

CIS Level 3 Benchmark

Why it fails: CIS Benchmarks define only two implementation levels for any given platform, Level 1 and Level 2, so a Level 3 designation does not exist in the CIS framework and cannot be selected as a scanning profile for any environment.

CIS Level 0 Benchmark

Why it fails: There is no Level 0 profile in the CIS Benchmark structure; CIS defines only Level 1, covering basic hygiene, and Level 2, covering advanced defense-in-depth controls, so a Level 0 designation is fabricated and not a valid scanning target.

Scope (S)

Why it fails: Scope (S) is a CVSS base metric that captures whether a vulnerability can cause impact beyond the security authority of the vulnerable component, such as affecting a different security domain. It is not an impact metric itself because it does not measure the direct consequence on data or system; instead, it modifies how the confidentiality, integrity, and availability impacts are scored when the scope changes. The CVSS specification categorizes S as a separate metric, so it cannot be classified as an impact metric.

Attack Vector (AV)

Why it fails: Attack Vector (AV) is an exploitability metric in the CVSS base score that describes the level of access an attacker needs to exploit the vulnerability, ranging from Network (AV:N) to Physical (AV:P). It is not an impact metric because it focuses on the conditions required to launch the attack, not the outcome or damage caused after exploitation, such as data loss or system compromise.

A08:2021 – Software and Data Integrity Failures

Why it fails: Software and Data Integrity Failures cover issues like unsigned software updates, insecure CI/CD pipelines, or deserialization of untrusted data that alters application logic or artifacts, none of which describes a URL parameter simply redirecting a browser to attacker-chosen infrastructure.

A03:2021 – Injection

Why it fails: Injection flaws occur when untrusted input is interpreted as commands or queries by an interpreter, such as SQL, OS commands, or LDAP, causing the backend to execute attacker-supplied code; an open redirect never gets parsed as executable syntax, it is merely echoed into a Location header.

A01:2021 – Broken Access Control

Why it fails: Broken Access Control describes failures in enforcing what an authenticated or unauthenticated user is permitted to do or view, such as bypassing authorization checks; an open redirect does not grant unauthorized access to resources, it only manipulates where the browser navigates next.

Buffer overflow

Why it fails: Buffer overflow: Buffer overflows are a memory-corruption vulnerability that occurs in native code (e.g., C/C++) when data exceeds a buffer's boundary, potentially overwriting adjacent memory. Web applications built on managed languages (Java, .NET, Python) typically prevent this, and Burp Suite operates at the HTTP layer, making it unable to directly exploit or detect memory-level flaws. While a web application could call a vulnerable native library, this is not a standard web vulnerability and is far less relevant to Burp's testing focus than input-based issues.

Insecure deserialization

Why it fails: Insecure deserialization: Insecure deserialization occurs when an application deserializes untrusted data, allowing an attacker to manipulate object fields or trigger code execution. Burp Suite can test for this by sending crafted serialized payloads (e.g., Java, PHP, .NET), but it is less common than SQLi/XSS and requires deep knowledge of the application's internal classes. Burp's automated scanner is not specifically tuned to detect deserialization flaws as reliably as it does for injection attacks, so this is not a primary finding in routine web testing.

Race condition

Why it fails: Race condition: A race condition is a concurrency flaw where the outcome of a system depends on the timing of multiple processes, leading to unexpected behavior such as unauthorized transactions or data corruption. Burp Suite's core functionality focuses on HTTP message manipulation, session handling, and fuzzing, but it does not natively orchestrate simultaneous requests with precise timing to trigger race windows. While tools like Burp's Turbo Intruder can send concurrent requests, detecting a subtle race condition requires analyzing server-side state, which is not a standard scanner feature, making it rarely a direct finding.

Nessus

Why it fails: While Tenable Nessus is an industry-standard vulnerability assessment tool used to identify software flaws and missing patches, it is not primarily designed as a dedicated multi-cloud compliance and configuration auditor. It focuses on network-based and agent-based vulnerability scanning rather than specialized cloud infrastructure benchmark auditing.

Qualys

Why it fails: Qualys is a comprehensive enterprise vulnerability management platform that offers cloud security modules, but it is not the primary tool for direct CIS benchmark auditing of cloud control planes. Its architecture relies heavily on agents and network appliances, making it less optimal for rapid, native multi-cloud configuration assessments compared to dedicated auditing tools.

Wireshark

Why it fails: Wireshark is a deep packet inspection and network protocol analyzer used to capture and troubleshoot live network traffic. It does not possess the capability to scan systems for software vulnerabilities, evaluate system configurations, or audit cloud environments against compliance frameworks like CIS benchmarks.

Broken Access Control

Why it fails: Broken Access Control is a separate vulnerability category, not an injection flaw. It arises when an application fails to enforce restrictions on what authenticated users can access or do, such as viewing other users' private data or performing unauthorized functions. Unlike injection attacks, it does not involve sending malicious interpretable code; instead, it relies on manipulating requests, URLs, or client-side state to bypass authorization checks.

Security Misconfiguration

Why it fails: Security Misconfiguration is a separate vulnerability category and not an injection flaw. It results from insecure default configurations, incomplete setups, open cloud storage, verbose error messages, or unnecessary enabled features. This category does not involve injecting malicious input into an interpreter; rather, it happens because the application or its environment is not securely configured, leaving doors open for various types of attacks.

Upgrade to SMB version 3.0 which has built-in signing

Why it fails: Upgrading to SMBv3 does not resolve the underlying issue if enforcing packet signing is deemed unfeasible due to legacy client compatibility or performance constraints. Furthermore, simply upgrading the protocol version does not automatically enforce signing if the active group policies or registry configurations still permit unsigned connections.

Accept the risk and document the decision

Why it fails: Accepting and documenting the risk is a passive approach that should only be utilized as a last resort when no viable mitigation options exist. In this scenario, active compensating controls can and should be implemented to reduce the attack surface rather than leaving the vulnerability completely unaddressed.

Apply a host-based firewall rule to block SMB traffic from all sources

Why it fails: Blocking all inbound SMB traffic at the host-based firewall would render the file server completely non-functional for legitimate clients. While this action would technically eliminate the vulnerability, it violates the core security principle of availability by preventing authorized users from accessing necessary network shares.

Root account has MFA enabled

Why it fails: Enabling multi-factor authentication (MFA) on the root user account is a mandatory security best practice and explicitly required by the CIS AWS Foundations Benchmark. The absence of MFA on the root account is a critical finding; conversely, its presence indicates that the account is protected against unauthorized use, especially since root credentials cannot be scoped down by IAM policies. Therefore, this is not a violation.

Full connect scan

Why it fails: A TCP connect scan completes the full three-way handshake by sending a final ACK packet to the target port. Because the connection is fully established, the target operating system typically logs the connection, making this scan highly visible to intrusion detection systems and potentially disruptive to fragile services.

UDP scan

Why it fails: A UDP scan targets connectionless ports by sending empty UDP packets and waiting for ICMP port unreachable messages. This technique is notoriously slow and unreliable due to rate-limiting by target firewalls and routers, making it unsuitable for rapid or stealthy initial port discovery.

Ping sweep

Why it fails: A ping sweep utilizes ICMP echo requests and TCP/UDP discovery packets to determine which IP addresses are active on a subnet. While highly efficient for mapping live hosts, it does not perform port scanning or identify specific listening services, which is required for a comprehensive vulnerability assessment.

Cross-Site Request Forgery (CSRF)

Why it fails: Cross-Site Request Forgery (CSRF) is a web application attack that exploits the implicit trust a site has in a user's browser session cookies to submit forged state-changing requests. Modern APIs, however, typically employ stateless authentication mechanisms such as Bearer tokens, API keys, or JWTs that are not automatically attached by the browser, so CSRF has little applicability to API testing unless the API uses cookie-based sessions and lacks CSRF tokens. It is not an API-specific OWASP category, whereas Excessive Data Exposure directly addresses typical API response handling.

Wait for the next scheduled rebuild cycle to patch the base image.

Why it fails: Waiting for the next scheduled rebuild cycle introduces unacceptable risk when dealing with a high Exploit Prediction Scoring System (EPSS) score. Because EPSS indicates a high probability of imminent exploitation in the wild, security teams must prioritize immediate remediation rather than adhering to standard, non-urgent patch management schedules.

Apply a hotfix or workaround to the affected package in running containers.

Why it fails: Applying a hotfix or temporary workaround directly to the affected package or runtime environment provides immediate mitigation against active threats. This tactical response reduces the attack surface instantly, buying the security and development teams valuable time to properly test, rebuild, and redeploy the patched container image through the standard CI/CD pipeline.

Remove all containers using the vulnerable base image immediately.

Why it fails: Immediately tearing down all running containers utilizing the vulnerable base image is highly disruptive and violates availability requirements. This drastic action can trigger a self-inflicted denial-of-service (DoS) condition for critical business applications, making it an unacceptable response compared to applying targeted, non-disruptive hotfixes or workarounds.

Remove all unnecessary packages and services

Why it fails: Removing all unnecessary packages and services is a sound hardening practice that reduces the attack surface, but it is typically categorized as Level 2 in the CIS Benchmarks. This is because the removal process can break expected functionality if an application relies on a particular package or daemon, requiring thorough business impact analysis and testing. Level 1 controls are intended to be low-impact, universally applicable security settings, so this action does not qualify as a Level 1 baseline.

Enable mandatory access control (SELinux) in enforcing mode

Why it fails: Enabling SELinux in enforcing mode provides strong mandatory access control, but it is commonly relegated to Level 2 because enforcing mode can deny legitimate application operations when policies are not fully tuned, potentially causing service outages. This requires significant policy customization and testing for each environment, making it disruptive for organizations not already prepared. A Level 1 control must be deployable with minimal operational friction, which enforcing mode does not always offer, so it is not the correct choice here.

Configure audit rules for file permission changes

Why it fails: Configuring audit rules to monitor file permission changes is a powerful forensic control, but it is generally assigned to Level 2 in the CIS Benchmarks. The reason is that extensive audit logging can generate large volumes of data, increasing storage costs and potentially causing performance degradation on busy systems. Additionally, the rule sets are highly site-specific—organizations may need to tailor them to their own compliance requirements—so they are not a uniform, low-impact Level 1 setting.

Allow automatic logon with empty password

Why it fails: Allowing automatic logon with an empty password is explicitly forbidden by Windows security baselines and STIGs because it grants any user unattended access to the system without presenting credentials. The 'AutoAdminLogon' registry setting, combined with an empty password, effectively bypasses the entire authentication mechanism and leaves the host open to local privilege escalation. STIGs require that interactive logons always demand a password, and this setting must be disabled or removed. A compliance scan would flag this as a critical vulnerability because it directly undermines access control.

Disable audit log generation for failed logins

Why it fails: Disabling audit log generation for failed logins violates STIG requirements because the absence of failed-logon events prevents security analysts from detecting brute-force attacks, credential stuffing, or unauthorized access attempts. STIGs mandate that the 'Audit Logon' policy be configured to record both successes and failures, capturing event ID 4625 for failed logons. Without this audit trail, incident response teams lose critical forensic evidence, and the system fails to meet compliance with DoD security requirements. Additionally, disabling audit generation itself is a finding, as it indicates a deliberate evasion of accountability.

Enable SMBv1 protocol for compatibility

Why it fails: Enabling SMBv1 protocol for compatibility is a flagrant STIG violation because SMBv1 is a legacy protocol that contains known vulnerabilities, including EternalBlue (MS17-010), which facilitated ransomware propagation like WannaCry. STIGs explicitly require SMBv1 to be either removed or disabled in favor of SMBv2 or SMBv3, which offer stronger encryption and security mechanisms. The 'SMB1Protocol' feature and its associated registry key 'SMB1' must be set to 0 to disable it, and a compliance scan will report any system with SMBv1 active as high-risk. Even if legacy devices require it, the DoD mandate supersedes compatibility, and exceptions must be formally approved via a Waiver.

Number of affected assets

Why it fails: Number of affected assets is a contextual risk factor, but it does not estimate the likelihood of exploitation. A vulnerability present on thousands of hosts may be a low priority if no exploit exists, while a single actively exploited host demands immediate action. Standardized prioritization frameworks like EPSS and KEV focus on exploit probability and confirmed activity, not merely the breadth of exposure. Asset count also ignores business criticality, making it an unreliable basis for ranking vulnerabilities.

Vulnerability publication date

Why it fails: Vulnerability publication date is a poor prioritization signal because disclosure does not equate to exploitability. Some published vulnerabilities never gain weaponized exploits, while others are exploited within hours of disclosure, as seen with zero-days. EPSS specifically uses threat intelligence and exploit evidence rather than the date of publication, and KEV lists only vulnerabilities with confirmed active exploitation. Prioritizing by age alone would misguide remediation efforts, especially for older vulnerabilities that remain unexpired.

Vendor patch availability

Why it fails: Vendor patch availability indicates how remediation can be performed, not whether a vulnerability is likely to be exploited. A patch may exist but be ineffective, untested, or deferred due to operational risk, and many unpatched vulnerabilities are never exploited. Prioritization should be driven by threat context, such as EPSS scores and KEV listings, while patch availability is relevant only after a vulnerability is selected for remediation. In the case of zero-days without patches, availability is lacking yet the priority is highest.

Inject a payload such as ' OR '1'='1 to test for authentication bypass and confirm the vulnerability.

Why it fails: This payload is a classic authentication bypass technique, but it does not confirm SQL injection in a way that distinguishes it from other issues. It may simply log in if the query is vulnerable, but it does not demonstrate the ability to extract data, and it could be blocked by input validation. The error message already suggests SQL injection; a more definitive confirmation is needed.

Use a time-based blind SQL injection payload to cause a delay, confirming the vulnerability without relying on error messages.

Why it fails: Time-based blind SQL injection is useful when error messages are not displayed, but here the application already returns detailed database errors. Using a blind technique would be unnecessarily slow and complex. The tester should leverage the visible error to confirm and exploit the vulnerability more efficiently and reliably.

Use sqlmap with the --batch option to automatically detect and exploit the SQL injection.

Why it fails: sqlmap is a powerful tool for automating SQL injection detection and exploitation, and --batch would run it non-interactively. However, the question asks for the NEXT step after observing a potential injection point with an error message. Jumping straight to automated exploitation without first confirming the vulnerability manually could produce false positives or miss context. The NEXT step should be manual confirmation, not immediate automation.

The credentialed scan detected a vulnerability in a different library that shares the same CVE identifier.

Why it fails: This is speculative and not supported by the scenario. The analyst specifically noted the latest cumulative updates are installed, which would remediate the flagged Microsoft library. A CVE identifier is unique to a specific vulnerability, so sharing with a different library is incorrect. The more plausible explanation is outdated scanner plugins causing a false positive.

The unauthenticated scan cannot see the vulnerability because it lacks credentials to perform local checks.

Why it fails: While unauthenticated scans indeed lack local access, the scenario states the host has the latest cumulative updates, meaning the vulnerability should not be present. The credentialed scan's false positive is the real issue. The unauthenticated scan's inability to see local details would cause a false negative, not explain why the credentialed scan flagged a patched system.

The vulnerability is a false positive in the unauthenticated scan due to network-based detection limitations.

Why it fails: The unauthenticated scan did not report the vulnerability, so it is not a false positive there. The discrepancy is that the credentialed scan reported a vulnerability that likely does not exist because the system is patched. The unauthenticated scan simply missed it due to lack of access, which aligns with its limitations.

Authenticated scan

Why it fails: Authenticated scans log into the application and may perform actions that modify data, depending on the scanner's configuration. They are not specifically designed to be non-intrusive. While they can find SQL injection and XSS, they might alter data if not carefully configured, violating the requirement. The scenario requires a scan that does not modify data, so a non-intrusive scan is more appropriate.

Intrusive scan

Why it fails: Intrusive scans actively send malicious payloads to exploit vulnerabilities, which can modify or delete data. This directly violates the requirement to not modify data. Although they are effective at finding SQL injection and XSS, they are unsafe for production environments where data integrity must be preserved. The analyst should choose a non-intrusive scan instead.

Unauthenticated scan

Why it fails: Unauthenticated scans do not log in, but they can still send malicious payloads that might modify data if the application is vulnerable. They are not inherently non-intrusive. The requirement is to avoid data modification, which is best achieved with a scan that only analyzes responses without sending destructive payloads. Unauthenticated scans may still be intrusive if they test for SQL injection by inserting data.

Vendor patch release date

Why it fails: Vendor patch release date indicates when a fix became available, but it does not directly help prioritize based on risk. A patch may be released quickly but not widely exploited. The analyst should prioritize based on severity and exploit likelihood. Patch release date could inform urgency if exploitation is active, but it is not a primary factor compared to CVSS and EPSS.

Asset criticality rating

Why it fails: Asset criticality rating is indeed important for prioritization, but the question asks for two factors to consider. In this scenario, the analyst should consider asset criticality to weigh the impact of a compromised asset. However, since the question is multi-select and the correct answers are CVSS and EPSS, asset criticality is not selected here. It is still a valuable factor, but the combination of CVSS and EPSS directly addresses severity and threat likelihood.

Number of open ports on the asset

Why it fails: The number of open ports is not a direct factor in vulnerability prioritization. While it may indicate exposure, it does not reflect the severity or exploitability of specific vulnerabilities. The analyst should focus on CVSS, EPSS, and asset criticality. Open ports could be relevant for attack surface but are not a primary prioritization metric in this context.