Barely two weeks after I posted my last blog discussing benefits of the true cloud Wi-Fi over the controller over WAN architecture using Cisco FlexConnect as example for the latter; news of Cisco acquiring Meraki broke out. I got a kick out of it since it showed that my inferences on Cisco FlexConnect and other controller centric offerings were dead on spot, that they can never become real cloud Wi-Fi by incremental touchups and jargon experimentation. I also got a kick out of its timing — 1.2B acquisition barely 2 weeks after I wrote that post! There are several takeaways for the future of cloud Wi-Fi from this big event. First and most obvious is that the cloud Wi-Fi market is expanding rapidly. Another takeaway is that for the vendors already committed to the controller centric WLAN architecture, migration to cloud architecture is not incremental, but it is disruptive. Cisco could not do the migration in-house even after trying for few years with incremental changes like REAP, H-REAP, ELM, and FlexConnect. As I said in my last blog, cloud Wi-Fi is not about throwing controller over WAN, but is needs to be architected differently from the bottoms up. Finally, it also shows that with the standardization of access point platforms, differentiation in mainstream enterprise Wi-Fi will come from innovations in the application space such as network management, security, and integration with other services.
AirTight envisioned value of the cloud managed Wi-Fi solutions way back in 2008; when it was the first to launch wireless intrusion prevention (WIPS) and wireless PCI compliance solutions from the cloud (cloud used to be called SaaS at that time). It saw wholehearted acceptance from customers for Wi-Fi security and compliance applications. Having seen the benefits of the cloud Wi-Fi security offering, those same customers then wanted Wi-Fi access bundled with security in the AirTight cloud offering and AirTight answered their call in 2010. AirTight’s cloud managed Wi-Fi access with built in PCI compliance, saw tremendous success in the market. Riding on this second wave of success in the cloud strategy, AirTight then launched cloud managed enterprise grade Wi-Fi access with its highly acclaimed, absolute best-in-class WIPS buit into it.
Due to strong security posture, extreme scalability, and unique management capabilities, AirTight Cloud Services™ are not just for the midmarket, but also fit very well into scale many times as big. No wonder, organizations even as large as multiple 10,000’s distributed locations have selected AirTight cloud Wi-Fi over all competing Wi-Fi solutions! I am excited to see the cloud Wi-Fi market ignited by Cisco right at the time when AirTight has reached great level of maturity on its cloud Wi-Fi offerings over all these years.
With rising popularity of the cloud Wi-Fi in the distributed Wi-Fi deployments, there is also an attempt to pass off the legacy controller technology as the cloud Wi-Fi by deploying conventional controllers over the WAN. Realizing that it is infeasible to deploy many smaller controllers in the distributed Wi-Fi deployments such as retail, remote offices, etc., the controller over WAN architecture deploys bigger controllers at the HQ and calls it a cloud Wi-Fi. However, the controller over WAN Wi-Fi does not measure up to the true cloud Wi-Fi for many reasons as outlined below. We will use example of Cisco’s controller over WAN architecture to illustrate these differences. Earlier, Cisco called it H-REAP and ELM, now it calls it FlexConnect, but does changing terminology get controllers to measure up to the true cloud? Let us find out. Read more…
Right when the Wi-Fi access and security management are moving towards the controller-less architecture, another interesting architecture seems to have evolved at the other extreme. This architecture seems to be advocating not one, but two WLAN controllers in tandem – and that too from two different vendors. And, some optional (additional?) security management servers on top of the tandem. You think I am kidding? Then check this announcement from Aruba Networks, which is a leading controller-based WLAN vendor: http://www.arubanetworks.com/solutions/by-application/byod-services-on-your-existing-wi-fi/. The stated business case seems to be to put a band-aid on the Cisco WLAN’s (another leading controller-based WLAN vendor) insufficient security features.
In this case, the tandem is only for BYOD security, but as a matter of fact there are many more security gaps that will still remain to be addressed even after the twin tandem controllers are deployed. Would we need a third WLAN controller in the tandem to fill the remaining security gap, and who might provide that? Or, is it just easier to deploy a controller-less comprehensive WIPS solution (and that too with the onsite or cloud option) and secure the Cisco WLAN once and for all. Just a practical thought.
Recall “Skyjacking” vulnerability discovered with Cisco LAPs couple of years ago? It allowed hacker to transfer control of enterprise Cisco LAPs from enterprise WLC to hacker controlled WLC in the Internet with over-the-air attack. Once control is transferred, the hacker could change configuration on those LAPs in any way by adding, deleting and modifying SSIDs. The hacker could also tamper with Cisco monitor mode APs and take away the security layer. Cisco Skyjacking exploited vulnerability in Cisco’s over-the-air controller discovery protocol. Know more about it here.
Now a similar vulnerability seems to have been discovered in Aruba OS and AirWave console. The advisory states: “[a]n attacker could plant an AP with maliciously crafted SSID in the general vicinity of the wireless LAN and might trigger a XSS vulnerability in reporting section of the ArubaOS and AirWave WebUIs. This vulnerability could potentially be used to execute commands on the controller with admin credentials.” Though modus operandi is different from Cisco, the end result is similar – transferring the control of Wi-Fi controller to hacker by launching over-the-air attack.
No system is free from vulnerabilities and such things will continue to be discovered. But, you don’t have to give away “hack one, get one free”. You don’t have to give hackers control of Wi-Fi coverage and Wi-Fi security in a single shot. This can be achieved by ensuring that the Wi-Fi security layer operates independent of Wi-Fi infrastrucutre. Read more…
This latest vulnerability on Cisco WLAN (AP Skyjacking) points out the importance for customers to deploy overlay WIPS to have a zero day response capabilities in place. Making changes to your WLAN controller, APs, and firewalls takes time and new vulnerabilities like this will continue to surface.
A dangerous exploit that can be carried out using this vulnerability is for a hacker to route an enterprise customer’s Cisco AP to WLC deployed out in the Internet and change the Guest SSID to map to an internal enterprise VLAN (using REAP mode supported on Cisco APs); see below for Pravin’s comments.
AirTight is the only WIPS vendor who can detect this dangerous exploit (i.e. Guest SSID mapped to incorrect VLAN) and prevent this scenario. Using AirTight WIPS, you can map WLAN SSID-to-VLAN security policy (i.e. wireless-to-wired security policy mapping) thus allowing you to detect this misconfiguration and prevent a hacker from exploiting this. Using Cisco WLC+WCS+MSE or other third-party WIDS/WIPS, this scenario will go undetected for sometime thus allowing the hacker access into the customer’s enterprise network.
Customers should pay immediate attention to this vulnerability and change their default settings on their Cisco APs (i.e. out of the box configuration) and put zero day response strategy for vulnerabilities like this in the future.
Skyjacking vulnerability which allows Cisco LAP to be diverted to connect to rogue controller by manipulating OTAP could be more dangerous than what has been clarified by Cisco in its advisory. The advisory says that “An exploit could prevent the device from functioning properly, resulting in a DoS condition. There is no risk of data loss or interception by the rogue access point or Wireless LAN Controller.”
As a matter of fact, it should be possible to convert Authorized Cisco LAP into a wired rogue AP using skyjacking. After Cisco LAP is trapped into skyjacking (for example, made to connect to a controller hosted on the net), it is possible to convert it to Cisco REAP mode and make it bridge traffic locally between Enterprise wired subnet and wireless.
Just a thought – won’t blocking LWAPP discovery port on enterprise firewall protect you from this threat?
Stay tuned for more updates as we dig deeper into this.