Wireless, IoT and Cloud Security practice questions

Use WPA2-PSK with a strong passphrase.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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.

Enhanced network segmentation

Why it fails: 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 it fails: 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 it fails: 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.

The attack failed because WPA3-Enterprise requires a RADIUS server, and the captured frames are encrypted with a unique session key that is not derivable from the password alone.

Why it fails: While WPA3-Enterprise does use a RADIUS server for authentication, the SAE handshake occurs before the RADIUS exchange and is used to establish a secure channel. The session key is derived after authentication, but the reason offline dictionary attacks fail is not because of the RADIUS server or session key encryption; it is because the SAE handshake itself does not allow offline password verification.

SAE uses a 256-bit elliptic curve group, and the computational effort to test each password guess offline exceeds practical limits, making the attack infeasible.

Why it fails: The use of elliptic curve groups in SAE does not inherently prevent offline dictionary attacks; if the protocol allowed offline verification, the curve size would not stop an attacker from testing guesses. The security comes from the protocol design, not the computational difficulty of the group operations. Therefore, this is not the correct reason for the attack failure.

SAE uses a Diffie-Hellman key exchange that provides forward secrecy, so the captured handshake cannot be used to derive the session key even if the password is guessed.

Why it fails: This is incorrect because SAE's forward secrecy prevents deriving the session key from a captured handshake, but an offline dictionary attack against SAE does not try to derive the session key; it attempts to confirm a password guess by checking whether the guessed password produces the observed commit message. Forward secrecy does not prevent this confirmation, so the attack failure is not due to forward secrecy.

Apply resource-based policies on the S3 buckets and DynamoDB tables that explicitly deny access to the Lambda function's role.

Why it fails: Applying explicit deny policies would block the Lambda function from accessing the resources it needs, breaking functionality. The goal is to maintain functionality while reducing permissions, not to deny all access. Resource-based policies can be used for cross-account access, but here the issue is the identity-based policy of the Lambda role. Denying access would not achieve least privilege.

Enable AWS CloudTrail logging for all Lambda invocations and analyze the logs to identify the specific API calls made by each function.

Why it fails: Enabling CloudTrail logging is a monitoring and auditing step that helps identify actual usage, but it does not directly remediate the excessive permissions. While it is a good practice for understanding what permissions are needed, it alone does not reduce the over-privileged access. The engineer must take further action to restrict the permissions based on the findings.

Replace the Lambda execution role with one that has the AWS managed policy 'AWSLambdaBasicExecutionRole' attached.

Why it fails: The AWSLambdaBasicExecutionRole only grants permissions to write logs to CloudWatch. It does not provide access to S3 or DynamoDB, so the Lambda function would lose necessary access to those services and fail. The engineer needs to grant the specific S3 and DynamoDB actions that the function requires, not remove all access.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

AWS Key Management Service (KMS)

Why it fails: 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 it fails: 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 it fails: 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.