Appendix C
Sample Architectures

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:

  • Architectures for Internal Access Networks “Architectures for Internal Access Networks” will address security for all use cases where a user or device has access to any of the organization's protected assets, such as internal networks.
  • Architectures for Guest/Internet-only Networks “Architectures for Guest/Internet-only Networks” will address securing networks for users and devices needing only Internet access. While the backend architecture supporting these guest networks may require access to internal resources (such as DNS or DHCP servers), the model is defined by the end user or endpoint access.

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.

Architectures for Internal Access Networks

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:

  • Managed User and Managed Device
  • Non-User-Based Devices
  • Contractors and Third Parties
  • BYOD/Personal Devices with Internal Access

Managed User with Managed Device

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.

Security Considerations

Considerations for the security architecture of managed users on managed devices include:

  • Classification of Network or Data Sensitivity The overall classification of the network or data is the most influential factor in planning that network's security. Networks that host assets with data labels associated with compliance (including PCI DSS and CMMC as examples) will demand certain levels of authentication, encryption, and segmentation. Beyond the minimum requisite designs, additional controls may be recommended, and different classifications of data (with varying security requirements) should be further segmented.
  • Segmentation Requirements Network and endpoint segmentation can include techniques like over-the-air inter-station blocking (peer-to-peer blocking) as well as L2/L3 controls enabled on the wired and wireless networks.
  • Authentication Requirements The networks defined in these architectures are all based on 802.1X/Enterprise-class networks. As such, all users and/or devices will be authenticated via 802.1X, with expectations that higher security requirements prescribe layering or chaining of both user and device authentication.
  • Group Key Exploits in 802.1X As you've seen, SSIDs are effectively a broadcast domain, by default with shared group keys (even if endpoints are in different VLANs). In 2010, researchers announced the “Hole 196” vulnerability, which specified a suite of possible attacks against Wi-Fi networks, primarily based on exploiting the inherent trust properties of group keys.

    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.

  • Industry-Specific Requirements Specific industries will have additional recommendations and requirements. Please use these sample architectures as a starting point and adjust as appropriate for your use case.

High-Security Architecture

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.

High-Security Architecture Requirements

For highly secured networks being accessed by managed users from managed devices, the architecture will specify:

  • 802.1X-secured SSID.
  • WPA3-Enterprise Only with a minimum of CCMP-128 or use of the 192-bit suite (with 256-bit keys) for the highest-security environments.
  • Authentication of both the endpoint and the user, which can be accomplished with EAP chaining, vendor-specific implementations that add device authentication or directory lookup along with user authentication, or use of a NAC product or advanced authentication server that supports both user and device authentication.
  • Only 802.1X authentications will be allowed, and use of MAB or any MAC-based authentication along with 802.1X is not indicated for high-security networks.
  • 802.1X allowed EAP methods should specify an encrypted outer tunnel and allow only the requisite methods (this may include PEAP, EAP-TTLS, EAP-TEAP, and EAP-FAST); the policy should not allow lower-security protocols such as un-tunneled MSCHAPv2 or deprecated methods of MD5, LEAP, or CHAP. Use the latest version of TLS and specify cipher suites of ECC vs RSA (see https://datatracker.ietf.org/doc/rfc4492/ for more).
  • Interstation blocking (peer blocking) should be enabled.
  • Multicast, mDNS, Bonjour, and any zeroconf networking protocols will be blocked/filtered (allowing for special considerations with IPv6).
Notes on User and Device Authentication in High Security

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:

  • Through EAP chaining
  • With vendor-specific implementations that add device authentication or directory lookup along with user authentication
  • Use of a NAC product or advanced authentication server that supports both user and device authentication (not a feature supported in Microsoft NPS)

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.

Medium-Security Architecture

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.

Medium-Security Architecture Requirements

Internal networks for managed users and devices, based on medium-security architecture should be planned with the following:

  • 802.1X-secured SSID
  • WPA3-Enterprise Only with a minimum of CCMP-128
  • Authentication of the endpoint and/or the user
  • 802.1X-secured SSIDs may support limited MAB endpoints, but only if the MAB endpoints are segmented from full 802.1X-authenticated endpoints
  • 802.1X-allowed EAP methods should specify an encrypted outer tunnel and allow only the requisite methods (this may include PEAP, EAP-TTLS, EAP-TEAP, and EAP-FAST); the policy should not allow lower security protocols such as un-tunneled MSCHAPv2 or deprecated methods of MD5, LEAP, or CHAP
  • Interstation blocking (peer blocking) should be enabled except when allowed by an admin-defined policy
  • Multicast, mDNS, Bonjour, and any zeroconf networking protocols should be blocked/filtered in business environments and used in limited areas to support residential use cases such as university residence halls and long-term care facilities

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.

Supporting MAB with 802.1X in Medium-Security Networks

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:

  • Via static or dynamic VLANs from RADIUS
  • Using downloadable ACLs from RADIUS
  • Other static or dynamic segmentation method such as NFVs
  • With a vendor-specific implementation based on a role or label
  • From a NAC product or advanced authentication server with granular policy support and/or endpoint profiling

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.

Supporting mDNS and Zeroconf in Medium-Security Networks

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:

  • Only allow it if absolutely necessary
  • If enabled, segment the endpoints and networks using zeroconf with separate SSID and VLAN (or NFV)
  • Add mitigating controls and/or additional security monitoring as appropriate, specifically for managed endpoints

Low-Security Architecture

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.

Low-Security Architecture Requirements

Internal networks for managed users and devices, based on a lower security need could be planned with the following:

  • 802.1X-secured SSID
  • WPA3-Enterprise Only with a minimum of CCMP-128
  • Authentication of the endpoint and/or the user
  • 802.1X-secured SSIDs may support limited MAB endpoints
  • 802.1X-allowed EAP methods should specify an encrypted outer tunnel and allow only the requisite methods (this may include PEAP, EAP-TTLS, EAP-TEAP, and EAP-FAST); the policy should not allow lower security protocols such as un-tunneled MSCHAPv2 or deprecated methods of MD5, LEAP, or CHAP
  • Interstation blocking (peer blocking) is optional
  • Multicast, mDNS, Bonjour, and any zeroconf networking protocols may be allowed

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.

Snapshot shows architecture summary for internal access by managed users with managed devices

Figure C.1: Architecture summary for internal access by managed users with managed devices

Headless/Non-User-Based Devices

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.

Security Considerations

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:

  • Classification of network or data sensitivity
  • Segmentation requirements
  • Authentication requirements
  • Group key exploits
  • Industry-specific requirements

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:

  • Roaming requirements and latency tolerance, which may dictate whether 802.1X (with or without MAB) can be used with FT, or if a passphrase-secured connection is required
  • Availability and uptime requirements, which may dictate whether Wi-Fi or another connectivity technology such as private cellular is best suited for availability needs

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.

High-Security Architecture

A high-security architecture for headless devices with internal access may be based on one or more of the following network types:

  • 802.1X-secured SSID
  • MAB on an 802.1X-secured SSID
  • WPA3-Personal Only SSID
  • Cellular LAN
  • Headless Devices on 802.1X-Secured SSID For endpoints such as most network printers and VoIP systems that support 802.1X authentication, device certificates or domain credentials can be configured on the device manually or provisioned through a management platform. As much as possible, the network should be configured similarly to the methods described earlier in “Managed User with Managed Device,” which also use 802.1X-secured networks.

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.

  • Headless Devices with MAB on an 802.1X-Secured SSID MAB may be used to authenticate endpoints with known and fixed MAC addresses. Please review the caveats and design best practices detailed in the section titled “MAC-Based Authentications” in Chapter 3.
  • Headless Devices on WPA3-Personal Only SSID The technical editors and I all agree that any network based on a Personal-class SSID is not considered “highly secure.” However, this is relative scoring, and some environments will demand passphrase-based networks. For endpoints that may not have a fixed MAC address and/or have roaming requirements that can't be met with FT, use of WPA3-Personal Only networks is appropriate.

    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).

  • Headless Devices on Cellular LAN Private cellular (aka cellular LANs) offers a secure alternative to Wi-Fi connected headless devices. Cellular LANs are covered in Chapter 8, “Emergent Trends and Non-Wi-Fi Wireless.”

    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.

Additional Configurations for Headless Devices

In addition to the type of network security profile, the following should be included in the architecture:

  • SSID segmentation of headless devices from fully capable and managed endpoints
  • SSID segmentation of headless devices of varying security classifications; for example, a biomedical device that could cause injury or death if tampered with should be separated from digital signage boards
  • Other segmentation as required; for headless devices of the same security classification, but with different access requirements, use dynamic VLANs (or similar control) to segment endpoints connected to the same SSID
  • Granular policies for authorization; the headless devices should have policies applied in the wireless or wired infrastructure allowing communication to and from only the resources required; some may only require Internet access; others will require access to one or more servers or devices
  • Access based on the degree of confidence of what a device is before allowing it network access; especially in sensitive networks, the admin and system owner should know without a doubt what an endpoint is and have a way to re-validate on connection if using MAC addresses to identify the endpoint
  • In sensitive networks, there should be a mechanism to profile endpoints actively and/or passively and alert when an endpoint profile changes; this is applicable for all Wi-Fi connected headless devices, regardless of how it's connected; this prevents MAC spoofing and endpoints using passphrases without authorization

Medium-Security Architecture

A medium-security architecture for headless devices with internal access may be based on one or more of the following network types:

  • MAB on an 802.1X-secured SSID
  • WPA3-Personal Only SSID
  • WPA3-Personal Only SSID + WPA2-Personal SSID
  • Other MAC-based authentication

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.

  • WPA3-Personal Only SSID + WPA2-Personal SSID For medium-level security networks, WPA2-Personal and WPA3-Personal can be supported in parallel. The configuration should include two SSIDs as follows:
    • SSID for WPA2-Personal
    • SSID for WPA3-Personal Only

    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:

    • Do not re-use any passphrases between WPA2- and WPA3-Personal networks
    • Do not use WPA3-Personal Transition Mode
    • Place WPA2- and WPA3- secured endpoints on different VLANs
    • As with all headless devices, allow only the specific access required for internal resources
  • Headless Devices with Other MAC-based Authentication MAC authentication can be achieved several ways. Aside from MAB, medium-security networks may use a NAC product or a Wi-Fi vendor's profiling and IoT engine to identify and then authorize a headless device based on its MAC address. This method does not rely on 802.1X or MAB.

    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.

Low-Security Architecture

A lower-security network for headless devices with internal access may be based on one or more of the following network types:

  • WPA3-Personal Only SSID
  • WPA3-Personal Only SSID + WPA2-Personal SSID
  • WPA3-Personal Transition Mode SSID

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:

  • Use different passphrases for WPA2 and WPA3 connected devices if possible
  • Segment WPA2 and WPA3 connected endpoints on different VLANs using dynamic VLAN assignment or other method

Figure C.2 provides a summary of all three security architecture levels for headless devices accessing internal network resources.

Snapshot shows architecture summary for internal access by headless devices

Figure C.2: Architecture summary for internal access by headless devices

Contractors and Third Parties

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.

Security Considerations

Securing access for contractors and other third parties should take into account these considerations:

  • Source of access, whether the contractor accessing resources from on-prem or remotely
  • Level of access, describing the assets or resources the contractor requires access to
  • Duration of access, which may be one time, recurring on a cadence, or for a specific length of time
  • Security classification of the resource(s) being accessed; an entity accessing a printer for remote maintenance should be handled differently than a contractor accessing the domain servers or security tools
  • Nature of the relationship, including whether the person is employed by a vendor partner with a formalized contractual relationship versus a freelance consultant, plus the posture or security certification of the vendor partner if applicable

High-Security Architecture

For contractors or third parties accessing sensitive networks or data, one or more of these methods should be considered:

  • Formal Vetting and Onboarding Just as with an Employee This is common and appropriate for long-term contractors effectively working as an employee or extension of the organization; these users are often issued a managed device and are then treated just as those in the “Managed User with Managed Device” architectures covered earlier.
  • Granting Access Through a Privileged Access Management Platform Contractors that are engaged less often or for a shorter time but are accessing highly sensitive data, networks, or are granted privileged access such as admin access to the Wi-Fi infrastructure should be managed through a privileged access management platform.

    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.

Medium-Security Architecture

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.

  • VPN Access for Contractors VPN access can be used to secure and control connections both on-prem and remote but for the purpose of contractors, it's most often for remote access. In wireless architecture, our purview is for contractors, engineers, and TAC that may need management access to the wireless infrastructure for configuration or troubleshooting.

    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.

  • NAC Access for Contractors NAC products can enforce granular authorization policies including for contractors. Policies can be enforced via wired connections, wireless, and/or remote VPN, depending on the deployment.

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.

Low-Security Architecture

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:

  • Granted Full Network Access Without Inspection or NAC Although not ideal, it's not uncommon for risk-tolerant organizations to simply grant access to certain trusted third parties with no formal vetting, privileged access management, or auditing. These users may be given a domain account and allowed to connect with their own device, which is not scanned for security posture. Others may be granted through a passphrase-secured network with access to the production network.
  • Granted Use of a Managed Device with Logged-on User Another access scenario for contractors in lower-security environments is to allow the third party to use a managed endpoint that a user has logged on to. This may be the lesser of two evils but isn't always feasible and offers no auditable attribution to actions taken by the contractor; all events will be documented as the logged-on user.

BYOD/Personal Devices with Internal Access

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.

Security Considerations

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:

  • Management and ownership model (BYOD, COPE, CYOD, etc.)
  • Legal considerations
  • Technical 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 Architecture

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:

  • BYOD, CYOD, COPE, or COBO models, with additional security vetting required for BYOD
  • Access via 802.1X-secured networks only, specifically:
    • WPA3-Enterprise Only SSID
  • Use of BYOD onboarding platform or MDM to manage server and device certificates for 802.1X
  • Use of MDM platform for posture scanning and monitoring of the endpoint
  • Granular access policies allowing only access to and from the resource required by business needs
  • Networks with personally managed smartphones, tablets, and laptops should be segmented from enterprise-managed endpoints with a dedicated SSID

Medium-Security Architecture

Personal devices accessing internal network resources with medium security requirements should plan for:

  • BYOD, CYOD, COPE, or COBO models, with additional security vetting required for BYOD
  • Access via 802.1X- or Personal-secured networks, specifically:
    • WPA3-Enterprise Only SSID, or
    • WPA3-Personal Only SSID
  • Optional use of BYOD onboarding platform or MDM to manage server and device certificates for 802.1X
  • Use of MDM platform for posture scanning and monitoring of the endpoint
  • Access policies allowing only access to and from the resource required by business needs

Low-Security Architecture

Personal devices accessing internal network resources with low security requirements can plan for:

  • BYOD, CYOD, or COPE models, with additional security vetting required for BYOD
  • Personal device self-registration through portal
  • Access via 802.1X- or Personal-secured networks, which may include:
    • WPA2-Enterprise
    • WPA3-Enterprise Only
    • WPA3-Enterprise Transition Mode, or
    • WPA2-Personal
    • WPA3-Personal Only, and
    • WPA3-Personal Transition Mode
  • Optional use of BYOD onboarding platform or MDM to manage server and device certificates for 802.1X

Guidance on WPA2-Enterprise and WPA3-Enterprise

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.

Migrating from WPA2-Enterprise to WPA3-Enterprise

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.

Supporting WPA2-Enterprise with WPA3-Enterprise

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.

Guidance on when to Separate SSIDs

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 Guest/Internet-only Networks

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
  • BYOD/Personal Devices with Internet-only Access

Guest Networks

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.

Security Considerations

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.

  • Guest self-registration without verification
  • Guest self-registration with verification
  • Guest sponsored registration
  • Guest pre-approved registration
  • Guest bulk registration
  • Captive portals for acceptable use policies
  • Open network with no portal

Revisit the “Captive Portal Security” area of Chapter 3 for details of these models and for more on planning captive portals for guest access.

High-Security Architecture

Organizations that allow guests but wish to have full visibility and auditing of guest access will use one of these methods:

  • Guest self-registration with verification
  • Guest sponsored registration

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).

Medium-Security Architecture

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:

  • Guest pre-approved registration
  • Guest self-registration without verification
  • Guest bulk registration

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.

Low-Security Architecture

Organizations that are not concerned with knowing who the guest users are may opt for these methods:

  • Captive portals for acceptable use policies
  • Open network with no portal

Even if an organization isn't concerned with security for guest networks, it makes sense to enable Enhanced Open, which is encrypted.

BYOD/Personal Devices with Internet-Only Access

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.

Security Considerations

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:

  • Protecting domain credentials
  • Keeping personal devices off production networks
  • Keeping managed endpoints off guest networks

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.

High-Security Architecture

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:

  1. Employee/user connects to the BYOD portal from their personal device.
  2. Employee/user enters their domain credentials into the secure BYOD portal and registers the personal device (by MAC address).
  3. Wi-Fi and/or BYOD registration system registers the device's MAC address as a known (but unmanaged) device.
  4. The personal device is granted access for the specified time without revisiting the portal (durations vary but are frequently 90 days to 1 year).
  5. Optionally, some portals allow the organization to specify a maximum number of devices per-user.
  6. Optionally, some portals offer the option for users to self-manage their devices (this is especially common in higher-education deployments with NAC products).

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:

  • WPA3-Personal Only (do not allow Transition Mode)
  • The SSID should have Internet-only access
  • The SSID should not be shared with any enterprise managed endpoints including IoT

Medium-Security Architecture

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:

  • WPA3-Personal Only or WPA3-Personal Transition Mode
  • The SSID should have Internet-only access
  • The SSID should not be shared with any enterprise managed endpoints including IoT

Low-Security Architecture

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.

Determining Length of a WPA3-Personal Passphrase

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.)

Why Passphrase Length Matters

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.

Considerations for 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:

  • Capabilities of the AP (a beefier AP can handle more connections per second and therefore more attempts)
  • Quantity of APs in the environment (each AP could be targeted for attempts, multiplying the effort)
  • Capabilities of the attacker (number of attack devices)

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:

  • Adding Encryption to What Would Otherwise Be an Open or Guest Network If this is the use case, consider switching to Enhanced Open, and otherwise the passphrase length is not significant as long as the network is Internet-only.
  • Creating a Barrier to Entry to Avoid Public Use of a Network If the goal is simply to keep passersby off a network, recommendations depend on the nature of that network. For internal access, it should be 802.1X-secured. For guest or Internet-only, passphrase is acceptable and shorter passphrases are sufficient.
  • Connecting IoT and Headless Devices In this use case, the most secure option is to move to 802.1X if possible. If not, the passphrase length recommendations vary depending on the nature of the IoT device, other endpoints on the same SSID, and the resources they have access to.
  • Connecting Non-Domain Endpoints with Internal Access This use case may be for contractors or a subset of BYOD models. If the user has internal access, it is recommended to move to an 802.1X-secured network for managed endpoints or use privileged access management (PAM) solutions for third-party access. If there's an unavoidable situation where a user must access an internal network with a passphrase, then the passphrase should be long.

Recommendations for Passphrase Lengths

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 CASERESOURCE ACCESSPASSPHRASE LENGTHRESILIENCE TO BRUTE FORCE
Adding encryption to what would otherwise be an open or guest networkInternet-only, no critical or secured systems on the same SSID8–12Low
Creating a barrier to entry to avoid public use of a networkInternet-only, no critical or secured systems on the same SSID8–12Low
Connecting IoT and headless devicesInternet-only, no critical or secured systems on the same SSID14–20Medium
Connecting IoT and headless devicesInternal or Internet-only but other critical systems on the same SSID18–22High
Connecting non-domain endpointsInternal18–22High
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.134.88.228