A vulnerability scan flags a critical flaw in a database server's network listener. The vendor has published an advisory but no patch yet, and the database must stay in service for a customer-facing application. What is the most appropriate response?
Select an answer to reveal the explanation.
Short Explanation
When there's no patch yet, you don't just shrug; you put a fence around the hole. Narrow who can reach that listener, watch it closely, write down the accepted risk, and patch the minute the fix ships. Pretending the finding isn't real is the fastest way to get burned.
Full Explanation
Remediation is not limited to patching. When a fix is unavailable, the standard response is to reduce exploitability with compensating controls while tracking the finding to closure. For a listener flaw, that typically means restricting the listener to the minimum set of client addresses, applying any workaround the vendor advisory describes, increasing monitoring for exploitation attempts, and recording the risk and its owner. When the vendor releases a patch, the team tests it, applies it through change management and rescans to confirm the finding is resolved. Shutting the database down eliminates the risk but violates the stated availability requirement, and an open-ended outage waiting on a vendor is rarely proportionate when the exposure can be reduced. Marking the finding as a false positive misrepresents a confirmed vulnerability, removes it from tracking and leaves no record that risk was accepted. Doing nothing because no patch exists ignores the controls that can lower the likelihood of exploitation in the meantime. Exam caveat: the patching cycle is identify, assess, mitigate, patch, verify. Operational check: confirm the compensating controls are in place, that the finding remains open in the tracker with an owner, and that a rescan is scheduled after patching.