Sean Convery

Search Security has an interesting article highlighting some of the challenges of rolling out secure wireless within the University of New Hampshire. The article also highlighted an interesting point on the public safety implications:

“We thought about the students instant-messaging back and forth on where to meet and at what time,” said Green, network manager for the UNH telecom department. “You don’t want the bad guys to intercept those IM transmissions and know where those students are.” They realized wireless security is also an extension of public safety — a way to protect students from predators.

My initial reaction was this seemed alarmist but then I thought about the massive concentration of young students, most of whom embrace IM and its variants. They’ll also be congregating in key areas of campus. The benefit to a predator of sniffing this traffic probably exceeds what they’d glean from your average Starbucks hotspot.

Those of you who’ve been in the IT industry for a long enough time have seen a remarkable evolution in connectivity. The evolution occurred so slowly that perhaps you missed it. Let’s back up to the early 1990s before IP really caught on in the enterprise space. Network engineers—myself included—were running around getting our Certified Netware Engineer (CNE) certifications and spending a lot of time building networks that ran IPX. IPX was a remarkably simple protocol that used a variation of the machine MAC address as the L3 IPX address. If this sounds a bit like IPv6, it should. Both derive the L3 address from the L2 address and make connectivity fairly easy, at least on a local level.

Skip forward to the mid 1990s and we were all enamored with the Internet and the possibilities of TCP/IP. Like me, perhaps you took part in the installation of your company’s first Internet firewall / bastion host. One thing you did, firewall or not, was configure static IP addresses. Lots of them…On every host that used TCP/IP. This is because DHCP didn’t materialize first as RFC 1531 until 1993 (It later became RFC 2131) and didn’t get deployed ubiquitously for a while after that. In that time between IPX and DHCP, configuring these static IP addresses was a pain. The chance of misconfiguration was high, and you tracked all your IP networks in an Excel spreadsheet. You knew that Bob’s IP address was 192.0.2.45 because you hard coded it as such just the other day. If you wanted to write a security policy for Bob, for all practical purposes 192.0.2.45 = Bob.

Static configuration was a particular pain for the network admins themselves who were constantly moving machines around the network for testing and troubleshooting. Since the Excel spreadsheet was invariably a bit out of date and your time on any IP network was limited, you tended to guess an address for the last octet of your machine’s IP address. Sometimes you guessed right, sometimes you guessed wrong and the gratuitous ARP caused your stack to shut down. Troubleshooting network connectivity had to do with making sure DNS was set right, the default gateway was set right, and you weren’t conflicting with another’s IP address. Of course the fact that TCP/IP stacks weren’t built into Windows until 1995 presented other problems that I won’t go into here.

The point of this trip down IT memory-lane is that since the deployment of DHCP we’ve been on a wave of more and more ubiquitous connectivity and less and less troubleshooting per connected station. You move your laptop to another segment, plug in, and get an address that works. IPsec VPNs gave us a small taste of problems as the filtering of ICMP Type 3 Code 4 (Fragmentation Needed and DF bit set) messages by overzealous firewall admins led to MTU issues from the IPsec headers. But for the most part, we’ve experienced a decade or so of fairly consistent connectivity. WLANs just extend the reach of the places you can connect and when combined with home broadband, hotel access, etc. we’ve been in IPv4 connectivity nirvana.

Now you may be wondering whom the villain is in this story and there isn’t one, save progress in general. This time it was progress in security. You see, this ubiquitous connectivity combined with nearly all IP connected stations being Internet connected created a breeding ground for network attacks of all sorts. There’s no need to rehash this except to say the last five years haven’t exactly been in the “Win” column for the good guys.

The latest wave of technology to combat the growth of Internet threats of all kinds is a technology type that I’ll call device posture assessment. Posture assessment products exist or are in development everywhere you look (Cisco, Juniper, Microsoft, TCG TNC, Symantec/Sygate, Consentry, etc.). The basic idea of these systems is to query the state of a connecting machine to see if it is an asset of the organization who runs the network, and if it is up to date with its anti-virus, patch levels, firewall policy, etc. These systems often make use of the RADIUS protocol and slightly less commonly the IEEE 802.1X port authentication standard. While these technologies offer great promise as they mature, they also have the unintended consequence of making troubleshooting basic network connectivity harder than I can ever remember it being. Let’s review the list of things that could be wrong in a normal vanilla DHCP enabled IP LAN:

Wired News has a great editorial from Bruce Schneier. He gets into the nasty implications to computer security companies of Sony’s rootkit:

What do you think of your antivirus company, the one that didn’t notice Sony’s rootkit as it infected half a million computers? And this isn’t one of those lightning-fast internet worms; this one has been spreading since mid-2004. Because it spread through infected CDs, not through internet connections, they didn’t notice? This is exactly the kind of thing we’re paying those companies to detect — especially because the rootkit was phoning home.

Juniper buys Funk. Interlink closes down. This is to some extent both validation and refutation of the same market within a couple weeks of each other. Interesting…

Nicholas Carr’s blog alerted me to a fascinating new service from Amazon called Mechanical Turk. It is named after the mechanical chess-playing automaton with a human hid inside from the late 1700s. The basic idea is through a web-services API you can code humans into applications so that when the code gets to a step that a human would be best at performing, a registered and qualified user at Amazon’s site is asked to answer the question.

The implications for security applications are interesting. To date, network security has been very good at identifying packets that match predefined bit patterns but generally quite bad at spotting a false positive (for example within an IDS system). Attempts at anomaly detection and event correlation have existed in the market for a while now but none have yet delivered on the promise of an intelligent system. The basic idea of such systems is that a low priority event seen at a firewall, combined with a low priority event seen at a WLAN AP, could be correlated into a high priority event if the system decided to do so.

So could the mechanical turk perform such a service? Integration via an API seems much more tight than popping up a dialogue box on a management console or firing off an email alert. Taking into account the base-rate fallacy in IDS combined with a human’s tolerance for boys crying wolf, this has been a tough problem to crack so far. Of course the mechanical turk just foists the problem back to the humans but in a seemingly scalable way. This could be an interesting model for managed security providers to take in the future.

Identity Engines launched today! Things have been busy around the office getting everything ready in all departments. Discussions with press and analysts have so far been quite positive. There’s much to do going forward but we’ve got a very interesting product that solves a real problem enterprises have today.

In a somewhat surprising article at ZDNet Asia, Steve Hurst, product director for managed security services at AT&T, has lots of juicy quotes proclaiming that Wi-Fi security is still not up to snuff. My favorite gem: “Wi-Fi devices are stupid devices that only pass data and do not authenticate users.” This would all make sense to me if he differentiated between open networks and more secure deployments within enterprises. Perhaps the author of the article tried to sensationalize things a bit, but the FUD quotient on this piece is off the chart.

For fun, contrast the ZDNet article with another recent article from SearchNetworking.com saying essentially the exact opposite. “Your wireless network, in many cases, is more secure than your wired network,” says Bill Terrill, senior analyst with Burton Group.

I think in order to be accurate in any assessment of the two technologies you need to consider the various vectors of threats. Confidentiality and authentication are subsets of overall security. So WLAN certainly has a better cryptographic profile than wired–at least until we see 802.1AE standardized and deployed. However, WLANs are certainly more vulnerable to interference attacks and other DoS based purely on the medium itself. Modern wired networks have the ability to ensure that one rogue actor can not easily render the entire network unusable. This is a much harder statement to make about WLAN.

Wi-Fi Networking news is reporting that Earthlink is mandating 802.1x with EAP-TTLS for its municipal wireless networks. This is somewhat unexpected given the current state of supplicant technology. It will be interesting to see how Earthlink fares compared with Google for the San Francisco wireless project. According to the article, Google is proposing a VPN overlay. It would also be interesting to know why EAP-TTLS was chosen. Regardless of my concerns, it is impossible to interpret this as anything other than clear evidence of the maturation of 802.1x. While most of the 802.1x issues are wired focused, this is still quite a step forward.