CEH Practice Question: Advanced Topics: Wireless, Cloud, IoT, Cryptography

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Disable the MQTT broker entirely and switch to HTTP

  Why it's wrong here

  Disabling the MQTT broker and switching to HTTP is generally impractical for an existing IoT ecosystem, as devices are often purpose-built for MQTT's lightweight publish/subscribe model. This drastic change would require significant re-engineering and redeployment of all IoT devices. Furthermore, merely switching to HTTP without implementing HTTPS and client authentication would simply replace one insecure communication method with another, failing to address the fundamental lack of secure transport and access control that the original problem presents.

• ✓

  Implement client authentication and enable TLS encryption

  Why this is correct

  Implementing client authentication ensures that only authorized IoT devices can connect to the MQTT broker, preventing unauthorized actors from publishing or subscribing to sensitive data streams. Concurrently, enabling TLS encryption secures the communication channel itself, protecting all data transmitted between devices and the broker from eavesdropping, tampering, and man-in-the-middle attacks. This combination establishes robust confidentiality, integrity, and access control for MQTT communications, directly addressing the core security vulnerabilities.

• ✗

  Change the default topic names to obfuscated strings

  Why it's wrong here

  Changing default topic names to obfuscated strings offers no real security benefit, as this approach relies on 'security by obscurity,' which is not a recognized security control. An attacker can easily discover topic names by subscribing to the '#' wildcard, observing network traffic, or reverse-engineering device firmware. This method does not prevent unauthorized access, provide data confidentiality, or offer any form of authentication for the communication, leaving the system vulnerable.

• ✗

  Use a VPN for all IoT device communication

  Why it's wrong here

  A VPN encrypts traffic between the IoT device and the broker, but the MQTT protocol itself still lacks authentication; the attacker, already on the same local network, can intercept the decrypted traffic after the VPN tunnel terminates at the broker endpoint. This option is tempting because a VPN is correctly used to secure communications across untrusted networks, and it would be the right choice if the threat were an external attacker on a different subnet rather than a local-network eavesdropper.

Go deeper

Related to this question