With the recent release of the research paper outlining the key reinstallation attack (KRACK) vulnerability found within the implementation of the WPA2 protocol, you might be wondering “How can I help limit my network from exposure?” I wanted to talk not about how the attack works or what patches are available, (far too many sources on that already such as a great post here by Andrew von Nagy) but rather how good network design practices can help limit your exposure to such an attack.

Let’s go ahead and get some things out of the way:

Yes this vulnerability is possible.

Yes it could be very bad in the hands of an attacker.

The SKY IS NOT FALLING.

The WPA2 protocol is still considered secure.

It is my belief that this vulnerability is not a flaw in the WPA2 protocol, as some talking media heads out there have suggested, but rather a flaw in the way supplicant developers wrote the software based on their interpretation of the standard. They simply never thought people would try replaying that piece of the handshake in those circumstances.

While this post is about helping mitigate the risks of this, and any, vulnerability, it won’t make your network impenetrable to this attack. The fact of the matter is that the KRACK vulnerability outlines 10 critical CVE’s, of which some affect the infrastructure (AP/controller side) and some affect the client device. While most major manufacturers and vendors have already released patches, or are in the process of, there will be many client devices that will go unpatched. The simple truth is that there are devices like old Android devices and healthcare devices that, while they have not outlived their useful lives, the products have long been mothballed and updates simply won’t ever become available.

How can you help secure your network?

One proposal is network segmentation. Yes, it’s something that we’ve all heard multiple times. Yet, many wireless production networks are moving more towards large flat VLANs. Flat & fast as I like to call them. While these definitely have their place in areas such as LPV (large public venue) stadiums, they aren’t necessarily the best when it comes to corporations or healthcare organizations where things like Sarbanes-Oxley, HIPPA, PCI etc exist. Network segmentation is the practice of utilizing additional VLANs to provide tighter security measures around the data carried by these segments. This is critical when you have data such as patient health information (PHI) and credit card/SSN information traversing your network.

What does network segmentation do?

Network segmentation helps provide additional areas within the network where traffic can be secured and isolated. The number of devices that actually need to touch that credit card data or PHI, are typically much lower than the total number of devices on your network. By placing devices such as this into their own VLAN, we have additional points where we can place tighter security measures around that data. Within their own VLAN, we could limit access by routing through a firewall, and even send them out their own dedicated internet link to help keep those pesky attackers as far away as possible from that data. After all, do you really think the bear is just going to leave his honeypot out in the open for all that pass by? There’s a reason even in nature why the best things are always protected by an outer layer of tougher material, or poisonous coatings. Your data should be protected by layers of security as well.

What products can help me in my efforts to segment traffic?

Solution One: NAC

While there are many ways and products out there to do this, my suggestion would be to recommend a NAC product such as Aruba ClearPass or Cisco ISE. Both of these products have the ability to utilize information provided by the devices connecting to your network, and identify the device type/category to be used in security policies. These security policies can be written in such a way that while James Smith uses the same credentials for all of his devices, we allow the MacBook access to the corporate VLAN, yet his shiny new iPhone X is placed onto a restricted, internet only VLAN. Why would you do this, you ask? We do it because in most cases the iPhone (or most cellular mobile devices) simply don’t need access to the secured VLAN, or the data within that network.

Solution Two: MDM

A second solution would be to utilize MDM software (mobile device management) such as MobileIron or VMWare’s Airwatch that can help provide security policies to those mobile devices, if they are found to be business critical. MDM software can help ensure that the latest patches are applied to the device, as well as controlling the ability for users to save corporate data to the device. Some even employ a secure area of device memory that is encrypted to allow certain corporate data to be stored safely.

Solution Three: BOTH

While every layer of device/network security always adds the dreaded level of management and administrative overhead, you simply have to look no farther than the daily news to see examples where a simple lack of security or misapplication allowed a huge data breach. While I hope that none of you reading this post have been at the helm of an organization experiencing this, you can be assured if you are/were this will be/has been a “résumé updating opportunity”. By utilizing both NAC & MDM, you are not only able to control what data the device has access to via network segment selection, but what the device can do with that data.

I realize that this article seemed to focus on mobile devices, and if you are wondering why I wanted to focus there take a look at this report. Over 8 billion mobile devices connected to the internet in 2016. In North America alone 81% of connections to cellular and wireless networks were from mobile devices. I don’t know about you, but that’s an awful lot of potential attacking devices if in the wrong hands.

UPDATE: If you are looking for another method to help mitigate the Krack vulnerability check out this blog post here by Jim Vajda that utilizes WIPS.

As always appreciate any comments.

-Scott