A security team received an alert from a vulnerability scanner about a zero-day vulnerability affecting a company-owned, SSL-based remote access VPN concentrator. Using this vulnerability, an…

Question

Options

• APerform virtual patching via Cisco IDS rules that block crafted requests for connections from outside.
• BRestrict access to the VPN concentrator management interfaces only from trusted internal sources.
• CRestrict access to VPN service to accept connection only from trusted outside IP address ranges.
• DBlock any connections to the TCP/443 port of the VPN concentrator and wait for a vendor patch.

• A
  8% (4)
• B
  13% (7)
• C
  75% (40)
• D
  4% (2)

Explanation

Restricting VPN access to trusted external IP ranges (C) directly shrinks the attack surface to known, authorized users - since the exploit requires an attacker to send a crafted request, limiting who can reach the service blocks unknown threat actors while keeping remote access operational for the business.

Why the distractors fail:

• A (IDS/virtual patching): Zero-day vulnerabilities lack reliable signatures, so IDS rules cannot definitively detect all crafted request variants - this is a probabilistic control, not a definitive block.
• B (restrict management interfaces internally): This hardens the management plane but leaves the VPN service itself exposed to any external attacker who can still initiate a connection and trigger the code execution; the code runs before management access is even reached.
• D (block TCP/443 entirely): Eliminates the risk but also eliminates the service - the scenario explicitly states remote access is critical, making a full outage unacceptable as a mitigation strategy.

Memory tip: When a patch isn't available and you can't shut down a critical service, the go-to compensating control is IP allowlisting - reduce the attack surface by controlling who can reach the vulnerable endpoint, not just what they send.

No community discussion yet for this question.