A city museum wants open Wi-Fi for visitors and a separate secured WLAN for exhibit sensors. How should security requirements be derived?
Select an answer to reveal the explanation.
Short Explanation
Visitors browsing maps and sensors guarding exhibits are different animals. Write two requirement piles—guest openness vs operational lockdown—not one mushy open SSID for both.
Full Explanation
A city museum that wants open Wi-Fi for visitors and a separate secured WLAN for exhibit sensors must derive distinct security requirement sets for public guest access versus operational IoT and sensor use cases. Guest access prioritizes usability, content filtering, and isolation from collections systems; sensor networks prioritize device authentication appropriate to capability, integrity of telemetry, and protection from visitor tampering. Using one flat open SSID for both visitors and sensors "to simplify" collapses trust boundaries and exposes exhibit systems to casual clients. Applying identical enterprise 802.1X to casual visitors and sensors with no guest design ignores visitor usability and often fails for headless IoT that cannot perform interactive EAP. Disabling encryption on the sensor SSID so curators can "see" traffic easily defeats confidentiality and invites manipulation of exhibit controls. Shared hardware is fine; shared security requirements are not. Exam caveat: CWSP expects requirements to follow use case and data sensitivity, not a single SSID convenience model. Operational check: write separate requirements packages for guest and sensors, implement separate SSIDs and VLANs with tested isolation, authenticate sensors to the strongest method they support, and verify visitor clients cannot reach sensor, collections, or staff networks.