Factors to Consider while Evaluating a Wireless Security Solution

Factors to Consider while Evaluating a Wireless Security Solution

By CWNP On 08/24/2010 - 23 Comments

Wi-Fi proliferation and increased awareness about associated security risks is prompting many organizations to install Wi-Fi security monitoring systems, for which the industry term is WIPS (wireless intrusion prevention system). Protection from rogue APs, WiPhishing, corporate client connections to neighborhood APs, mis-configurations of authorized Wi-Fi, wireless DoS attacks, spoofing, and zero-day attacks are some of the commonly cited reasons to install WIPS. There are many WIPS solutions available in the market today, including those offered by WLAN infrastructure vendors and those offered by dedicated security vendors. However, WIPS being a relatively new security technology, organizations often face challenges in evaluating these solutions to determine what best suits them. More so, many end-users may not have the level of dedicated wireless skills and resources required to thoroughly test a WIPS. In this light, this article lays out some high level considerations that are important while evaluating a WIPS solution.

1) What types of rogue APs on the network is the WIPS designed to detect?

Rogue APs on the network are the mother of all Wi-Fi threats, and protecting from them should be on the list of Wi-Fi security objectives for every organization. Rogue APs often get connected to the enterprise network, either by an unassuming employee or by malicious insiders. Such rogue APs on the network can provide access to the enterprise network for outsiders. From the wireless side, a wireless connection between the rogue AP on the network and the outsider client looks like a connection between two MAC addresses which do not belong to the enterprise Wi-Fi, much like a wireless connection between a neighborhood client and a legitimate AP of the neighbor (whose MAC addresses also don’t belong to enterprise Wi-Fi). But what differentiates the former (threat) from the latter (friendly neighborhood activity) is the wired connectivity of the AP to the enterprise network in the former case. Hence detection of wired connectivity of rogue APs to the enterprise network becomes important to detect the threat of rogue APs on network.

APs differ in nature on many dimensions such as:

• bridges vs. routers
• using wireless encryption vs. using open wireless links
• default state vs. having configuration changes done on them
• wired and wireless network interface properties
• hardware APs vs. software APs instantiated on end user devices
• APs connected to different VLANs (subnets) in the network.

Different permutations and combinations of these properties present different types of challenges for WIPS in detecting if that AP is connected to the monitored enterprise network. That is, some of the scenarios can be detected by wired only scanning while some necessarily require wireless side scanning, some can be detected by passive traffic correlation while others require active probing, even with active probing there are several ways in which it is done.

So, it is first essential to define the types of rogue APs on network that are considered potential candidates in the organization’s network and then to ensure that the WIPS properly detects them all.

 2) Does the WIPS integrate into managed switching infrastructure, or does it operate independent of it?

Not only is it important to examine the types of rogue APs on the network that the WIPS detects, but it is equally important to assess how the WIPS performs detection of rogues on the wired network. Broadly, there are two types of techniques available to detect rogue APs on network. First is based on using information in network switches to perform traffic correlation between wired and wireless domains to detect rogue APs on the network. This requires maintenance of switch properties in the WIPS, so that the WIPS can poll the switches for information (Is the MAC address of the client connected to a rogue AP visible in the wired domain?). The second technique is based on information gathered by the WIPS itself from traffic in the wired network to perform traffic correlation between wired and wireless domains. Some systems also actively generate special rogue detecting packets in the network. The second method does not require maintenance of switch properties in the WIPS.

Depending on factors such as how security and network operation teams operate (in close collaboration, or more or less independent), the size of network, availability of managed switches to the edge, vendor mix in the switching infrastructure etc., a judicious choice of rogue detection architecture must be made.    

3) If automatic wireless threat remediation (also called over-the-air blocking) is required, what are implications of false alarms in the WIPS?

Different organizations have different perceptions about the window of time in which a potential wireless threat should persist. For those who want this window to close instantly (rather than waiting for manual administrator remediation), automatic remediation is important. Further, most wireless threats can only be blocked over-the-air, notably ad hoc connections, WiPhishing, corporate clients connections to neighborhood APs and even many types of rogue APs on the network whose wired side connection point (switch port) cannot be precisely determined.

In over-the-air blocking, the false alarms consideration becomes important. There are two types of false alarms: false positives and false negatives. A false positive means incorrect tagging of a benign neighborhood activity as a threat to the enterprise assets. If automatic over-the-air blocking gets triggered on a false positive, the WIPS can disrupt benign neighborhood communications, such as normal client/AP activity or ad hoc networks. Such accidental neighbor disruption is totally unacceptable in the over-the-air prevention.

On the other hand, a false negative means incorrect tagging of a credible threat as a benign activity or a threat of lesser severity. The false negative may result in automatic prevention not triggering when it should, leaving the enterprise assets exposed to the threat. A typical example of the false negative is a rogue AP on the wired enterprise network not tagged as on-network by the WIPS.

To analyze false alarms, it is essential to let the system run in a production environment for at least one week, since all the dynamic wireless environment parameters that trigger false alarms cannot be simulated in a controlled lab setup. Many of the false alarm triggers are statistical in nature and manifest when the system is “worked up” in busy production environment.

4) What types of wireless threat remediation techniques are used by the WIPS?

One more thing to keep in mind with regards to wireless threat remediation is that even though all Wi-Fi devices follow the same IEEE 802.11 standard (and may even be Wi-Fi Certified), nuances in their implementations often pose challenges in over-the-air blocking of their communication. To cite an example, commonly used over-the-air blocking with forced de-authenticate messages may work on ad hoc connections with Dlink Wi-Fi client cards, but the same may not work on ad hoc connections with Centrino Wi-Fi clients. This is true even if Dlink Wi-Fi clients can form an ad hoc connection with Centrino Wi-Fi clients.

Hence, it is important for the WIPS to demonstrate that it has wireless threat remediation techniques that will cover all different violation scenarios and devices that the organization’s security policy demands. It is also worthwhile to measure the capacity of WIPS in terms of being able to block multiple simultaneous threats on multiple channels, since violations such as mis-associations often happen in bulk on multiple channels.

5) How many alarms does the WIPS generate?

Broadly, there are two types of approaches to wireless intrusion prevention. The first approach sends fine grained alerts to a user for every event that appears suspicious. On the other hand, the second approach processes fine grained details on suspicious events, draws concrete inferences, and raises alerts to a user only when the result of analysis points to a security threat or vulnerability.

The first of the above approaches may be machine-error proof, but it requires manual intervention and analysis on a continuous basis. This is because perturbations to wireless traffic (your own as well as in your neighborhood) constantly happen even in smooth running networks. On the other hand, if one wants to go with the second approach, it is necessary to evaluate how the WIPS’s logic of filtering alarms works and to ensure that it will not filter alarms that administrators want to know about. In general, when it comes to “alarms volume”, I would recommend focusing on security and operational objectives, rather than mechanical “more alarms equals more security” approach.

6) How much configuration does the WIPS expose to the end-user?

Here again, there are two types of approaches. The first approach relies on receiving detailed configuration from the user regarding how the system should behave. The system then executes user defined rules and performs user defined actions. For example, the system may ask the user to define rules to be matched with properties of APs to classify them into threatening or friendly classifications. On the other hand, the second approach provides built-in policy rules, with only fine-tuning options. For example, in this approach, the system may have built in rule sets regarding which APs should be called threat posing (e.g., unmanaged APs connected to enterprise network are threat posing) vs. which should be called friendly (e.g., neighborhood APs that do not attract wireless clients are friendly).

At first sight it looks like the first approach gives greater control over the system behavior. The flip side, however, is that it takes considerable skill to define those rules, and requires a process and resources for maintaining them in dynamic wireless environments. On the other hand, if you want to go with the second approach, you must evaluate why the system’s built-in rules have sound security underpinnings and if the less flexible approach of preset, automated, vendor techniques meet your requirements.

7) How does the WIPS facilitate ease of day-to-day operation?

From a day-to-day security management perspective, the WIPS may need to provide some useful features. For example, some WIPS deployments can get very large – spanning different networks, buildings, and campuses. To cater to this scale, the WIPS may need to provide a location context sensitive security console which can be managed independently by different administrators at different locations, while providing a bird’s eye view for the super-administrator at the top.

For some organizations, periodic reporting for regulatory/standards compliance is essential. The WIPS then needs to provide automated report generation so that the administrator is relieved of this task on a day-to-day basis and there are no lapses.

Also, administrators often have to look at previously collected data to analyze events/incidents of the past. For this, the WIPS will need to provide forensics capability to facilitate the administrators to search, sort, and correlate security events/incidents of the past.

The various selection factors described above can serve as guideposts for the WIPS evaluators. End-users can then expand on these criteria with their own application-specific criteria and network needs to come up with their own test scripts and criteria to evaluate a particular wireless security solution.

(CWNP Editorial Note: Hemant is the Director of Technology for a leading WIPS vendor. To avoid bias, he refrained from discussing the topic of overlay vs. integrated WIPS. That is one of the most important factors when evaluating a WIPS because there are significant tradeoffs with either approach.)

Tagged with: security, WIPS, WiFi, evaluation, test-cases, WIDS

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.