CEH Wireless, IoT and Cloud Security Practice Question
A penetration tester is assessing the security of a smart building's IoT infrastructure. The building uses Zigbee sensors for temperature and motion detection, and some devices communicate using MQTT over Wi-Fi. During the assessment, the tester captures traffic and notices that some Zigbee devices are sending unencrypted frames containing sensor IDs and values. Which TWO actions should the tester recommend to mitigate the identified vulnerabilities? (Choose two.)
⚠ Common exam trap
Many candidates confuse network segmentation (VLANs) with data encryption, thinking that isolating IoT devices on a separate VLAN alone protects the confidentiality of unencrypted wireless frames.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable Zigbee security suite (AES-128 encryption) on all sensor devices.
Zigbee's security suite uses AES-128 encryption to protect over-the-air frames, preventing eavesdropping on sensor IDs and values. Enabling this suite ensures that captured unencrypted frames are no longer readable, directly mitigating the observed vulnerability. Option B is correct because MQTT over Wi-Fi without TLS exposes all communication in plaintext; configuring TLS 1.2 with mutual authentication encrypts the payload and verifies both broker and client identities, preventing man-in-the-middle attacks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable Zigbee security suite (AES-128 encryption) on all sensor devices.
Why this is correct
This option directly addresses data confidentiality for Zigbee communications within the smart building. The Zigbee security suite, specifically utilizing AES-128 symmetric encryption, encrypts data packets exchanged between sensor devices and the coordinator. This prevents unauthorized eavesdropping and ensures the privacy of sensitive sensor readings, which is crucial for maintaining the security and integrity of the smart building's operational data.
- ✓
Configure MQTT to use TLS 1.2 with mutual authentication between brokers and clients.
Why this is correct
Implementing TLS 1.2 for MQTT ensures that all data transmitted between clients and the broker is encrypted, protecting against man-in-the-middle attacks and passive sniffing of sensitive information. Mutual authentication, using client and server certificates, further strengthens security by verifying the identity of both parties. This prevents unauthorized devices from connecting to the MQTT broker and publishing or subscribing to topics, ensuring only trusted entities communicate.
- ✗
Disable encryption on MQTT to reduce latency and improve performance.
Why it's wrong here
Disabling encryption on MQTT traffic, while potentially offering a marginal performance gain, severely compromises data confidentiality and integrity. Unencrypted MQTT messages can be easily intercepted and read by attackers, revealing sensitive smart building data or allowing for message tampering. This introduces a critical security vulnerability, making the system susceptible to unauthorized control, data manipulation, or privacy breaches.
- ✗
Implement device authentication using pre-shared keys only for Zigbee devices.
Why it's wrong here
While pre-shared keys provide a basic form of authentication, verifying the identity of Zigbee devices, this measure alone does not encrypt the actual data payload being transmitted. An attacker could still intercept authenticated communications and read the unencrypted sensor data or control commands in plain text. Authentication is a necessary component of security, but without encryption, data confidentiality is not achieved, leaving sensitive information exposed.
- ✗
Segment the IoT devices into a separate VLAN and restrict access with ACLs.
Why it's wrong here
Network segmentation using VLANs and Access Control Lists (ACLs) is a fundamental security practice that limits the blast radius of a compromise and restricts unauthorized access to IoT devices from other network segments. However, this measure primarily focuses on network isolation and access control. It does not provide encryption for data in transit *within* the IoT segment or between devices, leaving communications vulnerable to sniffing if an attacker gains access to that specific VLAN.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
About these practice questions
This CEH question is part of Courseiva's 870-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CEH practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CEH exam.