The vendor PSIRT publishes a remote code execution advisory for the municipal WLAN controller, but staff only read informal news blogs. Which guidance is best?
Select an answer to reveal the explanation.
Short Explanation
Blogs are gossip; the PSIRT and CVE record are the signed memo. For city controllers, start with the vendor advisory and official vulnerability ID, then decide risk—not the other way around.
Full Explanation
When the vendor PSIRT publishes a remote code execution advisory for the municipal WLAN controller but staff only read informal news blogs, the best guidance is to prefer vendor advisories and CVE records over rumor when identifying WLAN infrastructure vulnerabilities. PSIRT notices and CVE records state affected products, versions, attack preconditions, and fixed releases with accountability; blogs may omit version ranges or exaggerate impact. Trusting anonymous forum posts first because they are usually faster privileges speed over accuracy and can drive wrong changes. Assuming blog headlines always exaggerate and never opening the vendor advisory is equally unsafe—critical RCEs do occur and must be read from primary sources. Disabling all controller logging so the RCE cannot be proven later destroys detection and forensics rather than mitigating the flaw. Municipal WLAN teams should designate primary intelligence sources and treat secondary media as pointers back to those sources. Exam caveat: exam answers favor authoritative vulnerability identification (vendor/CVE) over informal channels when scoping infrastructure risk. Operational check: open the PSIRT advisory and related CVE, confirm whether municipal controller versions are listed, document exploitability and management-plane exposure, and drive patching or isolation from that authoritative record rather than from headline paraphrases.