Archive

Posts Tagged ‘Meraki’

Blackhat 13 Wi-Fi Security Reports and Nuances of Detection Methods

September 12th, 2013

|

blackhat USA 13Shortly following the conclusion of Blackhat’13, a few articles came out reporting wireless scanning data from the venue.

  Inside the Black Hat 2013 Wi-Fi Network

  Karma is a …Errr, What We Learned at BlackHat 2013 

 

Both reports state that many security relevant events were detected in the Wi-Fi traffic during the conference. Given that Blackhat is attended by security experts, ethical hackers and just plain security geeks, finding security signatures in the traffic is not uncommon. Nonetheless, I think a few things still need to be matched up in these stats before arriving at sound conclusions.

|

1190 rogue devices detected compared to 1300 legitimate devices in 24 hours:

|

One of the articles states that: “It’s rather interesting to see an almost equal amount of rogue devices to real ones, and that is very unique”. What would be good to know is how they define ”rogue”. Depending on how you define rogue, you can call anything from a normal friendly device to a real threat posing device as a rogue.

I suspect that the definition for rogue used in the context of this report is so broad that it is classifying just about every wireless device unknown to the scanning system and seen in the airspace as rogue. But then, it is not clear why such an observation is considered “unique”. This is because, almost everyone attending Blackhat carries multiple Wi-Fi enabled devices and we cannot expect them to register each of their devices with the scanning system.

From the security perspective however, it is important not to get lost in definition of rogues, but be able to detect straight up genuine rogues (aka security threats) and not raise false alarms on normal wireless activity.

 

Fast WEP Crack (ARP Replay) Detected

|

The report also cites “most likely a security vendor demonstrating a tool”. What is perplexing is why Blackhat attendees still have interest in WEP crack tools or their antidotes, especially given that WEP has been beaten to nail and is now mostly irrelevant.

Or, it could point in the direction that the Wi-Fi community has done such solid job with security and WPA2 that hackers still think that they have to make hay out of WEP.

There is also a third possibility; that these ARPs are just part of normal Wi-Fi traffic that correlates with the signature of WEP cracking detection.

|

Spoofed MAC Address

|

Both reports state several occurrences of MAC spoofing. I suspect that these inferences are based on sequence number anomalies that were detected in the traffic. In fact, the video in one of the reports explicitly calls out sequence number anomalies. However, it’s important to note that sequence number anomaly also routinely happens due to normal traffic patterns.

Common reasons include :

  • sequence numbers fall in range 0-4096, so they wrap around very quickly making the wrap around appear like sequence number anomaly,
  • radios routinely skip sequence numbers due to implementation nuances,
  • intermediate frames may be missed because of device coming and going out of coverage making it look like a sequence number anomaly.

MAC spoofing should only be concluded after all these possibilities are eliminated.

|

Signatures and Anomaly Detection

|

Similar analysis can be performed for other anomalies detected in Blackhat traffic. In fact, this kind of analysis can be performed for several security alerts in many scanning tools and wireless security systems (may be another blog some day, I have many amusing stories to tell about these alerts :-)). The key take-away is that many times there is a leap from signatures and anomalies detected to inferring the presence of a genuine security relevant event.

Bubbleman path optionsWhose job is it to make this leap: system or admin? The need to make the leap gives rise to false alarm problem. Imagine how difficult the job of the security admins becomes when this happens in the enterprise setting! All of a sudden, the alerts also need to be chased and mitigated, not just documented in reports! These admins are also presented with the challenge of defining and tuning thresholds that are right for their environments. If admins are unable to filter false alarms and/or not get to the root causes of steady stream of alerts, it eventually leads to frustration and turning off the security system.

|

Policy Enforcing WIPS

 |

An alternative to signature and anomaly based system is policy enforcing WIPS. By de-emphasizing signature and threshold anomalies, and instead focusing on auto-classification and intrusion prevention, the policy enforcing WIPS offers strong security without overheads of threshold configuration, signature maintenance, false alarms and manual intervention.

So, to reiterate the meta level point about Wi-Fi security: “Intelligent security algorithms tall pole for effective WIPS. Dedicated scan radios otherwise only overwhelm admins with data”.

|

Hemant tall poll tweet

Wireless security , , , , , , ,

Cisco’s recent acquisition shows exciting times ahead for the lead players in the cloud Wi-Fi space

November 28th, 2012

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.

Cloud computing, PCI, WiFi Access, Wireless security , , , ,