A vulnerability scan finds that an old print server still has SMBv1 enabled. The business says the vendor will not support a patch for at least two months, but the server must stay online. What is the best temporary mitigation?
Isolating the server on a restricted network segment is a sound compensating control; it shrinks the attack surface to only those hosts that legitimately require SMB access, reducing the number of potential exploit sources while the vendor patch is pending. Because SMBv1 is remotely exploitable without authentication in many cases, limiting connectivity via firewall rules is more effective than relying on host-level hardening. This approach aligns with network segmentation principles and does not hide or destroy security-relevant data.
Why this answer
Network segmentation is the most effective temporary mitigation when a patch is unavailable. By moving the print server to a restricted VLAN or firewall zone and applying an access control list (ACL) that permits SMB traffic only from known, required hosts, you reduce the attack surface and prevent widespread exploitation of SMBv1 vulnerabilities (e.g., EternalBlue). This approach follows the principle of least privilege and containment, buying time until the vendor releases a patch.
Exam trap
The trap here is that candidates may choose a reactive measure like rebooting or a non-technical control like password changes, failing to recognize that containment via network segmentation is the only proactive defense that directly limits the exploit's reach without requiring a patch.
How to eliminate wrong answers
Option B is wrong because turning off endpoint logging reduces visibility into potential attacks, making it harder to detect exploitation of SMBv1; it does not address the vulnerability. Option C is wrong because increasing password length does not mitigate the SMBv1 protocol-level flaws (e.g., lack of pre-authentication integrity checks, susceptibility to relay attacks); it only strengthens authentication, which is irrelevant to the unpatched service. Option D is wrong because scheduling a weekly reboot does not prevent exploitation; attackers can re-establish malicious sessions quickly after reboot, and the vulnerability remains fully exploitable between reboots.