Wireless Water Cooler

A few days ago I read an article regarding security and compliance in retail. As we are well aware a retail space can consist of both guest and enterprise environments. Of course, the article rightfully focused on the protection of enterprise systems (i.e. POS, back office, inventory, etc.) within an enterprise environment. The strategies presented were accurate and consisted of such topics as detection throughout a transactional process, multi-level protection, and security education. As a wireless and (aspiring) security professional I immediately realized that, although accurate, the strategies presented did not account for a wireless environment. More specifically, the article did not account for the installation and verification (or sign-off) of an enterprise wireless environment. Before applying any post-deployment strategies a network architect must ensure that the environment is, at the very least, initially pristine.

Many retail organizations handle the wireless deployment (installation, configuration, verification) in-house. For organizations that adopt that model, hiding the SSID, changing the passphrase to the SSID after every deployment, MAC authentication, and the proper ACLs may be enough. But what if the retail organization is a nationwide enterprise with 500+ locations and has employed the services of an MSP? One can still hide the SSID, but now the SSID and passphrase are known by someone outside of the retail organization - namely, the installer. In fact, the "hidden" SSID and passphrase can be potentially known by 500+ WLAN installers (non-employees). In such an environment, changing the passphrase and/or SSID after every deployment is no longer scalable.

Part of ensuring that the environment is pristine consists of ensuring that only those that require network credentials to the enterprise environment actually have the credentials to the environment. Without a viable, comprehensive solution to this potential catastrophe, not only is the network in danger, but so are the installers. If there is a security breach during the deployment of this large nationwide network, the integrity of the installers, along with anyone else that has knowledge of the network SSID and its credentials, comes into question. So my questions to the community are the following:



How do we better protect the networks?
How do we better protect the installers?
@keepitmobile - http://keepitmobile.wordpress.com/2014/05/01/the-forgotten-strategy-of-security-and-compliance/
#ALE

I reckon use certificates and dot1x. Don't bother hiding the ssid either you can find that out very quickly. The security of a system depends on the use case. When you say passphrase I guess you mean for a psk. You can inject traffic into most aps and gather data for brute force decryption to decipher the static encryption key so don't use it. Let's be honest, Mac spoofing isn't rocket science either so I'd only use that for like guest auth, or in a really tightly controlled role as a last resort. You need to do deep packet inspection and protocol analysis and make decisions there, which for me was one of the selling points on the Aruba for me personally. Then feed it all back in to a central repository for analysis and more intelligent deciding making. Face the fact you will always get coverage bleed outside your premises and act on this assumption. My pennies worth.

Thanks for the insight. I appreciate your perspective. Regarding the protection of the installers, I agree that dot1x would be effective. For the location where the deployment is occurring, restrict the amount of time and access that an installer can have to the network (while still providing him with enough access to verify that the network works as configured). A couple of people have recommended that I have the store manager connect to the enterprise network and complete the verification. I have major concerns regarding that approach (By the way, that recommendation is part of my reason for writing my initial post):

 

1. A store manager (or any other customer employee) is normally not qualified to properly verify the functionality of the network.
2. A store manager has not been hired to deploy any aspect of the network. The store manager does not have contract with the MSP and are not on payroll. (I probably sound a bit extreme or paranoid but I imagine that legal departments for both the MSP and customer will have a cow over that.)
3. In the event that there is a security breach, it would be embarassing to discover that the security breach could have been discovered and properly escalated by a qualified professional during the verifiaction process of the deployment. (This is why legal departments would have a cow.)

In addition, I want to log the time the installer's device connected the network, the time the device was authenticated, and logged off. And when the installer logs off, he can no longer gain access to the network at that location without calling in to a helpdesk.

 

I agree that a hidden SSID and pre-shared key can be crakced, but using both is like locking the door to your home. Sure, people can still break into your home, but you still lock the door. DPI and RFProtect further lock down the network. If SSID and PSK are the lock, then DPI and RFProtect is the alarm system. I have only been involved in open Internet environments, but am aware of some customers that have an interest in wireless enterprise networks. I reviewed the IDS (WIP) functionality in my IAP and realized that I have alot more to learn. Do you have any experience with IAPs? If so, how does  enabling aspects of "Detection" and "Protection" impact the performance the cluster (if at all)?