Wireless security is more important than ever as the traditional perimeter dissolves and remote working via Wi-Fi connected devices increases. Wireless security must be constantly re-evaluated as the wireless architecture changes and new terminals, such as IoT devicesconnect to the network.
With Wireless Security Architecture: Designing and Maintaining a Secure Wireless Network for the Enterprise, author and founder of Viszen Security Jennifer Minella wanted to educate a wide audience about the security and architecture of wireless networks. “Wireless has its own language that isn’t necessarily accessible to other IT professionals,” Minella said. “I wrote this book to target any IT professional who has basic networking knowledge.”
Here, Minella explains why the book was needed, which companies will find it useful, how to manage security alongside UX, how zero trust has affected wireless security, and more.
Read an excerpt from Chapter 5 of Wireless Security Architecturewhich covers Minella’s five-phase methodology for wireless network security.
Editor’s note: The following interview is edited for brevity and clarity.
why did you write Wireless Security Architecture?
Jennifer Minella: My book covers more than wireless security; it’s more like a network security architecture book. I’ve been in the role for almost 20 years, doing a lot of implementation and consulting for different companies in all industry segments. During network architecture and security projects, the same questions come up again and again. I wanted people to have a source to turn to.
One of my big drivers has been aligning the SOC [security operations center] and NOCs [network operations center]. This is my cute way of saying that we need to align networking with security operationally and strategically. Many technologists focus on the products and their configuration. I would consult them throughout the security decision-making process. What is the risk appetite and compliance requirements of the CISO office or risk management office? This isn’t always communicated well, especially if a company doesn’t have both positions in the first place.
Many recent updates have also been made to wireless security. Current best practices often run counter to what we have followed before. I wanted to give this information to people. This happens in two ways in the book: there are short little cheat sheets for small teams that just need to know best practices. Architects and professionals more interested in making their own informed decisions can read the rest of the book and learn more about the thought process, standards, insights, and data that went into those cheating decisions. I wanted to give people something actionable to use that really doesn’t exist in any other resource.
If someone just wanted to read one chapter of the book, I would recommend that it be Appendix C. It contains example architectures, which are the culmination of the book’s content in a series of easy-to-use tables.
Can businesses of any size use the advice provided in the book?
Minella: Yeah, and that’s why the book has to be so big. My experience spans everything from federal agencies and private corporations to state municipalities and individual schools. If you are an organization with managed switches and your switches have IP addresses and an interface that you can configure, the book is for you.
Although I don’t work much in small businesses, they could benefit from Wi-Fi. The book explains the relationship between security on the wired side as it relates to Wi-Fi.
A constant struggle is maintain security without ruining the UX. Do you have any tips on how to handle it?
Minella: When it comes to wireless, you can follow several different UX patterns:
- You log in, and you are open.
- You log in and you get a portal.
- You enter a passphrase to log in.
- You are performing full 802.1x authentication with credentials/certificate.
That said, there are new mechanisms designed to simplify and strengthen security without further affecting the user. An example is Wi-Fi Enhanced Open, which adds encryption to an open network, such as a guest network at Starbucks or a hotel. Usually these networks are not encrypted because there must be a key exchange to have encryption. Currently this does not support all endpoints. The configuration needed is messy and inconsistent. While it’s not perfect, we’re moving towards adding security without impacting users.
Another option is to consider what we see from private cellular space. It’s interesting because we get the same level of security, or an equivalent level, as with a fully secure 802.1x network, but the user really doesn’t have to do anything. Identities are tied to a hard-coded serial number on a phone or a subscriber ID on the SIM card, and then security is layered on top of that. Out of the box, the UX resembles using a cell phone on a public carrier network.
What security issues do you frequently see occurring when a team is setting up a wireless network?
Minella: I see several things that people commonly do. The big problem is that they don’t really dig into how they undermine their own security mechanisms.
An example concerns SSIDs [service set identifiers]. For years we have been told to reduce SSIDs. It had to do with the overhead of an RF [radio frequency] airspace perspective – there is only limited time in the air, and anything that talks and beacons takes up some of that airtime. So if you have a lot of SSIDs – even if there’s nothing on them – those take up some airtime. Once you hit three, four or five SSIDs it was like “OK, now you need to start grouping them into common security domains”. But, with newer technology, this is less of an issue. It’s one of those contradictory things where the advice now is that we need to do a better job of cracking SSIDs based on the security profile of the endpoints connecting or the resources or data available on those networks.
It’s no longer appropriate for us to try to put every passphrase-based IoT device on a single network or put anything that can do 802.1x on one SSID. Even though they have separate VLANs [virtual LANs], once they’re on the network, the reality is that the default mode of operation – and the only mode of operation for some products – is for the entire SSID to be on a broadcast domain. There are vulnerabilities that can be avoided between these endpoints, even if static or dynamic VLAN assignments occur anywhere the vulnerability exists live. So don’t reduce the SSIDs. Instead, increase the number of SSIDs based on security requirements.
The next security concern is that not all devices can use 802.1x, which is the gold standard for security and a standard Wi-Fi access scenario. For devices that can’t do 802.1x, vendors take it easy and do MAC [media access control] authentication bypass or MAB. This effectively undermines all security on the 802.1x network as they allow devices that do not participate in authentication. MAC addresses are identification, not authentication. The security around this endpoint is not up to par with other devices on the network. It feels like it’s safe, but it’s exceptionally insecure. Many penetration testers use it to enter a network.
The final issue concerns protocols intended for use on home networks where there is no infrastructure like in the enterprise – things like DNS servers and the Dynamic Host Configuration Protocol [DHCP]. Instead, a suite of protocols, like Apple’s Bonjour and multicast DNS, allow things to talk to each other. It’s not ad hoc from a strict Wi-Fi definition, but effectively they use the network infrastructure. But that’s just connectivity and no other network services like DNS and DHCP.
Basically, we received calls to activate interstation communication. Maybe eight or ten years ago, this option was off by default. If I joined an SSID with my laptop and then with my phone, these two devices would not be able to talk to each other. Then consumerization became popular and manufacturers got support calls for it. The default behavior changed to being open and allowing this communication.
Unhindered communication over SSIDs exposes businesses to problems such as the spread of malware, because nothing stops anything from talking. Different devices may have different protections from others.
Consumer protocols on enterprise networks are a big deal. You can’t walk into an organization and say to a leader, “I’m sorry your AirPlay has stopped working.” They will just tell you to re-enable the feature.
How Has Zero Trust Affected Wireless Security?
Minella: So far it has had minimal direct impact. That will eventually change.
Zero-Trust solutions can be placed into three use case models:
- user-to-resource, whether on-premises or in the cloud;
- device to device, no user is necessarily attached; and
- service to service or server to server.
The user to the resource, whether they are together on campus or both are remote, is appropriate for zero trust. For the second, we enter network-based microsegmentation products. The last involves workload microsegmentation, which is a completely different set of products.
What’s odd is that many zero-trust solutions are designed to be native or cloud-routed, and they really fit that model where the user is in one place and the resource is somewhere else. When the user is co-located with the resource, such as over Wi-Fi, we are often physically close to the access point and must connect to Wi-Fi to be remote. We embarked on this model where we rely on either agent-based technology or device-to-device microsegmentation type technology.
Since many zero-trust products are a cloud-based remote model scenario, they have failed to make their way into the traditional LAN and Wi-Fi world. It’s happening, but slowly. Eventually, our endpoints that are under company management will have some type of agent. Instead of something that connects to Wi-Fi and then to a VPN, this is where the agent makes the decisions and helps enforce resource access. This same managed endpoint can participate in Wi-Fi connectivity, as if we were doing 802.1x over a wired network or connecting through a VPN.