No matter how much detail one provides to upper management regarding a vulnerability or a security issue, sometimes a technology that isn't in the company's best interests is approved.
My problems started when an executive within the company proposed building a LAN infrastructure using an 802.11b wireless LAN. By his figures, rolling out wireless would help the company avoid more than US$2 million per year in lost productivity. I have a hard time believing that we would save that much, and I've yet to see any supporting documentation. Most of our employees have offices or cubicles with wired connections, and each conference room has enough Ethernet drops so that anyone who wants to connect his laptop to the corporate network can do so easily.
A few months ago, when the decision was made to implement a wireless network, Windows NT administrators within the IT department did the initial implementation on our development network. They're very good administrators, but they knew nothing about wireless technology and installed everything using the default settings. This included using the notoriously insecure 40-bit Wired Equivalent Privacy (WEP) protocol encryption and the default Service Set Identifier (SSID) codes that identify the wireless hubs on the network.
Upon reviewing the install, my team was able to demonstrate how weaknesses in the implementation would allow a hacker with freely downloadable software and a $100 wireless LAN card to sit outside our building and gather information that would then let him gain access to our corporate network. We positioned ourselves on the street in front of our building and used these tools to start collecting packets and crack the WEP algorithm. I'm not a cryptographer and don't know the details of WEP encryption. But by using these tools, which compiled easily on our Unix server, I was able to collect network packets and crack the WEP key.
After I demonstrated this to our CIO, he trashed the wireless project, and that appeared to be the end of it until three weeks ago. Suddenly, the executive staff was at it again, deciding that we should implement a wireless LAN anyway. We were being forced to implement a technology that has a history of being insecure. Although I didn't think the benefits outweighed the security risks, the deployment was happening anyway. So we had to make the best of it.
Fortunately, I was able to convince management that my team should at least specify the products and configuration to improve security. After reviewing the options, we decided to require Cisco Systems Inc.'s Aironet access points and adapters, which include enhanced security features.
Like many products, Aironet supports stronger, 128-bit encryption. But the feature that attracted us was Aironet's Lightweight Extensible Authentication Protocol (LEAP). With LEAP, Cisco decouples authentication from the encryption process by supporting the use of an external Remote Authentication Dial-In User Service (RADIUS) server to authenticate wireless LAN users. In traditional wireless systems, anyone with the proper SSID and password (used for WEP encryption) can become a node on the network. With LEAP, even if someone were to compromise the SSID and the encryption key, he would still need an account on the RADIUS server to gain access to the LAN.
Aironet also lets administrators establish a midsession reauthentication policy. We plan to configure this feature so that users are forced to authenticate again every 30 minutes. This type of policy disrupts a hacker's ability to intercept packets and crack the session key, which could be used to gain entry to the network.
We already have Cisco's Secure Access Control Server to authenticate our virtual private network (VPN) users, and we're going to force the use of a VPN tunnel for wireless access to our corporate infrastructure. We'll use our current installation of VPN concentrators and configure them so that only the required level of access will be authorized for each wireless user. For example, if a sales employee accesses the network wirelessly, he will have permission to access only e-mail, the intranet Web site and specific sales force tools. On the other hand, a Unix administrator will have permission to access the gateway servers we use to control access to our critical Unix servers.
We also plan to require the use of a token for those individuals who have permission to access critical servers via their wireless connections. This way, if a compromised laptop has passwords either stored in clear text or cached in the application, the potential hacker won't be able to break in unless he has the user's token. This may seem like a lot of extra overhead on our users and their equipment, but we can make it virtually invisible to the end users aside from the occasional requirement to reauthenticate and present the SecurID token.
There are certain levels of exposure with almost any technology, and wireless is no different. However, Cisco's technology, coupled with our current installation of RADIUS and VPN services, should provide a reasonably secure environment for our employees.
Our security team presented its recommendations to upper management, and they have agreed with the proposed design. The next step is getting the new infrastructure into the lab to ensure everything works as planned.
But we're not done yet. If you've had a chance to play in the wireless space and can offer some suggestions, please feel free to share your experiences in the Security Manager's Journal forum. wSix-Step Program for Wireless LAN SecurityThe six main features of the wireless LAN security strategy at Mathias Thurman's company:
1. Enable 128-bit session encryption.
2. Configure RADIUS server authentication.
3. Force 30-minute periodic reauthentication for all users.
4. Require use of VPN to access critical resources.
5. Restrict LAN access rights by role.
6. Implement two-factor authentication scheme using access tokens for users accessing critical infrastructure.