A vulnerability bulletin lists a high-impact CVE in the city’s AP firmware train. What is the sound vulnerability-management response?
Select an answer to reveal the explanation.
Short Explanation
AP firmware CVEs are just like PC patches with antennas. Watch the advisories, score how bad it is for your estate, and schedule the upgrade like grown-up change control. Hoping the building walls stop remote bugs is wishful thinking.
Full Explanation
A high-impact CVE in the city’s AP firmware train requires disciplined vulnerability management: monitor CVE sources, risk-rate exposure against the deployed fleet and SSID sensitivity, and prioritize firmware patches for affected WLAN infrastructure. Civic WLANs that carry staff, payment-adjacent, and public-safety traffic cannot treat AP firmware as optional cosmetics. Documented risk rating also supports change windows, rollback plans, and council-facing risk reporting when downtime is politically sensitive.
Ignoring CVEs because APs are “inside” the building misunderstands physical proximity, client-driven attack paths, and guest adjacency. Patching randomly without recording risk ratings produces unprioritized churn and weak audit evidence. Waiting for a public exploit blog post before opening a change ticket maximizes the exposure window.
Exam caveat: not every CVE forces emergency midnight patching—severity, exploitability, and compensating controls drive timing—but continuous monitoring and rating remain mandatory. Operational check: enter the CVE in the municipal vuln tracker with affected AP models, assign a risk rating, schedule the firmware change, and verify post-patch version inventory matches the remediated train.