SP 800-153 Guidelines for Securing Wireless Local Area Networks (WLANs)

Status: Final Published

Date: February 2012

Region: United States

Document: Link

Background

The NIST SP 800-153 document was developed to provide security guidance for WLAN connections based on the IEEE 802.11 specification. This standard is meant to supplement, not override any other NIST documents, guidelines, and standards related to communication security. The SP 800-153 is considered one of the vital digital security documents aimed at providing the groundwork for a significant portion of IoT connections, including applications that relate to the smart city/automotive combination.

Summary

WLAN Network Architecture: WLAN connections are characterized by the wireless communication of networking devices within a certain geographic area (key applications include building automation or industrial settings). WLAN depends upon the following three components: 1) the gateways/routers that allow the connection, 2) the devices (CE) that connect to said routers, and 3) the Wireless Access Points (WAPs or simply APs), which are the hardware components required to allow connectivity, even if there is no router in range. Different security requirements are needed in order to protect the network and its components, and the document focuses on suggestions related to the networks themselves rather than the devices that connect to them.

Security Assessment and Monitoring: The NIST makes another important suggestion regarding WLAN security assessment and monitoring. These two terms describe the periodic or continuous processes that relate to an organization assessing and monitoring the security aspects, traffic, and behavior of their WLAN networking systems. A great deal of the suggestions relate to attacker tunneling from WLANs to wired connection for dual systems, which is not relevant for this security study.

Passive Threats: The SP 800153 states that attackers can passively eavesdrop on WLAN connections, gathering information about all involved parties, message content, and all related intelligence. Continuously monitoring car systems is a lot more challenging than enterprise settings. Monitoring for this threat is usually insufficient because the attackers are simply eavesdropping, not generating traffic. Therefore, implementers are advised to monitor car systems at predetermined time frames, or after any suspicious network shift. This can be achieved locally through the use of dedicated systems like Intrusion Detection and Prevention Systems (IDPS).

Active Threats: Fraudsters can also actively engage in DoS attacks, use replay attacks posing as legitimate users to request information from any connected system or online resource, and even modify any message sent. This case requires more sophisticated security tools. This includes systems that place a threshold over the number of requests (i.e., DoS prevention), make use of User and Entity Behavioral Analytics (UEBA) to effectively monitor traffic and abnormal user or system behavior, or even wireless IDPS sensors that can prevent rogue devices from spoofing the identity of another system. This is referred to as in-vehicle IDPS and can be used to detect anomalies in automotive ECUs.

Identify WLAN Security Requirements: As expected, all wireless connections are considered highly insecure when compared with their wired counterparts. Organizations should carefully plan out the security requirements for their target application, which may well extend into laws and regulations from governmental and regulatory bodies like the Department of Homeland Security or the Government Accountability Office (GAO). Each application has its own threat vectors and companies are expected to research these ahead of time in order to safely design the basic WLAN networking blueprint. For the task at hand, the following market segments are targeted: automotive, smart home, smart cities, and related applications like connected parking, in-car payments, etc.

Architecture Suggestions and Caveats: The NIST explicitly states that security architecture should not focus on the organization’s WLAN network, but also calculate how it will be affected by other networks that are accessible through it. Separating WLANs and addressing security concerns in a different manner should also be one of the top priorities (e.g., internal use versus external use, high-priority or critical sys- tems versus secondary functions, etc.). This measure is meant to address a serious security concern: network tunneling. Cyberattackers can essentially tunnel traffic and leap from one insecure, secondary sub-network (e.g., guests) to a higher-security one (e.g., corporate) based on architectural flaws that exist in the relationship between these two networks. This also applies to “dual” connections and devices that can connect to multiple wireless interfaces. This may include, for example, a laptop that is both wirelessly and Ethernet connected, or a smartphone device that connects both to public or other networks and an automotive system at the same time. Suggestions to address the above include:

• Configuring the system to deny other network interfaces (or at least permit only some)
• Deploy OTA updates or specialized software that allows connection in either WLAN or wired
  access, but not both simultaneously
• Enforce host-based tools (gateway firewalls and intrusion detection/prevention systems) to
  prevent any external networks to access car systems
• Account for the fact that CE or poorly coded third-party car infotainment apps may sometimes cause an override in the above measures

Notes

Note that some of the aforementioned insights follow the same pattern covered in the NIST’s SP 800-187 Guide to LTE Security. Many of the attacks are also quite similar, but relate to WAPs instead of cellular communications. They also follow similar analysis covered in the UNECE Recommendation on Software Update Processes. Taken together, all three aforementioned documents give a more complete picture regarding the three key threat vectors for securing communication in the connected car:

a) securing cellular connectivity and maintain data integrity and confidentiality, b) protecting OTA security updates and standardizing the manner in which said updates are addressed, deployed, maintained, and monitored, and c) addressing security for wireless access communication, which has a direct effect on all incoming-outgoing communication with certain smart city applications—also considered a vital aspect for the future evolution of the connected vehicle.