A city WLAN vendor releases a fixed AP code train for a known vulnerability, but the municipal change window is next week. What mitigation approach best fits until the upgrade can run?
Select an answer to reveal the explanation.
Short Explanation
Patches are like a scheduled road resurfacing—you plan the night the crews can work, and you put cones out in the meantime. Book the upgrade in the change window and keep eyes (or compensating WIPS rules) on the risk until the blades land. Skipping monitoring because “next week is soon” is how surprises happen.
Full Explanation
When a city WLAN vendor releases a fixed AP code train for a known vulnerability but the municipal change window is next week, the best mitigation approach is to schedule the code upgrade in the approved change window and apply interim monitoring or compensating controls until then. That pattern balances change discipline with risk reduction instead of either ignoring the advisory or causing unplanned outages. Ignoring the advisory because civic networks are exempt from vendor PSIRT notices is false and leaves known holes open. Factory-resetting every AP nightly so the vulnerability cannot persist across reboots causes chronic disruption and usually fails to remove vulnerable code that reloads from image. Disabling all logging to reduce noise while waiting for the patch train destroys detection during the exposure window. Document the residual risk, enhance WIPS/SIEM watches, restrict management exposure if relevant, and execute the tested upgrade at the approved time. Exam caveat: delayed patching is acceptable only with interim compensating controls and a firm scheduled fix—not with inaction. Operational check: enter the upgrade into change management with back-out, enable interim signatures or heightened alerting on affected AP models, limit unnecessary management reachability, and verify post-upgrade versions and SSID health after the window.