Implementing wireless security in the enterprise

Wireless security is more important than ever as the traditional perimeter dissolves and remote work via Wi-Fi-connected devices increases. Wireless security needs to be constantly reevaluated as wireless architecture changes and new endpoints, such as IoT devices, connect to the network.

With Wireless Security Architecture: Designing and Maintaining Secure Wireless for Enterprise, author and founder of Viszen Security Jennifer Minella wanted to educate a broad audience on wireless network security and architecture. "Wireless has its own language that's not necessarily accessible to other IT pros," Minella said. "I wrote the book to target any IT pro who has foundational networking knowledge."

Here, Minella discusses 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 of Chapter 5 of Wireless Security Architecture, which covers Minella's five-phase methodology for wireless network security.

Editor's note: The following interview is edited for conciseness and clarity.

Why did you write Wireless Security Architecture?

Jennifer Minella

Jennifer Minella: My book covers more than wireless security; it's more like a network security architecture book. I've been in a role for almost 20 years featuring a lot of implementation and consulting for different companies across all industry segments. While doing network architecture and security projects, the same questions come up again and again. I wanted people to have a source they could turn to.

One of my big drivers has been to align SOC [security operations center] and NOC [network operations center]. It's my cute way of saying that we need to align networking with security operationally and strategically. Many technologists focus on products and configuring them. I'd be brought in to consult them through the security decision-making process. What is the risk appetite and compliance requirements of the CISO's office or risk management office? It's not always communicated well, especially if a company doesn't have the two positions in the first place.

There have also been a lot of recent updates to wireless security. Current best practices often go in direct opposition to what we followed before. I wanted to give people that information. That happens two ways in the book: There are short little cheat sheets for small teams that just need to know the best practice. Architects and professionals more interested in making their own informed decisions can read the rest of the book and learn about the thought process, standards, information and data that went into these cheat-sheet decisions. I wanted to give people something actionable to use, which does not exist really in any other resource.

If somebody were just going to read one chapter from the book, I'd recommend it be Appendix C. It has sample architectures in it, which is the culmination of the contents of the book in an easy-to-consume series of tables.

Can companies of any size use the advice provided in the book?

To learn more about Wireless
Security Architecture, click here.

Minella: Yeah, and that's why the book got to be so large. My experience spreads across everything from federal agencies and private corporations on down to state municipalities and individual schools. If you're an organization with managed switches and if your switches have IP addresses and an interface you can configure, the book is for you.

While I don't do a lot of work in small businesses, they could get value from the Wi-Fi side. The book goes into understanding the relationship between security on the wired side as it relates to the Wi-Fi.

One constant struggle is maintaining security without ruining UX. Do you have any advice on how to handle it?

Minella: When it comes to wireless, there are a few different UX models you can follow:

1. You connect, and you're open.
2. You connect, and you get a portal.
3. You enter a passphrase to connect.
4. You do full 802.1x authentication with credentials/certificate.

That said, there are some newer mechanisms designed to address ease and add security without further impacting the user. One example is Wi-Fi Enhanced Open, which adds encryption to an open network, such as a guest network at Starbucks or a hotel. Usually, those networks are not encrypted because there has to be a key exchange in order to have encryption. Right now, this doesn't support all endpoints. The configuration needed is messy and inconsistent. While it's not perfect, we are heading toward adding security without impacting users.

Another option is to consider what we are seeing from the private cellular space. It is interesting because we get the same, or an equivalent level, of security as one would with a full 802.1x secure network, but there's nothing the user really needs to do. Identities are tied to a hardcoded serial number on a phone or a subscriber ID on the SIM, and then security is layered on top of that. Out of the box, the UX looks and feels like using a cellphone on a public carrier network.

What security issues do you commonly see happen when a team sets up a wireless network?

Minella: There are several things I see people commonly do. The big issue is they don't really dig into how they're undermining their own security mechanisms.

One example is around SSIDs [service set identifiers]. For years, we've been told to collapse SSIDs. That had to do with the overhead from an RF [radio frequency] airspace perspective -- there's only so much time in the air, and everything that's talking and beaconing takes up some of that airtime. So, if you have a lot of SSIDs -- even if nothing's on them -- those are taking up a certain amount of airtime. Once you got around to three, four or five SSIDs, it was like, 'OK, now, you need to start collapsing those down into common security domains.' But, with newer technology, that's 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 breaking SSIDs back out based on the security profile of the endpoints connecting or the resources or data that are available on those networks.

It's no longer appropriate for us to try to shove every passphrase-based IoT-type device onto one single network or shove everything that can do 802.1x on one SSID. Even if they have separate VLANs [virtual LANs], once they're out onto the network, the reality is that the default mode of operation -- and the only mode of operation for some products -- is that entire SSID is on a broadcast domain. Vulnerabilities exist that can be avoided between those endpoints, even if static or dynamic VLAN assignments happen somewhere else that vulnerability exists over the air. So, don't collapse SSIDs. Instead, increase the number of SSIDs based on security requirements.

The next security issue involves how not every device can do 802.1x, which is the gold standard for security and a standard access Wi-Fi scenario. For devices that can't do 802.1x, vendors go the easy route and do MAC [media access control] authentication bypass, or MAB. This effectively undermines all security on the 802.1x network because they're allowing devices that aren't participating in authentication. MAC addresses are identification, not authentication. The security around that endpoint isn't on par with the rest of the network's devices. It feels like it's secure, but it's exceptionally insecure. A lot of penetration testers use this to get into a network.

The last issue involves protocols intended for use on home networks where there is no infrastructure like in the enterprise -- things like DNS servers and Dynamic Host Configuration Protocol [DHCP]. Instead, a suite of protocols, like Apple's Bonjour and multicast DNS, allows things to talk to each other. It's not ad hoc from a strict Wi-Fi definition, but effectively, they're using network infrastructure. But it's just the connectivity piece of it and no other network services like DNS and DHCP.

Basically, we got calls to enable interstation communication. Maybe eight or 10 years ago, this was by default disabled. If I joined an SSID with my laptop and then with my phone, these two devices could not talk to each other. Then, consumerization became popular, and manufacturers got support calls for it. The default behavior switched to being open and allowing that communication.

Unfettered communication on SSIDs opens enterprises up to problems such as malware propagation because nothing is blocking anything from talking. Different devices may have different protections than others.

Consumer protocols on enterprise networks are a big problem. You can't go into an organization and tell an executive, 'I'm sorry your AirPlay won't work anymore.' They'll just tell you to turn the capability back on.

How has zero trust affected wireless security?

Minella: At the moment, it's been a minimal direct impact. That will change, eventually.

Zero-trust solutions can be placed into three use-case models:

1. user to resource, whether on prem or cloud;
2. device to device, no user necessarily attached; and
3. service to service or server to server.

User to resource, whether they're together on a campus or if both are remote, is appropriate for zero trust. For the second, we get into network-based microsegmentation products. The last involves workload microsegmentation, which is a completely different set of products.

The weird thing is that a lot of zero-trust solutions are designed to be cloud-native or cloud-routed, and they're really geared for this model of the user being in one place and the resource being elsewhere. When the user is colocated with the resource, such as on Wi-Fi, we are often physically near the access point and have to connect to the Wi-Fi to be remote. We embarked on this model where we're relying on either something agent-based or a device-to-device microsegmentation type of technology.

Because so many zero-trust products are a remote model cloud-based scenario, they haven't worked their way down into the traditional LAN and Wi-Fi world. It's happening but slowly. Eventually, our endpoints that are under corporate management will have some type of agent. Instead of something connecting to Wi-Fi and then a VPN, it becomes where the agent makes the decisions and participates in the enforcement of getting to resources. That same managed endpoint may participate in Wi-Fi connectivity, just like if we were doing 802.1x on a wired network or connecting via a VPN.