In principal, using APs for WIDS monitoring can reduce install cost by leveraging existing hardware, Ethernet switch ports, Cat5 cable runs, and power drops. Since your WLAN Controller or Manager will be acting as your embedded WIDS server, you also will not need another platform on which to run overlay WIDS server software.
But, in practice, each system can only do so much. You may need to install more APs to shoulder the burden of WIDS, or to completely cover vulnerable areas. The I/O and CPU load placed on a WIDS server can be quite heavy, so your WLAN Manager platform may also need to be scaled up to do both jobs at once.
Furthermore, some sensors avoid the need for new cables by using dual Power-over-Ethernet ports for insertion between switch and AP. In addition to dedicated sensors, most overlay WIDS can use selected APs (e.g., Aironet) for monitoring, sacrificing some functionality. On the flip side, most embedded WIDS allow APs to be configured as full-time monitors. So don't get hung up on labels: determine how many monitoring devices you'll need and then compare installed per-unit cost.
For companies using WIDS to enforce a "no wireless" policy, overlay WIDS is the only real option -- there are no existing APs to reuse. Other companies with installed WLANs should take a hard look at their WIDS coverage needs.
Your WIDS footprint should be slightly larger than your WLAN footprint. Rogues may lurk just beyond the reach of legitimate APs, luring users into associating with them or launching attacks that you cannot otherwise see. Either dedicated sensors or monitor-only APs can be added to extend spatial coverage.
APs use specific frequency bands and assigned channels within those bands. A WIDS should always scan beyond those channels, because unauthorized APs and Ad Hoc stations are more likely to occupy unused channels. An off-the-shelf 802.11b/g AP cannot monitor 802.11a channels, or frequencies in the 2.4 GHz band used only in other countries. Purpose-built WIDS sensors can usually scan more frequencies, although product capabilities vary.
With an embedded WIDS, APs spend part of their time servicing wireless clients. Spare time is spent monitoring that channel, or scanning other channels. With an overlay WIDS, monitoring traffic is the sensor's primary task, although it may spend some time on other WIDS tasks, like blocking rogues.
Some traffic is going to be missed by every WIDS -- the intruder may be too distant, the signal may be too weak, the transmission may be too short. In fact, any device scanning channels in RFMON mode is sequentially sampling traffic on every channel in the list. The goal is to listen long enough, often enough, to have a decent chance of spotting attacks, policy violations, and rogue devices.
In a busy WLAN, a full-time sensor is clearly going to hear more traffic. Short-duration attacks are more likely to be missed by a part-time AP, as are relatively quiet rogue devices like bridges. A part-time AP will also have less spare time to perform other WIDS tasks -- for example, a full-time sensor may block more rogues, more persistently, and thus more effectively.
However, in a lightly-used WLAN, a full-time sensor can't put spare cycles to good use, while an AP might have enough horse power to do two jobs well. To balance cost vs. risk, you can mix full-time sensors in major facilities with part-time APs in small branch offices, adding more full-time sensors where it becomes clear that they are needed to satisfy security requirements. Impact on WLAN
AP time-slicing not only impacts WIDS effectiveness -- it also impacts the WLAN's performance. But this can be difficult to quantify. Potential impact depends on AP loading, client density, application traffic, scan list/duration, and other WIDS tasks. For example, an Aruba paper reports that "Multi-vendor lab testing recently found that when using scanning APs for both client services and off-channel monitoring, a throughput drop of up to 16% was possible when APs were required to spend significant time off-channel."
Dedicated sensors or monitor-only APs cannot adversely impact the WLAN's performance. In fact, because they gather more complete information, they may be more helpful when it comes to trouble-shooting WLAN performance problems.
On the other hand, when push comes to shove -- an AP fails, or client demand suddenly spikes -- a dedicated sensor cannot be temporarily placed into active duty to boost a struggling WLAN's performance. From a security perspective, keeping your monitoring infrastructure intact is an asset. But from an operations perspective, service availability is usually top priority.
Purpose-built sensors support WIDS functions not found in commercial APs. Ability to scan "off" channels is one such function. A purpose-built sensor may even be able to scan non-802.11 traffic to fingerprint RF interference sources like microwave ovens and Bluetooth.
As the market matures, overlay WIDS are placing more demands on purpose-built sensors. In particular, sensors are being used to implement new rogue defense strategies. Any AP can generate deauthenticate or disassociate packets, but some sensors are now being used as wireless clients. For example, a sensor may associate to a rogue AP to trace back network connectivity. A sensor may try to lure a rogue Ad Hoc, keeping it busy while responders try to find and eliminate that device. Because a purpose-built sensor is incapable of behaving as an AP, there is also less risk of a firmware bug being exploited to create a wireless backdoor into the wired network.
Part-time APs can be augmented to provide additional WIDS capabilities, but realistically, developing new WLAN functions may take priority over new WIDS functions. Furthermore, no matter how much an AP is capable of doing, a part-time AP is not well-suited for performing WIDS tasks that require sustained activity (e.g., creating a traffic capture for a designated channel or device, persistently deauthenticating a large number of rogues). Integration
Another concern regarding any type of overlay is proliferation of consoles and databases and integrating them to facilitate coordination and avoid duplication.
An embedded WIDS is more likely to provide a single, integrated management interface through which you can both configure and monitor your WLAN. An embedded WIDS has built-in criteria with which to differentiate between legitimate APs and rogues, while an overlay WIDS must be configured with (or import) a list of legitimate APs. When an embedded WIDS decides to disable a rogue's wired network access, that WLAN Controller may be directly responsible for managing the port anyway (e.g., Cisco WLSE). While many overlay WIDS can send SNMP requests directly to Ethernet switches, it may be preferable to relay switch configuration requests to the responsible management system.
This difference is becoming less clear-cut as product integration increases. For example, Trapeze includes "core" WIDS capabilities in its WLAN Mobility System (an embedded WIDS), but has also been integrated with AirDefense (an overlay WIDS). Colubris Networks recently integrated AirTight Network's WIDS technology into its InCharge RF Manager.
Segregation of duties
Finally, look beyond differences in approaches and products to consider organizational impacts and policy requirements. In some companies, network operations and security compliance are the responsibility of different organizations. WLAN components may be chosen based on their ability to deliver network, not security, services. The organization responsible for security monitoring may not be authorized to use existing APs for WIDS. In fact, some companies explicitly require Segregation of Duties for security audit personnel and tools.
Choosing a WIDS should be based on many factors -- embedded vs. overlay is just one (albeit important) consideration. We hope this tip helps you to better understand that consideration, so that you can match dedicated sensor and AP monitoring capabilities to your company's requirements.
>> Read the next tip: Using your WIDS to monitor WLAN performance