CCNA Cysa Vulnerability Management Questions

The CISA KEV catalog's defining criterion is real-world exploitation evidence; CISA adds a CVE only after confirming it has been actively exploited in the wild, which is why federal agencies under Binding Operational Directive 22-01 must remediate KEV-listed vulnerabilities on an accelerated timeline regardless of their CVSS score.

Server-Side Request Forgery (SSRF) occurs when a web application fetches a remote resource without validating the user-supplied URL. This allows an attacker to coerce the vulnerable server into sending crafted requests to internal-only resources, such as loopback interfaces, local databases, or cloud metadata endpoints (like AWS IMDSv1), effectively bypassing perimeter firewalls.

Staging environments often mirror production configurations and may reside on networks with access to sensitive internal resources or active directory domains. Patching this vulnerability immediately is critical because an attacker could exploit the staging server to establish a foothold and perform lateral movement across the corporate network.

The A component of the CVSS v3.1 vector is H, which is the Availability Impact metric and indicates that the exploit can cause a total loss of availability, such as a denial of service. Unlike the C and I metrics, which are both N, the A metric is the only one rated high, so this option correctly identifies the finding's high impact on availability.

Verbose error messages, such as stack traces or database debugging information returned by an API endpoint, represent a classic security misconfiguration. Properly configuring the application server to suppress detailed debugging outputs and return generic error messages prevents attackers from mapping the internal architecture and finding exploitable vectors.

Attack Vector (AV) is a base metric that describes the context by which a vulnerability can be exploited, such as network, adjacent, local, or physical. This metric directly influences the CVSS exploitability subscore and is fundamental because it determines the remote vs. local nature of the attack. A network attack vector is typically the most severe because it allows exploitation from anywhere on the internet without prior access.

Updating the Active Directory Group Policy Objects (GPOs) to enforce the disabled state of the guest account ensures centralized, automated remediation across all target systems. This approach establishes a permanent configuration baseline that actively prevents configuration drift, aligning the environment with the required STIG profile validated by OpenSCAP.

This option aligns with established security best practices by ensuring the patch is first validated for efficacy and stability on test systems before proceeding. Utilizing the organization's formal change management process ensures that the production rollout is coordinated, scheduled during maintenance windows, documented, and equipped with a rollback plan to minimize operational impact.

Applying a workaround as a compensating control is the most appropriate immediate action when a critical vulnerability is discovered and a vendor patch is not yet available. A compensating control is an alternative security measure that reduces the risk to an acceptable level until a permanent solution can be implemented. This approach effectively mitigates the immediate threat without causing undue operational disruption, balancing security with business continuity.

HostPath mounts allow a pod to mount an arbitrary path from the underlying node's filesystem directly into the container. Without restrictions such as requiring read-only mounts, allowing only specific directories, or disabling hostPath when possible, a compromised container can read or modify sensitive host files, plant malicious executables, or even achieve full node compromise. This is a critical misconfiguration that directly exposes the host and is absolutely a security risk.

Trivy is an open-source, fast, and comprehensive vulnerability scanner designed specifically for container images. It scans both OS packages (e.g., Alpine, Debian) and application dependencies (e.g., Python, Node.js) by comparing against a continuously updated CVE database, and it can be easily embedded into CI/CD pipelines with a simple CLI without requiring a separate server. Its low false-positive rate and support for multiple input formats (e.g., Docker, Podman, OCI) make it the most straightforward and effective choice among these options for the security team's container scanning need.

Broken Object Level Authorization (BOLA) is the most direct and correct answer because it occurs when an API fails to enforce per-object permissions, allowing an attacker to access, modify, or delete another user's data simply by substituting an object ID in an API request. For example, changing 'GET /api/user/123' to 'GET /api/user/456' can expose another user's private information if the server does not verify that the authenticated principal owns the requested object. This flaw is specifically catalogued as API1:2019 in the OWASP API Top 10 and is a primary focus of API penetration testing.

Emergency patching is a specialized, expedited process designed to rapidly deploy critical security updates to production systems, often bypassing standard testing and change management protocols due to the severe and immediate risk posed by a newly discovered vulnerability. Its primary objective is to quickly mitigate an active threat or prevent imminent exploitation, prioritizing risk reduction over typical operational considerations like extensive pre-deployment testing or scheduled maintenance windows. This approach is reserved for vulnerabilities deemed critical enough to warrant immediate action.

When a critical asset is affected by a vulnerability with a high Exploit Prediction Scoring System (EPSS) score, the probability of active exploitation is imminent. Expediting patch testing through an accelerated QA process and utilizing emergency change management procedures balances the urgent need to remediate the flaw with the necessity of preventing operational disruption. This approach ensures the vulnerability is closed rapidly without bypassing critical stability checks.

Discovery is the fundamental phase of the vulnerability management lifecycle focused on identifying active assets and detecting their associated vulnerabilities through automated scanning. When an analyst reviews raw scan results, they are actively engaging in this phase to establish a baseline of the organization's current attack surface and security posture.

Implementing a strict whitelist of permitted domains or IP addresses is the most effective mitigation against Server-Side Request Forgery (SSRF). By validating all user-supplied input against this predefined list at the application layer, the server is restricted from initiating outbound connections to arbitrary external destinations or internal loopback addresses. This directly neutralizes the threat vector while maintaining necessary application functionality.

When a legacy application cannot be patched, the vulnerability management lifecycle dictates that the risk must be formally accepted and documented in the risk register. To mitigate the exposure while maintaining business operations, the organization must implement compensating controls, such as network segmentation or strict access control lists, to reduce the likelihood or impact of exploitation.

In the OWASP Top 10:2021 framework, Cross-Site Scripting (XSS) has been consolidated into the A03: Injection category. Reflected XSS occurs when untrusted user input is dynamically injected into a web application's response without proper sanitization or encoding. Consequently, a vulnerability scan identifying a reflected XSS vulnerability with a CVSS vector indicating user interaction and scope change directly maps to this category.

The Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with documented, active exploitation in the wild. Remediation of these flaws must be prioritized because they represent immediate, validated threat vectors that adversaries are currently leveraging to compromise systems. Addressing KEV-listed vulnerabilities directly reduces the organization's active attack surface far more effectively than theoretical risk models.

STIGs are DoD-published configuration baselines that harden systems against known threats, so this option correctly identifies their origin and purpose. OpenSCAP evaluates a host against these mandated settings, and a failure means the system deviates from the DoD's required secure configuration.

An information disclosure vulnerability specifically exposes sensitive data to unauthorized parties without allowing them to alter system state or disrupt operations. Consequently, the CVSS metric for this vulnerability reflects a High Confidentiality impact, while the Integrity and Availability metrics remain at None or Low.

Implementing a web application firewall (WAF) rule (e.g., using the OWASP Core Rule Set) immediately blocks known XSS payloads at the edge, providing a temporary mitigation that reduces exploitability without taking the application offline. The WAF can be tuned to inspect query strings, POST bodies, and headers for attack signatures, allowing the security team to protect users while the development team prepares a permanent patch. This is a standard first-line response for web vulnerabilities, but the WAF rule should be considered a compensating control, not a substitute for secure coding.

OpenVAS (Open Vulnerability Assessment System) is a fully open-source vulnerability scanner maintained by Greenbone Networks. It provides a comprehensive, community-driven feed of Network Vulnerability Tests (NVTs) under the GNU General Public License (GPL), allowing organizations to inspect, modify, and deploy the scanner without licensing fees.

Immediately after scan results are generated, analysts must rank findings by exploitability, asset criticality, and business context so limited remediation resources are directed at the highest-impact vulnerabilities first, which is prioritization.

The Privileges Required (PR) metric measures the level of access privileges an attacker must possess prior to successfully exploiting the vulnerability. It is scored as None, Low, or High, directly reflecting whether the exploit requires administrative control, standard user access, or no authentication at all.

Engaging the vendor for a hotfix or documented workaround while layering compensating controls, such as WAF rules, enhanced monitoring, or restricted access, addresses the vulnerability's risk in the interim without forcing the team to accept either the security exposure or the measured performance degradation.

Because the Pod Security Policy reduces but does not eliminate the vulnerability's potential impact, the correct approach layers remediation with verification: patch the base image to remove the underlying flaw while also confirming the policy's privilege-escalation controls are properly enforced, ensuring both the root cause and the compensating control are addressed rather than relying on either alone.

CVSS is a standardized severity score that synthesizes exploitability characteristics (attack vector, attack complexity, privileges required, user interaction) and impact metrics (confidentiality, integrity, availability) into a 0–10 score. In v3.x, this score provides the critical first filter for triage, allowing an analyst to quickly separate low-severity flaws from those that demand immediate attention. However, it is only a measure of intrinsic severity, not a guarantee of real-world exploitation, so it must be combined with threat likelihood and business impact. As a severity benchmark, it remains the primary initial factor in any prioritization workflow.

Exposing detailed server version banners is a classic security misconfiguration that leaks valuable reconnaissance data to potential attackers. By failing to disable verbose headers or default error pages, administrators inadvertently assist adversaries in mapping out specific, exploitable vulnerabilities associated with that software version.

Verification is the final, critical step in the vulnerability management lifecycle where analysts perform follow-up scans or manual checks to ensure the patch was correctly installed and the vulnerability is fully mitigated. This step prevents false positives and confirms that the remediation efforts were effective in reducing the organization's attack surface.

In the Common Vulnerability Scoring System (CVSS), an Attack Vector of Network (AV:N) means the vulnerability is exploitable from any remote system that can reach the target over a network connection. This includes sending specially crafted IP packets, protocol-specific requests, or application-layer payloads without requiring any prior authentication or local access. The attacker does not need to be co-located on the target's local subnet, merely capable of network connectivity.

Stored XSS in the comment section is an injection vulnerability because the attacker injects executable client-side script (e.g., JavaScript) that is persisted on the server and later rendered in other users' browsers. Unlike SQL injection, which targets the database layer with structured query language, XSS targets the interpretation context of HTML/JavaScript in the victim's browser. The comment field fails to sanitize or encode user input, enabling script execution that can steal session cookies, deface pages, or perform actions on behalf of the target user.

The most effective remediation strategy for container security is to minimize the attack surface by practicing container hygiene. Requesting that the development team remove the unnecessary library and rebuild the base image permanently eliminates the vulnerability at the source, preventing it from being deployed into production environments.

Running a container in privileged mode eliminates the isolation boundaries enforced by namespaces and cgroups, granting the container near-root access to the host. When combined with a hostPath mount, an attacker can easily access the host's filesystem, manipulate system binaries, interact with the host's container runtime socket, and achieve full container escape to compromise the underlying node.

This option accurately reflects a CVSS v3 vector string where the Attack Vector is Network, meaning the vulnerability can be exploited remotely over the internet. It also correctly identifies that the exploit results in a High impact rating for confidentiality, integrity, and availability, indicating total compromise of the affected system.

An out-of-band (OAST) SSRF test uses an external callback server like Burp Collaborator to detect when the application fetches an attacker-specified URL. If a DNS lookup or HTTP hit is received, it proves the server-side component is making the request as the victim, even when the response body is not reflected to the tester. This technique is essential for blind SSRF, where the application processes the response internally without echoing it back. It also confirms the vulnerability independently of any firewall or filtering on the inbound path.

OpenSCAP evaluates systems against security baselines such as SCAP content and STIG profiles, checking configuration settings and reporting compliance deviations. This directly satisfies the scenario's compliance scanning purpose by automating configuration assessment against defined standards.

Trivy is an open-source vulnerability scanner specifically designed for containers, Kubernetes, and IaC templates. It excels at detecting vulnerabilities in OS packages and application dependencies within container images, making it ideal for integration into CI/CD pipelines.

The CVSS vector string 'AC:L' explicitly denotes a Low Attack Complexity. This means that a successful attack does not require specialized conditions beyond the attacker's control, nor does it demand extensive preparation or specific timing. Attackers can typically exploit such vulnerabilities with readily available techniques and resources, making the attack relatively straightforward and increasing its likelihood.

Scan intensity controls the aggressiveness of the scan, including the number of concurrent connections and payloads sent. Lowering intensity reduces the risk of overwhelming production systems, which could cause outages. The analyst should set a lower intensity to avoid disruption while still identifying vulnerabilities. This setting directly addresses the need to balance thoroughness with system stability.

This Group Policy setting directly addresses the OpenSCAP finding by preventing unauthenticated users from enumerating domain or local account names and shares. Enabling this policy enforces the recommended CIS benchmark control, securing the SAM database against reconnaissance techniques like null session enumeration without disrupting legitimate system operations.

Burp Suite is an intercepting proxy designed specifically for web application security testing. It allows an analyst to intercept, modify, and replay HTTP/HTTPS requests to manually inspect the web server's responses. This makes it the ideal tool to safely and directly verify if directory listing is enabled on a specific web directory.

DAST tools excel at identifying input validation flaws like SQL injection by actively sending malicious payloads to application entry points and analyzing the HTTP responses. If the application returns database error messages or exhibits unexpected behavior, the tool flags the vulnerability in real-time.

Injection vulnerabilities occur when an application passes unfiltered, user-supplied input directly to an interpreter, such as a SQL database or system shell. This allows an attacker to manipulate the structure of the intended command, leading to unauthorized data access, modification, or arbitrary remote code execution on the host system.

The primary objective of staging is to verify that the patch successfully remediates the targeted security vulnerability while ensuring it does not break existing functionality or cause system regressions. This validation phase allows administrators to observe system behavior, application dependencies, and performance metrics under realistic conditions before a full production rollout.

The KEV catalog includes a 'Date Added' field that records when a vulnerability was first identified as known exploited, allowing security teams to prioritize based on how recent and relevant the active exploitation is. This date is crucial because newer entries often warrant immediate attention, as attackers may be actively leveraging them. In contrast to CVSS or EPSS scores, this date is a distinct component of the KEV record itself, making it the right field when consulting the catalog for prioritization.

An EPSS score of 0.1% indicates the vulnerability has near-negligible real-world exploitation likelihood in the next 30 days, and the Kubernetes NetworkPolicy restricting ingress further reduces the attack surface by limiting who can even reach the affected containers. Combining low predicted exploitation with existing compensating controls justifies routine remediation timing rather than emergency action, letting the team patch the base image and redeploy during the normal maintenance cycle.

An Attack Vector of Local (AV:L) significantly reduces the exploitability score because the attacker cannot exploit the vulnerability over the network. They must already possess local shell access, console access, or the ability to execute code locally on the container or host, creating a major barrier to entry compared to Network-based attacks.

Trivy is an open-source vulnerability scanner specifically designed for containers and other cloud-native targets. It quickly scans container images, filesystems, and Git repositories to detect known vulnerabilities (CVEs), misconfigurations, and leaked secrets, making it ideal for integration into CI/CD pipelines.