This month, AirTight Networks’ flagship product, SpectraGuard® Enterprise, achieved FIPS 140-2 validation from the National Institute of Standards and Technology (NIST) of the United States and the Communications Security Establishment of Canada (CSEC).
These standards and guidelines are issued by NIST as Federal Information Processing Standards (FIPS) for use government-wide. NIST develops FIPS when there are compelling Federal government requirements such as for security and interoperability and there are no acceptable industry standards or solutions. See background information for more details.
Simultaneously, AirTight’s SpectraGuard Server passed TIC tests for inclusion on the DISA UC APL. The DISA UC APL is the single consolidate list of products that have completed interoperability (IO) and information assurance (IA) certification. Use of the DoD UC APL allows DoD Components to purchase and operate UC systems over all DoD network infrastructures.
AirTight’s products are deployed worldwide in many of the most security sensitive United States government and defense organizations to assure security and compliance with requirements such as DoD 8420.01, FISMA and guidelines from the National Institute of Standards and Technology (NIST). Because AirTight products are always kept up-to-date with certifications such as FIPS 140-2, Common Criteria and DISA; government and defense agencies can take advantage of the powerful wireless security technology provided by AirTight.
DISA UC APL, Federal Government, FIPS 140-2
Due to the overwhelming attendance and response we got to the recent WPA2 Hole196 webinar, we did not have time to answer all the questions asked during the webinar. In this post, we are keeping our promise and answering those webinar questions.
By the way, the webinar slides and recording from this webinar as well as answers to the frequently asked questions on Hole196 and a white paper are available here.
So here we go!
The WiFi snooping row Google has gotten itself into seems to be far from over. In April, Google revealed that its Street View cars had been collecting basic data such as the MAC addresses and SSIDs of WiFi networks in the vicinity. But after German authorities asked Google to audit the data, it admitted to have been “mistakenly” snooping payload data from Open WiFi networks. Apparently, a piece of WiFi data analysis code, written by Google engineers back in 2006, was part of the software used by the Street View cars, in turn leading to the WiFi snooping (of about 600 GB of data across 30 countries!). Read more…
The new 802.11 security protocol called 802.11w was recently ratified. Check this 802.11w-Tutorial to know how it works and what it means for your WLAN.
When talking about wired security, enterprise IT administrators talk about multiple layers of defense such as internet firewalls, VPNs, admission control, email filtering, content filtering, web application scanning and many others. It is like a hacker has to peel multiple layers of an onion before getting to the core. Each layer of security is independent and is preferably sourced from different vendors. Each layer compounds the amount of work that a hacker has to perform to get in.
When considering the security of a wireless network, the same enterprise IT administrators are content with the basic security mechanisms integrated into the wireless LAN infrastructure by vendors such as Cisco Systems and Aruba Networks. IT departments have a hard time understanding why an inner layer of defense for wireless network security is needed in the form of an advanced wireless intrusion prevention system (WIPS). The wireless network security posture of an organization is the weakest when the security integrated into wireless LAN infrastructure is the only layer protecting the core network. Without an inner WIPS layer, the core network is open to rogue APs, unauthorized client connections, ad-hoc networks, MAC spoofing and many other attacks that the wireless LAN infrastructure security cannot protect against.
The recently announced improved version of the original Beck-Tews attack on WPA/TKIP appears to have put the wireless security community in a tizzy again. In this post, I argue that the new attack is neither groundbreaking in academic terms, nor is it more worrying in practical terms.
The proposed attack assumes (somewhat unrealistically) that the AP and client cannot hear each other but the attacker can hear both (and can thus act as a man-in-the-middle). In terms of attack speed as well, it is actually slower than the original attack under its stated assumptions.
Security is hard to get right and shortcuts — be it coding shortcuts or design shortcuts – come back and haunt the product designers when the rubber hits the road.
The recently discovered “skyjacking” vulnerability of the Cisco LAPs seems to be a classic example. The “Over The Air Provisioning” (OTAP) feature allows an out-of-the-box Cisco LAP to automatically discover available WLC controllers to connect to by listening to wireless OTAP packets broadcast by neighboring Cisco LAPs. This feature obviously has attractive plug-and-play benefits for the end user but has also resulted in some critical security holes in the Cisco wireless infrastructure as reported recently. Malicious OTAP packets transmitted by an intruder can make a LAP connect to a “rogue” WLC controller on the Internet. This controller can modify the wireless settings of the AP in devious ways resulting in an AP that is in your airspace, connected to your wired network but completely controlled by an attacker.
Many security vulnerabilities are due to coding bugs (for example, inadequate input checking or the infamous buffer overflows). In contrast, the skyjacking vulnerability has its root, in my opinion, in two questionable design decisions that were probably made as early as the requirements definition stage.
Any organization handling payment card data should pay immediate attention to the PCI DSS Wireless Guideline published by the PCI Security Standards Council Wireless Special Interest Group last week.
Wireless Threats That Can Compromise PCI DSS Compliance
The key highlights are:
In my previous blog post (5 Wireless Intrusion Detection Questions You Need to Worry About), I talked about the key questions that are related to the detection of Wireless (WiFi) based intrusions in your enterprise. Today, let’s turn the focus on to the other important aspect of WiFi security – Intrusion Prevention. Here are the 5 questions you should ask on wireless intrusion prevention in your enterprise. Let me know if your answer to all of these questions is in the affirmative.
- Does my wireless security solution provide accurate and automatic prevention? If your solution requires a manual intervention for blocking a detected intrusion, you may be too late. Hence, the key to any intrusion prevention solution is the ability to automatically block the intruder. Although this requirement may seem obvious, it is interesting to note that getting this right is non trivial. For example, a poor implementation can end up blocking your neighbor’s communication - highly undesirable and in certain regions, illegal. Unless your security solution can accurately classify WiFi communication (authorized, unauthorized and don’t care/external), you will not be able to achieve this key functionality. Read more…