Wireless, IoT and Cloud Security practice questions

Use WPA2-PSK with a strong passphrase.

Why wrong: While WPA2-PSK with a strong passphrase provides robust encryption and authentication for legitimate clients connecting to authorized access points, it offers no protection against rogue access points. A rogue AP operates independently, often mimicking the legitimate network's SSID to trick users into connecting. The security of the legitimate network's WPA2-PSK key does not prevent an attacker from setting up their own unauthorized AP, which may or may not use WPA2-PSK, to capture credentials or launch further attacks.

Implement MAC address filtering on the access points.

Why wrong: MAC address filtering attempts to restrict network access by allowing only devices with specific MAC addresses to connect to an access point. However, this is a weak security measure against rogue access points because MAC addresses can be easily spoofed. An attacker can simply sniff the network to identify an authorized MAC address and then configure their rogue AP or client device to use that spoofed MAC, completely bypassing this rudimentary filter and gaining unauthorized access.

Disable SSID broadcast on the corporate network.

Why wrong: Disabling SSID broadcast, often referred to as "hiding the SSID," is a misconception as a security measure because it does not prevent rogue access points. While it makes the network less visible to casual users, the SSID is still transmitted in probe requests and responses, beacon frames, and association requests, making it easily discoverable by readily available wireless sniffing tools. An attacker can still set up a rogue AP with the same "hidden" SSID to entice users or launch deauthentication attacks, rendering this countermeasure largely ineffective against determined adversaries.

Physical theft of servers from the data center.

Why wrong: Physical theft of servers from a cloud provider's data center is generally not a common security risk for cloud customers. Cloud service providers (CSPs) invest heavily in robust physical security measures, including multi-factor access controls, surveillance, and on-site security personnel, to protect their infrastructure. This responsibility falls under the shared responsibility model, where the CSP secures the underlying physical hardware and facilities. Therefore, customers typically do not need to worry about this specific threat.

Hypervisor compromise due to unpatched vulnerabilities.

Why wrong: Hypervisor compromise due to unpatched vulnerabilities is primarily a concern for the cloud service provider (CSP), not typically a direct, common risk for the cloud customer. CSPs are responsible for maintaining and patching the underlying hypervisor software that virtualizes customer instances. They employ dedicated security teams and automated systems to ensure hypervisors are kept up-to-date, mitigating this specific threat at the infrastructure level.

High data throughput.

Why wrong: Bluetooth Low Energy (BLE) is fundamentally designed for power efficiency, not high bandwidth. While classic Bluetooth (BR/EDR) offers moderate throughput, BLE's typical effective data rates are significantly lower, often less than 100 kilobits per second (kbps) for application data. This prioritization of low power over speed makes "high data throughput" an inaccurate characteristic for the most prevalent low-power Bluetooth implementations.

Long range (up to 1 km).

Why wrong: Bluetooth, particularly Bluetooth Low Energy (BLE), is engineered for short-range wireless communication, typically within personal area networks. While Class 1 Bluetooth devices can theoretically achieve ranges up to 100 meters in optimal line-of-sight conditions, practical indoor ranges are often limited to 10-30 meters due to environmental factors. The assertion of "up to 1 km" significantly overstates Bluetooth's typical operational range, which is characteristic of other long-range wireless technologies.

Operates in unlicensed spectrum like Wi-Fi.

Why wrong: While Bluetooth, including BLE, does operate in the globally unlicensed 2.4 GHz Industrial, Scientific, and Medical (ISM) band, similar to Wi-Fi, the phrasing "like Wi-Fi" is misleading regarding its operational methodology. Bluetooth employs adaptive frequency hopping spread spectrum (AFH) to mitigate interference by rapidly switching channels, a distinct approach from Wi-Fi's channel-based direct sequence spread spectrum (DSSS) or orthogonal frequency-division multiplexing (OFDM). Therefore, equating their spectrum usage directly implies a shared technical implementation that does not exist.

The AMI ID (ami-0abcdef1234567890) is from a trusted source.

Why wrong: An AMI ID like "ami-0abcdef1234567890" is a standard format for Amazon Machine Images. Without additional context, such as the AMI owner, its public/private status, or a known vulnerability associated with a specific version of its underlying software, there is no inherent reason to deem it untrusted or a security concern. Trust in AMIs is typically established by using official AWS AMIs, AMIs from trusted third-party vendors, or custom AMIs built and hardened internally.

The source IP address (203.0.113.5) is suspicious.

Why wrong: The IP address "203.0.113.5" belongs to the 203.0.113.0/24 range, which is reserved for documentation and example purposes (TEST-NET-3) as defined by RFC 5737. Therefore, its presence in a log does not inherently indicate suspicious activity. While a source IP address can be suspicious if it originates from a known malicious actor, an unexpected geographic location, or an unauthorized network, this specific IP address is not indicative of such a threat.

The instance type is t2.micro, which may be vulnerable.

Why wrong: The "t2.micro" instance type refers to the virtual hardware configuration and resource allocation (CPU, memory, network performance) for an EC2 instance. It does not inherently introduce security vulnerabilities. Vulnerabilities typically reside within the operating system, installed applications, network configurations, or user data scripts running on the instance, not the underlying instance type itself. A t2.micro is simply a small, general-purpose instance suitable for development or low-traffic workloads.

Enhanced network segmentation

Why wrong: Enhanced network segmentation is incorrectly identified as a security risk; it is, in fact, a fundamental security control. Network segmentation involves logically dividing a network into isolated zones, which can significantly reduce the blast radius if a BYOD device is compromised. By restricting communication between segments, it prevents an attacker from easily moving laterally from a compromised personal device to critical corporate assets, thereby mitigating risk.

Stronger encryption of corporate data

Why wrong: Stronger encryption of corporate data is a robust security measure, not a risk. Implementing stronger encryption, such as full-disk encryption or application-level encryption, on BYOD devices is a crucial defense mechanism. It protects the confidentiality of sensitive corporate data stored on the device, rendering it unreadable to unauthorized parties even if the device is lost, stolen, or falls into the wrong hands, thereby reducing data breach risks.

Increased control over device configurations

Why wrong: Increased control over device configurations is a mischaracterization of BYOD environments. One of the primary challenges and risks of BYOD is the reduced corporate control over employee-owned devices. IT departments typically have limited ability to enforce specific security configurations, install mandatory software, or manage operating system updates on personal devices, which directly contrasts with the idea of increased control and introduces significant security vulnerabilities.

Install a host-based firewall on the IoT device to restrict outbound traffic.

Why wrong: Installing a host-based firewall is generally impractical for many IoT devices due to their constrained resources, limited processing power, and specialized firmware. Unlike traditional endpoints, most IoT devices lack a full-fledged operating system or the necessary architecture to support and manage such software, making this solution infeasible for widespread deployment and effective traffic control.

Deploy an intrusion detection system (IDS) on the network to alert on suspicious DNS queries.

Why wrong: While deploying an intrusion detection system (IDS) would certainly alert security analysts to suspicious DNS queries, its primary function is detection and notification, not prevention. An IDS passively monitors network traffic and generates alerts, but it does not actively block or mitigate the malicious outbound connections, leaving the IoT device vulnerable to ongoing command and control communication.

Disable DNS resolution on the IoT device to prevent any external communication.

Why wrong: Disabling DNS resolution directly on the IoT device would indeed prevent it from resolving external domain names, but this drastic measure would severely impair its legitimate functionality. Many IoT devices rely on DNS for essential tasks like firmware updates, cloud service communication, or time synchronization, rendering the device inoperable or severely degraded for its intended purpose.

The data is encrypted at rest, so no exposure risk exists.

Why wrong: This statement is incorrect because data encryption at rest, whether using SSE-S3, SSE-KMS, or SSE-C, primarily protects against unauthorized physical access to storage devices. While crucial for data protection, encryption does not inherently control who can *access* the data via the S3 API or HTTP endpoints. If a bucket policy grants public read access, an encrypted object can still be downloaded and decrypted by anyone with the necessary permissions, as the decryption process is handled transparently by S3 or the client.

The bucket policy is misconfigured but only affects objects with server-side encryption.

Why wrong: This statement is incorrect. An S3 bucket policy, by default, applies to all objects within the specified bucket unless explicit conditions are included to filter based on object properties like encryption status. A misconfigured policy granting public access will typically apply broadly to all objects, regardless of whether they are encrypted with server-side encryption (SSE-S3, SSE-KMS) or not. The policy's permissions are evaluated *before* object retrieval, making the encryption status irrelevant to the initial access decision.

Only authenticated AWS users can access the bucket, so the risk is limited.

Why wrong: This statement is incorrect. A common misconfiguration in S3 bucket policies involves granting permissions to the `Principal: "*"`, which represents "AllUsers" (anonymous users) or `Principal: { "AWS": ["arn:aws:iam::ACCOUNT_ID:root"] }` which represents the account owner. If the policy allows `s3:GetObject` for `AllUsers`, then *anyone* on the internet, without any AWS credentials or authentication, can access the objects. This constitutes anonymous access, not limited access to only authenticated AWS users, thus posing a significant risk.

Perform a PMKID attack on the WPA3 client to capture the handshake.

Why wrong: The PMKID attack specifically targets WPA2-PSK networks by capturing the Pairwise Master Key Identifier from a single EAPOL frame, which can then be brute-forced offline. WPA3, however, utilizes the Simultaneous Authentication of Equals (SAE) handshake, which is designed to be resistant to offline dictionary attacks and does not transmit a PMKID in a way that can be exploited for offline cracking. Therefore, this attack method is ineffective against WPA3 clients.

Use a WPS PIN brute-force attack against the WPA3 client.

Why wrong: Wi-Fi Protected Setup (WPS) is a separate protocol designed for easy device connection, often vulnerable to PIN brute-force attacks due to its design flaws. While some WPA3-capable devices might still support WPS for backward compatibility, WPS itself is not an inherent part of WPA3's core security mechanisms and is largely deprecated due to its known vulnerabilities. Attacking WPS would compromise the WPS feature, not directly exploit WPA3's cryptographic handshake or downgrade the WPA3 connection.

Send deauthentication packets to the WPA3 client and capture the reconnection handshake.

Why wrong: Sending deauthentication packets merely disconnects a client from its current access point, forcing it to reauthenticate. While this can capture a legitimate WPA3 SAE handshake, WPA3's design, particularly its resistance to offline dictionary attacks through SAE, means simply capturing this handshake does not provide an avenue for compromise. The client will attempt to reconnect securely using WPA3, not automatically downgrade its security protocol.

4G LTE

Why wrong: 4G LTE, while offering wide area coverage and high bandwidth, is fundamentally unsuitable for battery-powered IoT sensors in a remote facility due to its significantly higher power consumption. The continuous cellular connection and data transmission rates required by 4G LTE would rapidly deplete sensor batteries, making long-term, low-maintenance operation impractical in a power-limited environment. This technology is designed for higher data throughput, not extreme power efficiency over extended periods.

Wi-Fi 6

Why wrong: Wi-Fi 6 (802.11ax) is designed for high-throughput, short-to-medium range local area networks, making it a poor choice for remote IoT sensors with limited power. Its power consumption, even with advanced power-saving features, remains too high for sensors expected to operate for years on small batteries. Furthermore, its limited range, typically tens to hundreds of meters, would necessitate extensive and costly infrastructure deployment across a remote facility, contradicting the 'limited power' and 'remote' constraints.

Bluetooth 5

Why wrong: Bluetooth 5, particularly Bluetooth Low Energy (BLE), excels in short-range, low-power personal area network applications, but it is not suitable for wide-area remote sensor deployments. Its maximum effective range, even with enhancements, is generally limited to a few hundred meters line-of-sight, which would require an impractical number of gateways to cover a potentially large remote facility. This technology is optimized for local device-to-device communication or hub connectivity, not expansive remote monitoring.

Install fail2ban to automatically block IPs after failures.

Why wrong: While fail2ban can mitigate basic brute-force attempts by automatically blocking source IPs after a configurable number of failed logins, it remains vulnerable to distributed attacks. Sophisticated attackers can employ botnets or rotate through a large pool of IP addresses, effectively bypassing the single-IP blocking mechanism. This renders fail2ban less effective against determined, large-scale brute-force campaigns.

Implement rate-limiting on SSH connections per IP.

Why wrong: Implementing rate-limiting on SSH connections per IP address offers limited protection against advanced brute-force attacks. Attackers can easily circumvent this defense by distributing their login attempts across a multitude of compromised systems or proxy networks, each presenting a unique IP address. This strategy allows them to stay below the per-IP rate limit while still achieving a high volume of overall login attempts.

Change the SSH port to a non-standard port.

Why wrong: Changing the default SSH port (22) to a non-standard port provides only a superficial layer of security, often referred to as 'security by obscurity.' While it might deter casual scanners looking for default services, a determined attacker will simply perform a full port scan of the target system. Tools like Nmap can quickly identify services running on any port, rendering this measure largely ineffective against targeted attacks.

Decrypt the traffic using the captured handshake to get the credentials.

Why wrong: In a WPA2-Enterprise environment, the captured EAPOL handshake frames do not contain the user's plaintext credentials or a directly crackable hash of them for offline decryption of *traffic*. While the Pairwise Master Key (PMK) is derived during the EAP authentication process, it is used to generate session keys for encrypting data traffic, not to directly decrypt the initial EAP exchange to reveal user credentials. The EAP tunnel itself is established and encrypted *before* the PMK is fully derived for data encryption, making direct credential extraction from the handshake for traffic decryption impossible.

WPS PIN brute-force to recover the PSK.

Why wrong: WPS (Wi-Fi Protected Setup) is a feature exclusively designed for WPA/WPA2-Personal networks, which utilize a single Pre-Shared Key (PSK) for all clients. WPA2-Enterprise, conversely, relies on 802.1X authentication with an external RADIUS server and individual user credentials, not a shared PSK or a WPS PIN. Therefore, attempting a WPS PIN brute-force attack is entirely irrelevant and ineffective against an Enterprise-grade wireless network, as the WPS protocol is simply not implemented or supported in such environments.

PMKID attack to crack the pre-shared key.

Why wrong: The PMKID attack is specifically designed to recover the Pre-Shared Key (PSK) in WPA/WPA2-Personal networks by capturing the first frame of the 4-way handshake and performing an offline brute-force. This method is inapplicable to WPA2-Enterprise environments because they do not use a single PSK. Instead, Enterprise networks employ 802.1X authentication with individual user credentials and a RADIUS server, meaning there is no PSK to crack via a PMKID attack.

Enforce complex password policies.

Why wrong: Enforcing complex password policies, while generally good security practice, primarily mitigates brute-force attacks against individual accounts or dictionary attacks. It does not prevent credential stuffing because this attack vector relies on users reusing credentials that have already been compromised in other breaches. If a complex password is reused across multiple services, its complexity offers no protection when it's "stuffed" into a new login form, as the attacker already possesses the valid combination.

Implement CAPTCHA on the login page.

Why wrong: Implementing CAPTCHA on the login page offers some protection against unsophisticated automated bot attacks but is not a robust solution for credential stuffing. Sophisticated attackers can employ CAPTCHA-solving services, use advanced bots that bypass common CAPTCHA mechanisms, or even leverage human CAPTCHA farms. Furthermore, in a cloud-based Identity Provider (IdP) scenario, the primary authentication flow might occur via APIs or federated protocols where CAPTCHA integration is often impractical or non-existent, diminishing its overall effectiveness.

Enable account lockout after 3 failed attempts.

Why wrong: While account lockout policies are crucial for mitigating brute-force attacks against specific user accounts, they are largely ineffective against credential stuffing. Attackers performing credential stuffing typically use a large list of known username/password pairs, attempting each pair only once or a few times across many different accounts. This distributed approach avoids triggering lockout thresholds for any single account, allowing the attacker to test thousands or millions of credentials without interruption, or even cause a denial-of-service by locking out legitimate users.

Require strong passwords on the camera web interface.

Why wrong: Requiring strong passwords on the camera's web interface primarily secures administrative access to the device's configuration settings. However, this measure does not encrypt the actual video, audio, or telemetry data streams transmitted from the camera to a server or monitoring station. Consequently, even with robust interface authentication, the sensitive communication payload remains vulnerable to passive eavesdropping or active tampering if the underlying network channel is unencrypted.

Use a site-to-site VPN between the cameras and the server.

Why wrong: Implementing a site-to-site VPN typically involves establishing a secure tunnel between two networks, often requiring dedicated hardware or significant software configuration on network gateways. Many resource-constrained IoT cameras lack the processing power, memory, or firmware capabilities to act as VPN endpoints, making direct site-to-site VPN integration impractical or impossible. Furthermore, managing individual VPN tunnels for a large fleet of devices introduces considerable operational complexity and overhead.

Use certificate pinning to prevent man-in-the-middle attacks.

Why wrong: Certificate pinning is an advanced security technique that enhances the trust model of TLS/SSL by hardcoding or pre-configuring specific server certificates or public keys within the client application. While effective at preventing sophisticated Man-in-the-Middle attacks by ensuring communication only occurs with known, legitimate servers, certificate pinning itself does not provide the fundamental encryption layer. It relies entirely on an existing TLS/SSL connection to establish the secure, encrypted channel; without TLS/SSL, pinning has no cryptographic context to operate within.

Enable Universal Plug and Play (UPnP) for easy integration.

Why wrong: Enabling Universal Plug and Play (UPnP) for IoT devices is a significant security risk and should be avoided. UPnP allows devices to automatically discover each other and open ports on a router without user intervention, effectively bypassing firewall rules. This creates direct pathways from the internet to potentially vulnerable IoT devices, making them easily discoverable and exploitable by attackers scanning for open ports.

Ensure all devices are connected directly to the internet for remote access.

Why wrong: Connecting all IoT devices directly to the internet for remote access without an intermediary secure gateway is a dangerous practice. Direct exposure makes devices highly vulnerable to constant scanning, exploitation attempts, and denial-of-service attacks from malicious actors worldwide. A secure gateway, VPN, or cloud-based IoT platform provides essential layers of authentication, encryption, and centralized security policy enforcement, acting as a protective barrier against direct internet threats.

The pairwise cipher is CCMP, which is outdated.

Why wrong: The statement that CCMP is outdated is incorrect. Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is the mandatory and robust encryption protocol for WPA2, leveraging the Advanced Encryption Standard (AES) for strong confidentiality and integrity. It remains the industry standard for secure wireless communication and is not considered outdated or insecure for WPA2 networks.

The network uses WPA2-PSK, which is easily cracked.

Why wrong: The assertion that WPA2-PSK is easily cracked is misleading. WPA2-PSK (Pre-Shared Key) provides strong cryptographic protection when a sufficiently complex passphrase is used. While it can be vulnerable to offline dictionary attacks if the passphrase is weak or common, this vulnerability lies with poor passphrase choice, not an inherent flaw in the WPA2 protocol's cryptographic design itself, which remains secure.

The beacon frame reveals the BSSID, which is a security risk.

Why wrong: Broadcasting the Basic Service Set Identifier (BSSID) in beacon frames is a fundamental and necessary aspect of Wi-Fi network operation, not a security risk. The BSSID is simply the MAC address of the Access Point (AP) and is essential for client devices to identify and connect to a specific wireless network. It is publicly advertised by design to enable network discovery and communication.

Disconnect the thermostat from the network.

Why wrong: While immediately stopping potential malicious communication, disconnecting the device entirely is a highly disruptive measure that prevents further investigation into the nature and scope of the unusual traffic. This action removes the "patient zero" from the network, making it difficult to capture additional forensic data or understand the attack vector without a confirmed threat. A more targeted containment strategy is generally preferred for initial response.

Block all outbound traffic from the IoT VLAN.

Why wrong: Implementing a blanket block on all outbound traffic from the entire IoT VLAN is an overly broad and disruptive response. This action would indiscriminately disable legitimate functionality for all other Internet of Things devices within that segment, causing widespread operational impact without specifically addressing the identified suspicious thermostat. Targeted containment is crucial to minimize collateral damage and maintain essential services.

Uninstall the companion app from the user's smartphone.

Why wrong: Uninstalling the companion app from a user's smartphone is unlikely to resolve unusual traffic originating directly from the smart thermostat itself. The device's firmware or a compromised state is the more probable source of unauthorized outbound communication, independent of the mobile application's presence or functionality. This action misidentifies the primary point of compromise and fails to contain the actual threat originating from the device.

Compute the Pairwise Master Key Identifier (PMKID) from the PSK and AP MAC.

Why wrong: Incorrect. The PMKID is not required to decrypt captured traffic. It is used in a PMKID attack to verify a candidate PSK, but decryption requires deriving the PTK from the handshake nonces.

Use the PSK directly to compute the Michael Integrity Check (MIC).

Why wrong: Incorrect. The PSK is not used directly to compute the MIC. The MIC is computed using the Michael key derived from the PTK.

Obtain the Group Temporal Key (GTK) from the access point.

Why wrong: Incorrect. The GTK is used for broadcast/multicast traffic and can be decrypted from the handshake after deriving the PTK; it does not need to be obtained separately from the access point.

AWS Key Management Service (KMS)

Why wrong: AWS Key Management Service (KMS) is a managed service primarily designed for creating and controlling encryption keys used to encrypt data across various AWS services and within applications. While KMS keys can be protected by IAM policies that dictate who can use or manage the keys, KMS itself does not define or enforce the broader access control policies for AWS resources. Its role is data protection through encryption, not user authentication or authorization to resources.

AWS CloudTrail

Why wrong: AWS CloudTrail is an essential service for governance, compliance, and auditing of your AWS account. It continuously monitors and records API calls and related events made by users, roles, or AWS services in your account. CloudTrail provides a detailed history of actions, including who performed them, when, and from where, but it is purely a logging and monitoring tool and does not possess any capabilities to control or restrict access to AWS resources.

AWS CloudFront

Why wrong: AWS CloudFront operates as a global content delivery network (CDN) service, accelerating the delivery of web content and applications to users worldwide. Its primary function is to cache content at edge locations to reduce latency and improve performance. Although CloudFront can implement some access restrictions for the content it delivers, such as signed URLs or geo-restrictions, it is not designed to manage or enforce the fundamental identity and access permissions for users and roles interacting with core AWS services.

Disable the site-to-site VPN and require all traffic to go through a bastion host.

Why wrong: Disabling the site-to-site VPN is an inappropriate response as the VPN facilitates secure network connectivity between on-premises infrastructure and cloud resources, which is unrelated to unauthenticated PUT requests targeting AWS IoT Core. This action would severely disrupt legitimate business operations and data flows without addressing the specific vulnerability of unauthorized device communication with the IoT platform. A bastion host primarily secures administrative access to private network segments, not public-facing IoT endpoints.

Move the S3 bucket and DynamoDB table to the on-premises data center to reduce cloud exposure.

Why wrong: Moving S3 buckets and DynamoDB tables to an on-premises data center is an extreme and costly measure that fundamentally misunderstands the source of the vulnerability. The issue stems from unauthenticated PUT requests targeting AWS IoT Core, indicating a lack of proper authentication at the IoT endpoint, not the exposure or security of the backend data storage services themselves. This action would introduce significant operational overhead and latency without resolving the critical authentication gap at the IoT platform.

Replace all IoT sensors with new ones that have firmware-level encryption.

Why wrong: Replacing all IoT sensors with new ones featuring firmware-level encryption is an unnecessary and expensive undertaking that misidentifies the attack vector. The problem described involves unauthorized PUT requests directly to the AWS IoT Core endpoint, indicating a lack of proper authentication at the cloud service level, not a compromise of the physical sensors or their inability to encrypt data during transmission. While firmware encryption is beneficial for data at rest or in transit from the device, it does not solve the issue of unauthenticated access to the IoT platform.

Disable encryption on MQTT to reduce latency and improve performance.

Why wrong: 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 wrong: 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 wrong: 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.