By Ron Knode and Graham Logsdon Ask the CIO at any company with a mobile workforce, and you will find that wireless LANs work. WLANs are providing network access and data transfer for both general purpose and specialized applications. Yet the absence of a wire to contain the transmission of data and to control information introduces new security needs.

What is often missing in WLANs is the assurance that it is being used only by those who are supposed to use it; that only data that is supposed to traverse the WLAN is finding its way through; and that only known and approved data paths and access points are being used.

These unsettling issues can be addressed today with a process that identifies WLAN security requirements, organizes those requirements in a priority ranking that establishes an acceptable level of risk, then maps them to a set of controls that satisfies operational and cost requirements. Determining security requirements and allocating them to control mechanisms is the work of the security architect.

A bad news, good news, bad news, good news story

There’s bad news because of he ever-expanding alphabet of standards for WLAN technology. The terminology, rationale, differences, and interpretation of the standards can be baffling when trying to plan and implement a strategy for WLAN use. There’s good news because WLAN equipment vendors and integrators are successful at adopting and implementing the most widely applied parts of these standards.

The absence of a wire is more bad news. Because WLAN traffic is “floating” through the airwaves, it is available for anyone to capture, even those well outside the physical boundaries of the enterprise. The good news is that there are many “right” solutions to this predicament, and those solutions blend both architectural and operational controls to meet the most serious threats.

Architectural controls are essential, …

Architectural controls are structural in that they impose configurations and standards for operation. That means deploying the pieces of a WLAN in a way that satisfies security requirements. The type, number, and location of security components depend on the specific requirements of the enterprise and the level of residual risk that is acceptable.

For example, choosing a wireless access point (WAP) that supports Wi-Fi Protected Access (WPA or WPA2) encryption is an important architectural control for access, authentication, and encryption requirements. But that control is incomplete without establishing configuration standards, e.g., not broadcasting WAP service set identifiers (SSID). The same would be true of adding WAP controllers to accept and forward wireless traffic. Every device has to be configured and managed in accordance with security policy.

Choosing from among the possible alternatives depends on the enterprise risk threshold, the current wireless legacy environment, and cost constraints. For example, if a RADIUS service is already available, then that service can be extended to support the WLAN authentication. Likewise, if total end-to-end encryption is not required by the enterprise, then WPA2 is a sufficient encryption solution, and VPNs are not necessary.

Making architectural choices to deal with the control requirements of WLANs is often influenced by three typical constraints:

• If legacy special-purpose wireless devices (e.g., bar code readers) that are unable to meet the encryption standards have already been deployed, then special accommodation must be made for those devices.
• If “guest” users are likely to be present in the enterprise, then additional controls are needed to prevent full enterprise access to this special class of users.
• If enterprise WLAN devices (e.g., laptops) must also operate in completely unsecured environments (e.g., at home or at Starbucks), then alternative and automated connection recognition and selection methods must be included in the individual devices.           

… but so are operational controls …

Still, as strong as they are, architectural controls do not solve the whole security problem for WLANs. However the network configuration is arranged, and whatever concept of operation is adopted for users to obtain access, there remains a set of operational security mechanisms that must be applied as well. Operational controls are ongoing dynamic actions that monitor and enforce the policy statements and architectural control assumptions in the secure WLAN service.

Many types of accidental violations of WLAN security policy are possible. Since WAPs are so small and simple to install with default settings, it is easy to unwittingly introduce an exploitable wireless LAN. Suppose an employee who really needs an ad hoc workgroup to collaborate on a tight deadline goes into her office, unplugs her PC, takes a WAP out of her purse and plugs the WAP into the network interface. All of a sudden, a WLAN is born! And, that WLAN is just as available in the parking lot as it is in her office.

Architectural controls alone would not detect the introduction of an unauthorized WAP. Only monitoring (not configuration) can quickly detect these rogue access points, which is why operational controls are necessary to detect violations of security policy.

… and awareness and trust.

Mobile, wireless technology is wonderful, but it creates new security problems. Physical barriers and guards in building lobbies have long been trusted countermeasures for controlling access to wired networks. “If you can’t get to the wire, you can’t get to the network.” The advent of ubiquitous wireless technologies means the loss of physical control. New security solutions with carefully thought out architectural and operational controls must be applied to maintain the confidence and convenience of a secure network.

The end users must be aware of the secure WLAN policies and capabilities, and must see the controls in operation. Architectural controls set the security foundation, and operational controls sustain and enforce the policy directly to the user. This is how successful SWLAN solutions bring trust to the world of wireless networking.

Ron Knode is a director and LEF Associate in CSC’s Global Security Solutions (GSS). Graham Logsdon is a security architect in GSS.