When reports began circulating in mid-2001 that researchers had found the IEEE 802.11 WEP (Wired Equivalent Privacy) security system was vulnerable to attack, the news cooled an extremely hot wireless LAN market. Wireless technology's performance, interoperability and manageability continued to improve, while security loomed as an insurmountable hurdle.

Indeed, when Network Computing led a four-city "Solutions Summit" on WLANs (wireless LANs) late last year, nearly 80 percent of the 300 attendees identified security as the greatest obstacle to deployment of wireless LANs in their organizations. Our recent WLAN security reader poll confirmed these impressions. Fewer than one-third of the respondents said they would be willing to accept a little less security in exchange for the benefits of wireless network access.

But the biggest barrier to implementing WLAN is beginning to come down. If you're contemplating adding wireless LANs to boost productivity in your organization, you can implement a secure system. However, the IEEE 802.11 Task Group 1 has struggled to gain enough vendor consensus to get new wireless security standards out the door. On a more positive note, a broader and more robust set of products based on existing 802.1X standards has begun to appear in the market. In addition, a number of vendors have jumped on the obvious market opportunity and released WLAN security overlays that provide a range of enhanced services, addressing the major problems. Agere Systems, Cisco Systems, Proxim Corp., Symbol Technologies and others have enhanced their WLAN security offerings, though their solutions often force you to forsake multivendor interoperability.

In implementing a secure WLAN, you'll need to ante up to acquire security hardware and software and accept the burden of increased complexity. One size definitely does not fit all. First, you need to understand the key elements of a comprehensive WLAN security system. Next, you must assess your organization's level of risk aversion and the price you are willing to pay to achieve security. Finally, you have to understand the alternative systems available.

Protecting a PBX used to mean locking it in a closet and controlling access to the keys and any attached modems. If you were really security conscious you might go so far as to make sure incoming lines couldn't be tapped, short of using shovels and jackhammers, but times have changed: While concerns over physical security and toll bypass are still relevant, a whole new set of issues comes into play when your PBX is part of and accessible through your IP network.

Don't Be the Weakest Link

The relationship between the network people and the telecom group can be rocky enough without having your PBX be the route a cracker takes to get to the main corporate network. In some cases, the very reason you bought your IP PBX--to have a full feature set--can turn around and bite you. Turn off unneeded services, such as forwarding, call distribution and override, and grant administrative access carefully, with an eye toward physical security of maintenance and attendant consoles. The PBX should not let traffic pass through it. Many IP PBXs ship with two NICs; make sure traffic cannot travel from one NIC to the other. In addition, if your vendor performs updates and maintenance of your PBX remotely, closely watch external access control.

Many fundamentals of securing your IP PBX parallel the basics common to safeguarding your data networks:

Asynchronous Transfer Mode - what a mouthful of vague abstractions. If there weren't so much money and job security riding on ATM, it would be awfully tempting for many of us to ignore it. A transfer mode is a method of transmitting, multiplexing, and switching data in a communications network. (Multiplexing is combining multiple streams of data on a single circuit; if it weren't for multiplexing, the view of the sky in our cities would be blocked by telephone wires.)

It's only possible to understand "asynchronous" by getting a grasp on "synchronous". The terms refer to digital signals; more specifically, they identify two ways that units of data are framed or blocked within a stream of bits. Synchronous signals are closely tied to some sort of clock, so each unit of data begins, for example, precisely at 0.0ms, then 7.5ms, then 15.0ms, then 22.5ms, and so forth. Asynchronous signals are not bound tightly to a clock - perhaps their data units have a start and a stop bit, or some kind of unique bit pattern to identify the beginning and end of a character or a packet.

Most serial communications and practically all LAN communications are asynchronous, but most data transfers in and out of your microprocessor, the traffic on your parallel port, and the traffic on your computer's bus, are synchronous. Given a steady stream of data, synchronous transmission tends to be more efficient than asynchronous, while asynchronous transmission tends to be more flexible and resilient.

Like traffic in a large city, traffic on a WAN is sometimes unpredictable, and your best bet is knowing an alternate route. To ensure that your packets get to their destinations in the most efficient manner, you've got to route them on a particular VC (virtual circuit) based upon the destination point. Traffic is relegated to a specific path through a network and doesn't deviate from that path. While this has been the basis of both frame relay with DLCIs (data link control identifiers) and ATM with VPIs/VCIs (virtual path identifiers/virtual channel identifiers), not all traffic can be routed in this manner. Pure IP networks are entirely different: IP routing over large networks is a step-by-step process. Based upon its routing table, each router along the way analyzes the header and determines the best path for the next leg of a packet's journey.

This can be extremely inefficient, as each router spends precious time examining each packet and determining to which router the packet is sent next. The amount of information held in most headers isn't enough to let a router send the packet all the way to its final destination; the routers rarely if ever have a complete view of the path each packet takes.

The other way of getting IP traffic to its destination is by broadcasting it. Basically, broadcasting a packet means sending it everywhere in the hope that it will end up where it was supposed to go eventually. This method has an obvious drawback in that traffic on the broadcast network is unbearably slow because every router has to deal with every packet no matter if it is meant for Timbuktu or Antarctica. Security is also nonexistent in a broadcast network because every router on the network has access to every data conversation taking place.