The following sample architectures are organized by network use case type (employee, guest, etc.) with each use case then covering the range of security architecture from most to least secure. The content is arranged this way with the understanding that some organizations have higher security requirements for some networks than others. Healthcare is again a great example; it's common to have varying degrees of secure internal networks for staff and biomedical devices, but a completely open guest network to meet business objectives for patient needs.
A few use cases may span both internal and guest network models. For example, BYOD with access to internal resources is covered in the first group, and BYOD with only Internet access is covered under guest networks. The same will be true for certain uses cases of third parties and contractors as well as students. In K-12/primary education students are most often accessing the network with school-managed devices, whereas in higher education and university systems, the students are using personal devices. For that reason, primary education scenarios are covered under the category of “Managed User and Managed Device,” and university scenarios are included under the “BYOD/Personal Device” headings.
The two main areas of architecture are:
The architectures are described as relative: high, medium, and low. Where appropriate, additional notes for more security are included along with elements to avoid. As you'll see in the coming content, it's appropriate to mix-and-match based on the network in scope—meaning an organization may have a self-described high-security implementation for two internal SSIDs, and a lower security architecture for a guest/Internet-only network.
With security architecture, decisions are complex, non-linear, and interdependent. The beauty of a well-orchestrated security architecture is that there are layers of complementary and compensating controls.
With all of that said, it's simply not possible to outline recommendations for every possible scenario. High, medium, and low are generalizations used to describe the combination of needs as defined in risk and compliance (Chapter 1, “Introduction to Concepts and Relationships”), with available authentication and authorization mechanisms (Chapter 3, “Understanding Authentication and Authorization”), and scoping (Chapter 5, “Planning and Design for Secure Wireless”).
The safe bit of guidance I can offer is, based on common practices (not necessarily best practices), many educational institutions opt for low-medium relative security, whereas government and regulated industries will tend toward higher security. That statement is still an incomplete and inaccurate generalization.
Internal access networks offer some level of access to an organization's resources other than just Internet. The access could be a connection to an internal network, or some level of privileged access to one or more assets.
What's excluded from this section are use cases to allow guest users access to one or more specific resources, such as allowing access to a single printer or screen casting device; those scenarios are covered in the “Architectures for Guest/Internet-only Networks.”
In this section, secure architectures are described for the following access scenarios:
Access scenarios based on a managed user on a managed device is the most common scenario for traditional enterprise models for access by employees and staff. This model also applies to students accessing resources from a school-managed device.
In these use cases, the user is known and managed in a directory such as Active Directory. The device is also known and managed and may be part of the domain infrastructure (also in AD) or managed by an MDM tool or NAC product. Although I'm using Microsoft as an example for domain management, the same thought process follows with any platform including G-Suite and Google Workspace, Google's Managed Microsoft AD, Microsoft Azure AD, or any other directory. Similarly, MDM products range from Microsoft Intune to Google Endpoint Management, Citrix, SOTI, AirWatch, ManageEngine, and others.
In all cases, the managed devices covered here will have the capability to connect to an 802.1X-secured network and the architectures here are based on Enterprise class networks of WPA2-Enterprise or WPA3-Enterprise.
Organizations are encouraged to separate SSIDs, and that may include more than one 802.1X-secured network. In fact, for many environments, that's exactly what the following recommendations prescribe. This means there may be multiple 802.1X-secured networks, each mapped to a different security level of high, medium, or low, and each with a different use case and security domain. See the upcoming topic of “Guidance on When to Separate SSIDs” for more.
Considerations for the security architecture of managed users on managed devices include:
This is an insider attack, and a rare one at this point in time. It can only be executed against endpoints connected to the same SSID, on the same AP, but should remain a consideration for highly sensitive environments. In these instances, recommendation for further separating SSIDs or using per-endpoint group keys is advised. Most organizations need not worry about this since an attacker will have several other easier paths into to the network.
High security is the relative descriptor for networks and environments that require the most protection from attacks, both malicious and unintended insider attacks.
Organizations in industries of financial, healthcare, federal governments, and those with high-value intellectual property should consider high-security networks for any access to internal resources. Highly secured networks can be supplemented with less secure architectures described later, with the proviso that the less secured networks will not afford the same level of access as the highly secured network.
For highly secured networks being accessed by managed users from managed devices, the architecture will specify:
Although certificates are the most cryptographically secure authentication mechanism, both user and device authentication should be enforced on highly secured networks.
Additional controls for exceptionally sensitive environments may use multi-factor authentication and/or a VPN for Wi-Fi connections.
As summarized the preceding bullets, authenticating both the user and device can be accomplished in many ways, including:
Further, since MAC addresses are an assertion of identity and not authentication, any authentication based on MAC addresses should not be mixed with fully secured 802.1X authentication. This includes MAC Authentication Bypass (MAB) among others. Endpoints that can't participate in 802.1X are addressed later and will use a different SSID, not a shared 802.1X network.
MAC randomization will also impact the ability to rely on MAC addresses for identity.
Environments in which the organization is prepared to trade off certain security controls in favor of usability and streamlined operations are described with the relative label of “medium security.” Organizations that are security-conscious but not targeted to the degree of highly sensitive environments should consider medium-security architecture.
Internal networks for managed users and devices, based on medium-security architecture should be planned with the following:
Medium-security architecture differs from high security in bullets 2–4, 6, and 7. For medium-security designs, the WPA3-Enterprise SSID need not support 192-bit mode. In these networks it's also appropriate to authenticate the user or the device—although still advisable to authenticate both when possible.
Another significant variation is that in medium-security environments we introduce the flexibility to support MAB on the same SSIDs as 802.1X-authenticated endpoints. The caveat here is that the MAB devices and the 802.1X devices should be in separate networks, which can be accomplished in many ways including:
Remember that even if endpoints are in different VLANs, if they're on the same SSID, they're in the same wireless broadcast domain, creating opportunity for Hole 196 or other insider attacks.
In Chapter 6, “Hardening the Wireless Infrastructure,” I covered a million and one reasons why zeroconf protocols shouldn't be allowed on secured networks. And I maintain that if a network does allow these protocols, by definition, it's not a secured network.
However, networks aren't valuable unless they support the defined business use cases, and some use cases will demand these protocols.
Where possible, I encourage organizations to fully weigh the pros and cons of allowing these protocols. Without rehashing Chapter 6, I'll just issue the reminder that these protocols were designed for home use, not enterprise networks, and exploiting them is one of the first methods used by attackers and pen testers to breach a network.
If you must support a business case and enable some or all protocols, the recommendation is to separate the networks, create a different SSID and VLAN (or other NFV segmentation) for endpoints and networks using these protocols.
For enterprise use cases such as network printing and screen casting, there are products and configuration options that don't rely on vulnerable zeroconf protocols. It may take a bit of extra effort up front, but your network will be exponentially more secure if you put in that work. As an example, you can configure screen casting (such as an AirTame device) to display an IP address to connect to; configure an allow policy through the Wi-Fi infrastructure, and then allow users to connect to and cast to the device without the use of mDNS.
Supporting mDNS and zeroconf protocols recommendations can be summarized as follows:
Organizations may have use cases for one or more networks that are appropriate for a lower level of security architecture. As hinted earlier, a lower-security network may be used in addition to higher-security architectures to address different risk postures and use cases.
Internal networks for managed users and devices, based on a lower security need could be planned with the following:
Moving from medium- to lower-security requirements impacts the guidance in bullets 4, 6, and 7. With the laxer design, an organization may choose to comingle MAB devices with 802.1X-authenticated endpoints. Interstation-blocking (peer blocking) and the zeroconf protocols may be enabled. Figure C.1 provides a summary of all three security architecture levels.
Non-user-based devices include what are often referred to as “headless” devices such as printers, VoIP phones, and standard network-connected business endpoints. In addition, this category also covers LAN-based IoT devices including Wi-Fi connected facilities management and monitoring such as HVAC controls, temperature sensors, and lighting control systems.
Headless devices are defined by the lack of a human user attached to them. Depending on their capabilities, these devices may connect to the network using full 802.1X, using MAB, or with a passphrase, meaning Enterprise or Personal class networks.
Considerations for the security architecture of enterprise-owned devices that are non-user-based are the same as enterprise-managed devices with managed users described previously, including:
In addition, certain headless and IoT-type devices may also have unique roaming and availability requirements that may impact the security architecture, adding two more considerations:
Here, the authentication requirements will be less stringent. There will be a subset of endpoints that support a full 802.1X authentication using domain credentials or device certificates, but the majority of endpoints in this category will not.
It's worth noting that even if a non-user-based device supports 802.1X authentication, it is not recommended to connect them to the same SSID as traditional OS endpoints covered earlier. See “Guidance on When to Separate SSIDs” later in this section for more.
A high-security architecture for headless devices with internal access may be based on one or more of the following network types:
In higher-security environments, headless devices, even when authenticating with 802.1X should be on a separate dedicated SSID, not on a shared SSID with internal users on managed devices.
Note that higher security requirements should use WPA3-Personal Only and should not use WPA3-Personal Transition Mode for this purpose (which effectively downgrades security to WPA2-Personal levels).
These networks include an intentional and known provisioning process, device identification, and mutual authentication to the network, offering a higher degree of security than the other prior two options for headless devices on Wi-Fi. In addition, cellular LANs operate using transmission scheduling and modified modulation and encoding that make it more suitable for hostile RF noise environments, enable connectivity over longer distances, and offer a higher guaranteed QoS for latency-sensitive applications.
In addition to the type of network security profile, the following should be included in the architecture:
A medium-security architecture for headless devices with internal access may be based on one or more of the following network types:
The first two bullets are described in the preceding section. The third bullet adds the option to support WPA2-Personal and WPA3-Personal SSIDs, and the fourth bullet adds the flexibility for other (non-MAB) MAC-based authentication.
The WPA2- and WPA3- networks should not share the same passphrases nor the same VLANs (or other segments). WPA3-Personal Transition Mode is not appropriate for medium security requirements and should be avoided. To recap the additional security requirements:
As with other aforementioned methods, any authorization that isn't based on strong device identity and authentication should add mitigations such as endpoint profiling to prevent MAC spoofing.
A lower-security network for headless devices with internal access may be based on one or more of the following network types:
For networks and headless devices that don't require medium or high security, an additional option is presented.
The WPA3-Personal Transition Mode SSID supports both WPA2 and WPA3 endpoints on the same SSID. This mode is not recommended since it effectively downgrades the overall security to that of WPA2-Personal including all the vulnerabilities for offline dictionary attacks.
With Transition Mode, there are some mitigations for the WPA3-connected endpoints including forward secrecy and PMF, but continued use and sharing of passphrases between WPA2 and WPA3 networks introduces additional vulnerabilities that impact the entire wireless network.
If WPA3-Personal Transition Mode is used, additional recommendations include:
Figure C.2 provides a summary of all three security architecture levels for headless devices accessing internal network resources.
Contractors and third parties requiring access to a subset of internal resources often fall just between the scenarios of employee access from a managed device, and BYOD access from a personal device. With contractors and third parties granted privileged access, the organization may invoke additional security controls to protect its assets and data.
Scenarios covered here include an unmanaged user on an unmanaged or lightly managed device. It's not only reasonable but it's common for organizations to require contractors to use a NAC agent or privileged access management agent to allow the organization to inspect the endpoint for security posture.
Depending on the contractual relationship and length of engagement, organizations may issue third parties a managed device and treat them just as they would an employee, in which case the security architecture will be in line with the “Managed User with Managed Device” scenario described previously. On the other end of the spectrum, again depending on the relationship and access needs, the organization may treat contractors and third parties similarly to BYOD access scenarios.
For scenarios covered here, it's assumed the third party needs access to internal resources, is onsite or remote, and is accessing the enterprise resources from an unmanaged device. This may include integrators that require management access to some or all of the wireless infrastructure, vendor systems engineers, or external security monitoring services. It also encompasses non-IT users requiring internal access including contractors providing business operations, accounting, and auditing services, among others.
Securing access for contractors and other third parties should take into account these considerations:
For contractors or third parties accessing sensitive networks or data, one or more of these methods should be considered:
These users and their access should be well documented; if appropriate, their endpoints should be scanned for security posture before being allowed access; access should be restricted to only what's required. For users that have access to management of the infrastructure, the connection and every command should be recorded for auditing.
In medium-security architectures supporting contractor access, the organization may opt to loosen security a bit and add the additional option for VPN- or NAC-based access.
Ideally VPN access for contractors will leverage a product that supports a zero trust strategy, and therefore allows very granular access policies. A contractor shouldn't have full access to the entire network environment.
With both scenarios, vendor management processes and privileged access management rules should be followed, if defined by the organization. For third parties accessing key infrastructure devices, they should be vetted and have insurance verified, etc.
It is also perfectly reasonable to require third parties that are accessing internal resources to follow your organization's requirements for security scanning and posturing—meaning whether agent or agentless, it's appropriate and common to require interaction with a NAC or MDM.
In organizations that have less mature processes, lack the resources to implement granular control and auditing, or simply have a higher risk tolerance, contractor and third-party access may be handled in one of the following ways:
As defined throughout the book, BYOD scenarios may include access to internal resources or Internet-only access. This section covers managed users such as employees or students that are accessing internal resources from a personal device.
For a refresher on security considerations related to BYOD with internal access, visit “Bring Your Own Device” in Chapter 8. Here are a few of the highlights from that content on considerations:
As with all content in “Sample Architectures,” the high, medium, and low requirements are defined in part by the organization's risk management and by the sensitivity of the data or resources being accessed. For each use case, it's reasonable to design multiple networks if needed to meet differing privilege use cases.
High security requirements indicate networks with sensitive data or resources that require a high degree of protection. Personal devices accessing assets with high security requirements should plan for:
Personal devices accessing internal network resources with medium security requirements should plan for:
Personal devices accessing internal network resources with low security requirements can plan for:
Even though WPA3 has just recently been added to Wi-Fi products, any modern endpoint with a standard operating system should be WPA3-capable. WPA3 is required for Wi-Fi 6 and newer devices. Most standard endpoints updated capabilities by the end of 2020, and if the option isn't available, endpoints may simply require a firmware upgrade.
Organizations can quickly and easily migrate existing WPA2-Enterprise networks to WPA3-Enterprise and should not require reconfiguration of any endpoints or RADIUS policies, unless upgrading to the 192-bit security mode.
If there are concerns about the endpoint ability, the intermediary step of moving the SSID from WPA2-Enterprise to WPA3-Enterprise Transition Mode will allow the network admins to verify endpoint connectivity; any Wi-Fi product should show whether a client is connected with WPA2 or WPA3 security, and/or reports can be run.
For small organizations, the intermediary configuration can be short—a week or two. For large organizations additional time may be required but as a guideline, should not exceed six weeks unless there are extenuating circumstances. At the end of the transition time when client support has been proven, the SSID should be updated again from WPA3-Enterprise Transition Mode to WPA3-Enterprise Only mode.
If WPA2-Enterprise support is required in a medium- to high-security environment for an extended period of time, the architect should plan for two SSIDs—one being a WPA2-Enterprise secured network, and the other the WPA3-Enterprise Only network. It's left to the organization to determine whether the WPA2 or WPA3 network should be the newly created SSID.
If most endpoints support WPA3, then it will be more efficient to create a new WPA2-Enterprise SSID, and simply modify the existing WPA2-Enterprise SSID and change it to WPA3-Enterprise Only. The endpoints that don't support WPA3 will need to be modified manually or via group policy to connect to the newly created WPA2 network with a different SSID name.
For highly secured networks, Transition Mode should not be used other than for very short-term migration periods as described previously.
The one overarching theme of this appendix, and perhaps this entire book, is that today's security considerations are driving architectures toward separating SSIDs—a direct opposition to the decade-old guidance to collapse them.
Why? SSIDs are just an over-the-air broadcast domain. There are numerous known and well-documented vulnerabilities related to misuse of group keys in Wi-Fi. Hole 196 from 2010 is just one of many and it's still a vulnerability and viable attack today, not only for WPA2-secured networks but also WPA3. These attacks are insider attacks and are simply an abuse of the standard as it’s written. As such, the Wi-Fi industry (thus far) has elected to not address these issues, and therefore the security architect must design mitigations for these known risks. These attacks are so specific that in most environments there are many easier ways for an attacker to gain entry, but it's worth mentioning.
Even if you've created an SSID with dynamic VLANs, all devices on the same SSID are in the same Wi-Fi broadcast domain and using the same group keys. Attacks include everything from denial of service to installation of malware.
The recommendations dating back to 2008 and 2009 to collapse SSIDs was based on the desire to preserve airtime by reducing the overhead of beacons. Fast forward 10 years, and the Wi-Fi technology has evolved considerably, as has the speeds of 802.11 WLANs. The 802.11 of 10 years ago started to introduce airtime issues in the range of 3–6 SSIDs. Today's technologies can support a greater number of SSIDs without negatively impacting user experience. That doesn't mean we have carte blanche for an unlimited number of SSIDs; the design still requires a delicate balance, but we need not (and should not) continue attempting to collapse our wireless to three SSIDs.
Architectures for users and endpoints that only require Internet access differ from internal access requirements described in the prior section. Internet-only connections don't absolve the organization from all liability but offer greater flexibility and relaxed security requirements.
In this section, secure architectures are described for the following access scenarios:
Guest networks as defined here are Internet-only and are designed for transient guest users. Guest use cases for personal devices are covered under the two BYOD headings, and use cases for contractors and third parties requiring internal access were covered earlier.
When it comes to guest Internet-only access, the mandates for certain security controls are lessened. The relative labels of high-, medium-, and low-security architectures described in the coming text really maps to how much visibility and control the organization wants over the guest user.
Some organizations don't allow guest access at all; others do with a formal registration and approval, while some use open networks with no self-registration and not even a captive portal to present acceptable use terms.
As a reminder, the six models for guest access include the following. They're joined by an open network option with no portal at all for a total of seven scenarios.
Revisit the “Captive Portal Security” area of Chapter 3 for details of these models and for more on planning captive portals for guest access.
Organizations that allow guests but wish to have full visibility and auditing of guest access will use one of these methods:
Both methods ensure the guest requesting access is a real person and has not falsified data to gain access, such as used a fake email address during a self-registration process. These two methods also ensure someone within the organization knows and expects the guest user and is authorizing them at the time of access (versus pre-provisioning access).
Organizations that prefer to have some visibility and auditing of guest access but with a less stringent process may select one or more of these methods:
Pre-approved registrations are similar to the approval-based registrations mentioned in high-security methods but is included here under medium security since there is an opportunity to abuse an account that was pre-provisioned.
Organizations that are not concerned with knowing who the guest users are may opt for these methods:
Even if an organization isn't concerned with security for guest networks, it makes sense to enable Enhanced Open, which is encrypted.
As mentioned earlier, BYOD scenarios may include access to internal resources or Internet-only access. This section covers managed users such as employees or students that require only Internet access from a personal device.
As covered in Chapter 8, BYOD users vary from guest users in that most organizations want to remove the friction of forcing employees to repeat a traditional guest captive portal experience daily.
For that reason, additional networks and authentication may be provisioned to allow personal devices on an Internet-only network without enforcing repeating the captive portal.
For BYOD and personal devices that require Internet-only, the security considerations look a bit different than other use cases and include additional goals such as:
If a personal device is accessing internal resources, it should (in any level of security) be required to have an MDM or other enterprise-managed agent. However, if a personal device is being used for Internet-only access, there's really no reason to go through the hassle and ongoing maintenance involved with an MDM. Fundamentally these are two very different access models requiring unique security architecture.
Because BYOD is a personal device in use by someone with domain credentials, one goal in managing BYOD is to protect the user's enterprise credentials by not exposing them in an unmanaged device. This is especially relevant for personal devices without an enterprise MDM such as those with Internet-only access.
Just as with guest registrations, if an organization prefers to know what device belongs to whom, and/or requires some level of attribution, they may choose to implement a device registration portal. These portals are offered natively in some Wi-Fi products and are available in every NAC product, as well as some authentication servers.
To date, registration has always been based on the MAC address. The process can vary but generally follows this flow:
In today's architectures, any open networks will use Enhanced Open to offer encryption over the air.
Use of passphrase-secured networks is also an option for Internet-only BYOD. Note that passphrase-secured networks for high security requirements should meet these criteria:
For organizations that don't need to know the identity of Internet-only BYOD devices, they may simply provision a passphrase-secured network for BYOD. Passphrase-secured networks for medium security requirements should meet these criteria:
For organizations that aren't concerned with user friction and aren't concerned with the security of the personal devices, BYOD devices may connect with open networks with no encryption, including other guest networks.
Ah, we've arrived at the million-dollar question: How long should WPA3-Personal passphrases be?
Getting the answer to this was quite the journey. I asked notable cryptographers. I asked pen testers. I asked friends and family. (All of my friends and family work in tech, so that seems reasonable.)
WPA2-Personal networks have a minimum length of 8 characters. They are susceptible to offline dictionary attacks, and the key was directly derived from the passphrase, hence the term “pre-shared key.”
WPA3-Personal networks use a new algorithm, Simultaneous Authentication of Equals, or SAE. The key isn't directly derived from the passphrase, and so the encryption key length is not dependent on the passphrase length; meaning, if a WPA3-Personal passphrase was only three characters long, the cryptographic key would be the same length as if the passphrase were 20 characters long.
That begged the question: Why then do we care about WPA3-Personal passphrase lengths? If an attacker can brute force the WPA3 passphrase, they can join the network and have access to some set of network resources and have some level of access to other peer endpoints on the same SSID. Remember there are insider attacks and an SSID is a broadcast domain.
That means in order to protect passphrase-secured networks, we need to have an appropriate passphrase length.
In Chapter 7, “Monitoring and Maintenance of Wireless Networks,” I said pen testing offered a relative score of security. How long, with what tools, and how much effort did it take to compromise a target? Security controls don't give us 100 percent protection. They buy us time, and if our architecture is correct, we're alerted before an attack is successful. It's not a matter of “if” it can be breached, but “when” or “how long did it take?”
Cracking passphrases works the same way. The question is: How long does a WPA3-Personal passphrase need to be to offer reasonable resilience against today's attack tools?
The answer? It depends. WPA3 is new in the wild, and there's not a lot of data to analyze and base decisions on. Here's what we do know.
Specifically, the resilience of the passphrase to attacks depends on:
An attacker with a single device, targeting a single AP can operate at speed Y. An attack launched against 100 APs can increase the attack to 100Y and reduce the time to crack to 1/100th the time.
The goal of passphrase security should be considered as well. It's common to use passphrase-secured networks for:
The following guidance is based on certain assumptions of architecture and without the benefit of historical data (since WPA3 is new).
In the preceding lists, I referenced relative short and long passphrase lengths.
The general consensus is: if you want to protect against a brute force attack, a length of 8 characters is entirely too short, and something close to 20 characters is more appropriate.
With all of the caveats, exceptions, and fine print, I offer the lengths in Table C.1 as rough recommendations to consider.
Table C.1: WPA3-Personal passphrase length recommendations
USE CASE | RESOURCE ACCESS | PASSPHRASE LENGTH | RESILIENCE TO BRUTE FORCE |
---|---|---|---|
Adding encryption to what would otherwise be an open or guest network | Internet-only, no critical or secured systems on the same SSID | 8–12 | Low |
Creating a barrier to entry to avoid public use of a network | Internet-only, no critical or secured systems on the same SSID | 8–12 | Low |
Connecting IoT and headless devices | Internet-only, no critical or secured systems on the same SSID | 14–20 | Medium |
Connecting IoT and headless devices | Internal or Internet-only but other critical systems on the same SSID | 18–22 | High |
Connecting non-domain endpoints | Internal | 18–22 | High |
3.134.88.228