Chapter 1, “Introduction to Concepts and Relationships,” offered an introduction to the foundational concepts and relationships of the security and wireless networking realms. Chapters 2 through 4 included deep technical dives in the disciplines of segmentation, wireless security profiles and standards, authentication, authorization, and the domain services impacting wireless security.
This chapter begins our journey into Part II, “Putting It All Together,” in which knowledge from the prior chapters comes together in actionable guidance.
Instead of following a model of traditional design methodology, this chapter walks through my own methodology—including the planning processes, documentation templates, and decision trees I've used to help hundreds of clients architect secure wireless.
What I've noticed over the years is that most networking professionals within an organization tend to wing it when it comes to planning, often bypassing any formal scoping and documentation and skipping to configuring products. However, I think it's fair to say these teams have enjoyed the process and benefited from the more structured planning that accompanies having a third party involved in the design architecture.
It's natural to feel so familiar with an environment that you dismiss any formal planning, but even a slightly structured model with some basic documentation is extremely helpful in tasks of planning, communicating, monitoring, and troubleshooting. You don't have to hire a consultant to get the advantage of planning; this step-by-step guidance offers a great model for you to do it yourself!
This chapter's content is organized in the following topics:
You've likely heard of design methodologies such as 4D (Discover, Design, Develop, and Deploy). The Wi-Fi world has its own set of design steps addressing the many phases of RF design and validation. While all valid, these traditional models don't focus on design, nor do they address the complexity of architecture that crosses disciplines and domains.
My design methodology incorporates five interconnected phases, unabashedly borrowed from the constructs of the Design for Six Sigma (DFSS) framework. For any Six Sigma professionals out there, I hope you'll extend a bit of latitude and allow me to exercise some artistic license.
These five phases are not always linear in nature, but they do link to two concrete processes of inputs and outputs of a design architecture and can be grouped into three stages: discover, architect, and iterate.
The five phases for designing a secure wireless architecture are (see Figure 5.1):
Discover Stage
Architect Stage
Iterate Stage
The discover stage includes the tasks that serve as inputs into the architecture design. This entails scoping and requirements mapping with the first two phases:
Once these two phases are complete, you'll move onto the architect stage, which encompasses the third phase, design.
The define phase includes identifying project requirements, elements of scoped environment, and scope limits.
During this time, the architect should perform activities such as:
This exercise of the define stage of discovery is enhanced by the characterize phase, which aligns requirements to the scoped elements.
The characterize phase addresses the discrete elements for requirements mapping. In this phase the architect captures both qualitative and quantitative security characteristics mapped to the individual classes of networked elements such as endpoints, applications, and users. Those characteristics are then used for functional mapping in the design phase.
The architect correlates items from the define phase such as:
The define and characterize phases together comprise the discovery tasks and are the inputs to the architecture tasks of design, optimize, and validate.
The architect stage (architect being an action here) involves only the design phase, where the inputs from the discover stage are used for functional mapping.
The design phase encompasses the heavy lifting of taking the discovery inputs and performing functional mapping for requisite security controls and monitoring. As part of this work, the architect should also document conditions, variables, and known or anticipated design gaps.
During the design phase, an architect will:
Maintaining security requires continuous improvement, and the iterate stage helps meet this need with the final two phases:
The iterate stage is focused on design iteration and ensuring the architecture is updated to meet changes including those related to new vulnerabilities, changes in the network infrastructure, changes in endpoints and applications, and changes in use cases, among other things.
The design, optimize, and validate phases are iterative, with optimize and validate phases often being interconnected and non-linear.
During these tasks, it's reasonable to expect a proof of concept (PoC). PoCs may be as basic as having the internal team create test SSIDs and validate the operation against the design architecture or as complex as a lengthy structured plan with a vendor that includes installation of hardware and/or software.
During the optimize phase, the design is refined to enhance robustness of performance and security.
With industry standards evolving at an unprecedented rate, wireless endpoint capabilities always in flux, and security threats changing daily, wireless networks are no longer set-and-forget. For purposes of security, the architecture tasks are iteratively optimized and recurringly validated.
As part of recurring optimize phases, architects should be:
As part of the validate phase, the architect will verify capabilities and expected outcomes of the design against the originally scoped requirements from the discover stage tasks (define and characterize). The architect should also plan to communicate with other teams regularly and request feedback from stakeholders to ensure the scope hasn't changed and expectations are met and documented satisfactorily.
After an initial deployment and as part of ongoing improvement, the validate phase will include testing and validation of the system including security assessments and penetration testing, possibly along with compliance audit outputs.
In the iterative validate phases, the architect will:
The five phases facilitate the collection and organization of the data for planning in the form of inputs and outputs. Inputs being data consumed and factored in planning, and outputs being the actionable requirements for the infrastructure design.
The define and characterize tasks of the discover stage provide the planning inputs. During this stage you'll gather information around the business and technical scopes (define) and correlate scoped items to the security requirements (characterize).
In the following pages there are comprehensive notes on questions and considerations of project inputs. Given there is expected overlap, the content will naturally taper with successive topics as overlapping bullets are addressed in the earlier sections and not duplicated.
The first task is to understand the overall project scope. With wireless projects, the scope may be as simple as adding a single SSID, or it may entail a full system design as part of a greenfield deployment or organization-wide upgrade to a different product platform.
Even in the scenario of only adding an SSID, there can be a host of complexity depending on the use case, ownership, and applications to be supported.
The following is a sampling of questions designed to tease out some of the more intricate elements of a scope. Of course, not every project will warrant asking each question but consider this a fairly comprehensive starting point. I've been told I'm nothing, if not thorough. With each question is a selection of scenarios from various client projects and explanations on the relevancy.
This could be a person, a team, or department. For example, it may be the CIO of a retail chain, or clinical engineering team in a hospital, or facilities manager in a manufacturing organization. Understanding what you're doing, for whom, and what they care about is an instrumental part of planning.
The stakeholders likely have a high-level objective to meet, such as they need a wireless infrastructure to support autonomous guided vehicles (AGVs), or a network is needed to support a new nurse paging platform. Frequently the scope may be to fix or resolve an existing issue—such as the push-to-talk application isn't working, and they'd like it resolved. Or the guest network captive portal is being flaky and needs to be redesigned.
The scope may specifically include (or exclude) the PCI environment, or the scope may be to add a single SSID to support a new biomedical device set at a single location, or possibly the scope is to upgrade an existing PSK network to 802.1X.
Non-technical stakeholders don't always understand the impact of the scope they've outlined and asking early provides the opportunity to set expectations early. Physically replacing thousands of APs is a much different time requirement than adding an SSID.
Just as with timelines, stakeholders may not have a concept of whether the ask requires budget, and how much. Even if you don't believe you'll need to purchase anything at the outset, it's possible you'll need additional hardware or licenses and it's great to understand if that's an option. Also, whether budget is allocated or not can be a good indicator of how serious the organization or stakeholders are about solving a problem.
Often security-related projects are driven by concern following an incident at a peer organization, or a general increased threat level for an industry.
As an example, when a local government agency has experienced a breach, the peer agencies will usually tighten down security controls. Similarly, healthcare (among other industries) often experiences cycles of being targeted by malicious actors, and as such those organizations will have heightened sensitivity to security needs during those periods.
Fear and uncertainty often lead organizations toward reactions that aren't necessarily thoughtful responses. It may manifest as a project or request that isn't commensurate with the threat. Put more directly—you have an opportunity to help ensure whatever you're tasked to do will help solve the concern in a meaningful way and not just add busy work with no tangible security benefit.
The project may have some fixed parameters you don't have control over. For example, if you were tasked with creating a new network for connected sensors for facilities monitoring, a constraint may be that the endpoints and monitoring system has already been purchased and your design must work with those devices.
Other times constraints may be operational, such as you're tasked with creating a secure network for home users with remote APs, but the organization is now operating 100 percent remote, and you can't touch the endpoints to provision them.
Aside from the stakeholders who have a vested interest in the project, there may be a different person or group who has final technical authority over the project. Or there may be specific guidance on who should have input into the process or project.
I tend to like a simplified RACI (Responsible, Accountable, Consulted, Informed) approach, which will help capture who owns the project, who has input, and who needs to be updated about the progress or outcome. A simple RACI matrix may indicate who's involved in the project, and a more detailed matrix can detail discrete project phases or tasks.
Figure 5.2 is a RACI chart for a sample wireless project with just four project tasks (left column) and a model with both internal and external teams. For each project task, ideally one person or team is identified as accountable, and others may be responsible, consulted, or informed, indicated with the letters A, R, C, and I, respectively. Completing some or all of the information here can help clarify who is responsible, who has input, and who needs to be informed throughout a project.
The project tasks can be as granular as needed and in more complex projects with an assigned project manager may be much more detailed than this. Conversely, a RACI matrix for a small project may have just one task line.
Aside from the specific groups identified in scoping and the RACI matrix, you'll likely have your own Rolodex of project contributors and collaborators.
I'm a huge fan of efficiency, and one of the best paths to efficiency is through communication. Determining who you need to communicate with, and when, is vital. Even for small projects it's helpful to identify collaborators early. Communicate early and often and you'll lessen the chance of having to do rework because a critical detail wasn't brought in until the end.
Harkening back to the discussion of roles and responsibilities in Chapter 1, there are several teams or roles you'll likely need to connect with, as explained in the following sections.
Regardless of the title, you'll want to have communication with the person who can best offer direction on security requirements for the organization.
Specifically, you'll want to understand regulatory and compliance mandates as well as any organizational policies related to your project. This person should also be able to provide details around any vendor management and supply chain security requirements.
A security analyst or representative from the security operations center (SOC) can help identify requirements and processes for logging and alerting for the wireless infrastructure. This person or team can also collaborate on appropriate actions for escalations internally and define steps for incident response (IR) related to incidents on the wireless network.
Lastly, if there's a SOC they should play a role in the vulnerability management including scanning and reporting on the wireless system and track remediations around recommended security patches.
As one example, with WPA3-Personal networks especially, denial of service (DoS) monitoring and alerting is recommended to prevent DoS attacks through flooding that overwhelms the processor. Knowing this, the SOC should be monitoring and alerting on indicators of this type of attack.
Networks based on 802.1X/EAP authentication or even MAC Authentication Bypass (MAB) will need to reference a user or device account. Your identity and access management (IAM) contact can help ensure the proper connection of the authentication server to the various user or device repositories and participate in any testing and validation.
This person may also need to be involved in help desk procedures that involve account lockouts or password changes.
The IAM team should also play a lead role in the management of your systems' shared credentials and secrets such as SSH keys and API keys (covered in Chapter 6, “Hardening the Wireless Infrastructure”).
As you saw in the first two topics of Chapter 2, “Understanding Technical Elements,” and in Chapter 4, “Understanding Domain and Wi-Fi Design Impacts,” every wireless infrastructure relies on the wired infrastructure to varying degrees.
Whether the wired infrastructure is managing the data paths such as in bridged topologies, or simply serving up domain services, it will always play an integral role in wireless security and connectivity. As such, the network architect and network operations teams (if that's not you) should be your buddies throughout the planning stages.
Domain administrators (if not the same team as IAM) play an instrumental role in connecting or provisioning domain-based services such as DHCP and DNS as well as certificate and RADIUS services.
The help desk teams and processes are an integral part of supporting a secure wireless infrastructure. In addition, they're also your first line of defense (and offense) to help ensure a positive end user experience. Workarounds and shortcuts to bypass complex security controls lead to often overlooked lapses of security. The help desk can reduce friction with end users and participate in a feedback loop to you as the architect as part of the iterative optimize and validate phases.
Whether you're adding a network, updating captive portals, or planning a complete overhaul of the wireless, the help desk can provide valuable input into user behavior and ensure approved processes are followed as part of the security policy guidance.
If your project entails designing and securing a network for a specific application, or for access to/from a specific resource or data set, that application owner should be involved in planning and testing. This person can provide guidance on what the technical requirements are, offer insight on past challenges or issues, and detail the type of access required to and from the application.
He or she may also provide details on how the application is to be used, by whom/what, when, and how. For example, requirements for stationary IP-based temperature sensors are very different than those of mobile telemedicine carts.
Project contributors often overlooked are the contacts from your technology vendor, integrator, or other contractors. There's value in involving each. Having worked with hundreds of vendor representatives over the years, your mileage will vary.
Vendors can bring you product technical expertise, and if your specific account team can't help, they will have an escalation path to the support team, a product subject matter expert, or a product manager. A vendor sales engineer that's fully steeped in the industry can bring valuable insight combining both their deep product knowledge and industry knowledge.
Similarly, if your product reseller is a true value-added reseller (VAR) and integrator, they'll have expert technical resources that can help ensure you're considering all options—including those outside the vendor's portfolio. At the end of the day, the vendor team only gets paid if you buy their products, whereas a reseller often has a broader offering, and other consultants typically only offer services and not products, and therefore have no attachment to the products you purchase.
Aside from vendors, integrators, and consultants, you may also have third-party contractors such as a structured cabling company that may be physically mounting APs, or a penetration testing team, or compliance auditor. These are all great people to identify and communicate with early to reduce the chance of hitting a snag later.
Obviously, this entire exercise of planning secure wireless architectures addresses the countless technical security requirements such as authentication and segmentation.
At a higher level, the organization's more holistic security temperament should also factor into your planning. Chapter 1, “Introduction to Concepts and Relationships,” covered the quantitative and qualitative aspects of aligning wireless security with organizational risk.
The answers to organizational security requirements will shape your approach to designing robust and secure wireless and will define requirements for activities such as audits and testing. The following questions aim to reveal an organization's security requirements:
It's easy to gauge an organization's security culture; here are some questions to consider in support of understanding an organization's overall temperament about security.
Has the organization made security a priority? Does it provide meaningful security awareness training to all employees? Does emphasis on security come from the top down (e.g., from the CEO or board)? Does the organization have written policies around security, and does it enforce them? Do managers tolerate attempts to bypass security?
If the organization has a top-down security strategy that's communicated throughout the organization, then you're working in an environment where security is a priority.
Risk tolerance isn't the same as security culture. In a perfect world, there would be a correlation that organizations with a low risk tolerance (high security requirements) would have a strong culture of security, but that's not always the case.
If your organization has a mature risk management program, then it probably has quantitative data around the risk tolerance and risk posture at any given time.
Without that granular guidance, as demonstrated in Chapter 1, you can make some qualitative judgment calls using a high, medium, low scale.
If the organization is highly regulated and/or very security conscious, it will have a low risk tolerance. Conversely, if the organization is less regulated and has a weak security culture, it probably has a higher risk tolerance and is willing to accept more risk in favor of ease of use or minimizing complexity.
Any specific compliance requirements, auditable controls, or frameworks specified by the organization should be carefully considered during the planning of secure wireless.
Often these include requirements for access control, logging, authentication, approved cryptographic algorithms, and segmentation.
As mentioned earlier, security incidents within the organization, within a peer organization, or threats targeting an industry can all introduce a heightened level of fear, especially from non-technical stakeholders.
If there has been a defining security event that's driving your project, spend time researching and analyzing it to ensure your architecture addresses that vulnerability.
The organization's current security policies (which may include high-level policies as well as more technical standards and procedures) are a requisite input into your planning.
The policies may address who can access systems, when, how, and from what devices. At a minimum, the organization should have guidance around any controls related to compliance requirements. Following are a few other topics that should have policies you'll want to review.
In addition to being an input, updates or additions to policy documents are also an expected output of your architecture. Standards and process documents should be updated to reflect the evolution of industry standards such as the WPA3 security suite, recommended EAP methods, and endpoint capabilities. The following are examples of security policy topics:
The wireless network's purpose is to facilitate the connection of endpoints to networked resources, whether internal or on the Internet. It stands to reason that defining and characterizing the endpoints is an integral part of the design puzzle.
The endpoint capabilities (or lack thereof) will drive all aspects of the wireless design, from connectivity and RF to security. The following sections describe wireless endpoint considerations.
Wireless encompasses a multitude of technologies that can vary from layer 1 and up. Security considerations for 802.11 WLANs (aka Wi-Fi) are different than (for example) wireless personal area networks (WPANs) based on 802.15.4.
The form factor of a device—whether it's a handheld, a tablet, or traditional laptop, for example—correlates to its onboard capabilities (such as processing and memory). Restricted devices are limited in what they can do in terms of computationally intensive processes such as certain cryptographic functions.
How mobile a device is (based on a combination of form factor and use case) also factors into requirements around roaming, among other things.
Lastly, often form factor indicates the bandwidth capabilities of a connected endpoint. A tiny IoT sensor can't possibly transmit the same bandwidth a laptop streaming a movie can, a side effect of onboard storage capabilities and radio capabilities that are often correlated to form factor.
The device OS will further shape capabilities and factor into decisions such as supported authentication methods, whether a device can support 802.1X natively, whether a supplicant agent can be added, and which EAP methods are supported.
The OS of personal devices may also shape policies around BYOD and the ability of the organization to monitor and manage corporate data on a personal device. IoT devices are often running slimmed-down versions of OSs, which impacts the organization's ability to secure and interact with these endpoints.
Who owns the endpoint is another factor for consideration. Whether a fully capable device such as a laptop or smartphone, or a less capable IoT sensor, the endpoint may be owned by the organization, by an employee (such as in BYOD), or even a third party.
Third-party ownership of endpoints is not as rare as one might think. It's common in organizations to have subsets of endpoints being managed by a third party such as in many healthcare biomedical devices, or for organizations that have managed print services where printers are more or less rented and maintained by a service provider.
Ownership of the device doesn't necessarily correlate to management of the device. For example, in the realm of personal use devices at work there's not only BYOD but also a cornucopia of acronyms such as CYOD, COBO, and COPE for choose your own device, corporate-owned business use only, and corporate-owned personally enabled, respectively. The alphabet soup demonstrates the mixed ownership-management models prevalent in today's enterprises. These ownership models are detailed more in Chapter 8, “Emergent Trends and Non-Wi-Fi Wireless.”
Also, as with third-party owned devices, there may be managed services models with corporate-owned externally managed devices.
Who owns and/or manages an endpoint will greatly impact the organization's ability to manage and change configurations such as moving an endpoint to a new SSID, or enforcing DHCP versus static IP addresses.
Where are the devices located? Are they in an employee's home? At an office? For IoT-type devices, they could be distributed over large areas including outdoors.
Whether an endpoint has a user attached or not is a factor in security, specifically how the device can be provisioned, connected, and maintained throughout its life cycle.
Headless devices not only are not user-attached, but may not have an interface for configuration input.
As you saw in Chapter 4, fast secure roaming protocols play a major role in wireless security. Instead of falling back on passphrase-based networks, endpoints that support Fast BSS Transition (FT) can connect to 802.1X-secured networks without sacrificing speed and reliability.
Because of that, the endpoint's roaming capabilities remain a major factor in planning secure Wi-Fi networks.
Along with roaming, the WPA version of security an endpoint supports (WPA2 or WPA3 and Personal and/or Enterprise), plus the cryptographic algorithms, and suite of EAP methods determine its security capabilities. To be considered along with WPA3 is support for the newer encrypted Enhanced Open.
The endpoints' security capabilities will then determine how you must architect security profiles, and whether you'll need to use Transition Modes (to support legacy security protocols) or strict WPA3-only modes. Traditional OS-based endpoints receiving updates from the manufacturer can likely be updated to support newer roaming and security features.
As with other considerations in the inputs, the endpoint security and roaming capabilities can also be an output of the design, if the organization is in a position to specify requirements for procurement or prepared to upgrade incompatible endpoints.
The volume of any class or group of endpoints will help inform requirements for IP address space, segmentation, and options for provisioning.
Taking all of the above into consideration, you'll then classify or group similar devices together. This is your starting point for the planning templates and tables provided later in this chapter.
For endpoints that have users attached, such as traditional OS-based devices that support user logon, several aspects of the user should be considered. Following are a few bullets to help uncover relevant user attributes.
What expectations does the user have about the wireless connection? They may make assumptions about security, performance, uptime, and support, among other things.
How are the user accounts organized and managed? Where the user accounts reside, how they're managed, and referenced in network connection policies such as those in 802.1X-secured networks will dictate how granular your access control policies can be.
Is the user an employee, a contractor, or guest? The answer to this question sets expectations about the ability of the organization to monitor or manage the user's endpoint, and what type of control the organization has over the user.
In this phase of information gathering, the architect will use information about the endpoints, users, and systems to begin documenting who needs access to what. Those elements are further characterized by the knowledge of security compliance requirements and risk tolerance to later determine appropriate security controls—segmentation, authentication, cryptography requirements, logging, etc.
In addition to the questions and information gathered so far, following are a few questions to direct this activity:
The application(s) to be supported on the wireless network will have requirements for connectivity, service level agreements (SLAs), quality of service (QoS) needs, bandwidth demands, and possibly roaming requirements. For IoT deployments, factors like power capabilities and duty cycle also come into play.
In addition, the application and its data may be in scope for compliance regulation such as PCI DSS, Health Insurance Portability and Accountability Act (HIPAA), the federal Cybersecurity Maturity Model Certification (CMMC) program, or in the U.S. even fall under the purview of the U.S. Food and Drug Administration (FDA) Center for Devices and Radiological Health (CDRH) division. The following are factors to consider in supported applications:
The design may need to happen within the boundaries of certain system or process constraints, such as options for onboarding or provisioning devices.
Process constraints can apply to both greenfield and brownfield deployments but are naturally more prevalent in brownfield deployments where there will be limitations of existing infrastructure, applications, or workflows.
An example of a process constraint would be a requirement to provision secure remote AP access and onboard home users to the enterprise network without having access to the endpoint ahead of time—a common scenario in today's world with many organizations having moved to a 100 percent remote workforce.
Other process constraints may be related to provisioning options for headless or IoT devices, workflows within change management procedures, or an inability to change a directory structure for authentication purposes.
Last but certainly not least—in a brownfield deployment the wireless infrastructure may be already in place, without the option to upgrade, redesign, or replace those products. If that's the case, you may be working within product and management architecture constraints. Although not ideal, it's probably the most common scenario, especially for 802.11 WLANs.
And, as with a handful of other inputs, the wireless management architecture (e.g., controller versus cloud) and/or the wireless products may be a design output. In a greenfield deployment, or an upgrade scenario where budget is allocated, the architect may have the option to specify the product solution.
Your analysis during both the discover stage and the planning tasks coming up next should address any limitations of the current network infrastructure as it relates to the desired security configuration. There may be opportunities for incremental changes, or the organization may simply need to begin budgeting for refresh cycles.
The information collected in the discovery tasks (define and characterize) will have informed what security controls are required for the network, connected endpoints, and accessed resources.
The outputs of the architecture planning are tied to the phases of design, optimize, and validate. As explained earlier, the optimize and validate phases are iterative and often intertwined.
The output will entail about a dozen different aspects, from the overall connectivity technology (e.g., 802.11 vs. cellular vs. Bluetooth), the types of wireless products including infrastructure and (if you're lucky) endpoints. The outputs of the design will also specify the requisite segmentation and data paths, wired infrastructure requirements, domain services needed, wireless networks/SSIDs, hardening, and possibly additional tools or software.
Digital transformation projects and networks that are greenfield for novel use cases present the perfect opportunity to build a full secure wireless architecture holistically, including specifying the underlying connectivity protocol—802.11 WLAN, cellular LANs, Low Power WANs, Personal Area Network protocols, etc.
As part of the earlier work, the task of identifying which wireless protocols might work for the use case will have been completed as well and may further inform (or expand) the options around endpoints and endpoint capabilities.
For example, if you're tasked with researching and specifying a new network for point of care technology in a hospital, you might consider both 802.11 WLANs (Wi-Fi) as well as cellular LANs. In your research, you may find the cellular LAN solution is more cost effective, more secure, and more resilient than a comparable Wi-Fi solution in the same environment. In doing so, you'd then have the opportunity to specify many aspects of the wireless infrastructure, from the connectivity protocol up.
To summarize, here are a few of the dependencies that dictate which protocols and technologies can be considered.
The combination of requirements in these areas will determine the wireless technologies that can be considered:
The wireless network is only as secure as the endpoints attaching to it—and if you're lucky, you may get a rare opportunity to specify endpoint capabilities as part of the secure architecture. As described in the preceding scenarios, digital transformation programs, new use cases, and projects with a greenfield deployment are the perfect times to jump in and be prescriptive with endpoints and therefore endpoint capabilities.
In Wi-Fi networks, two key factors are support for the current version of WPA security (in this case WPA3) and support for fast secure roaming protocols (currently 802.11r being the reigning technology). Aside from that, endpoints should be Wi-Fi Alliance Certified to ensure functionality and interoperability (you'd be surprised how many aren't).
In other non-802.11 wireless technologies, endpoint capabilities to specify include of course the connectivity support, authentication and provisioning options, and encryption.
It was noted that greenfield deployments are a rare opportunity; in brownfield deployments options will be more constricted, as you'll have to work with what's there and make migration plans (e.g., from WPA2 to WPA3) accordingly. Having said that, when working on secure wireless enhancements in existing environments, there may be opportunity to upgrade existing clients to meet the latest standards for fast secure roaming and WPA, as follows:
The wireless management model (on-prem versus cloud) and products may be an input into your design, or the product of your design as an output. Again, greenfield deployments present unique opportunities but upgrades to a new product or new vendor solution during a refresh cycle present a similar opportunity.
Cloud-managed platforms offer organizations yet another distinctive opportunity during refreshes and expansion. The nature of cloud management makes it exceedingly easy to deploy a new product incrementally and in parallel with an existing solution. Meaning whatever exists in the environment currently, a network architect could deploy a second solution (from another vendor or a different platform from the same vendor) as part of an expansion or partial replacement of the existing solution.
Cloud solutions alleviate the hefty upfront expenses of on-prem infrastructure, plus offer a more linear cost model with AP-based subscriptions. It's easier now than ever to deploy a new solution and manage costing models associated with AP allocation to departments or locations.
However, cloud-managed solutions aren't for everyone. During your design, you may simply decide to modify an existing controller configuration for the desired effect, combining tunneled and bridged traffic to meet requirements, as follows:
RF design and AP placement are outside the scope of this book, but a critical piece of planning any wireless network. As you learned in Chapter 4, fast secure roaming protocols (which enable the use of more secure standards like 802.1X versus passphrase-based networks) depend on a proper RF design. The following are reminders for proper RF design:
Authentication in secure wireless encompasses authentication of endpoints, users, as well as the infrastructure and the admin access (as in hardening). Chapter 6 is all about infrastructure hardening with a deeper dive into that topic.
Each of those decisions will be informed by the requirements identified during the define and characterize phases. Your decisions around authentication schemas should include the following considerations:
Decisions around data paths will be commensurate with the management model (cloud or on-prem with a controller or tunnel gateway) and security requirements.
For example, in a highly regulated environment it's common to prefer tunneling some or all client traffic to controllers or a tunnel gateway. At a minimum, restricted traffic such as guest networks and regulated traffic such as those falling under HIPAA and PCI DSS regulations should be tunneled for segmentation and the ability to extend encryption over the wired network.
To plan data paths, consider the following best practices with the usual “it depends” caveat and an understanding that any recommendation for bridged traffic comes with the stipulation of “if policy allows” and any recommendation for tunneled traffic comes with the assumption the underlying network architecture supports it.
The wireless architecture will dictate many aspects of the wired infrastructure, from security and segmentation to meeting resiliency and uptime requirements.
The edge switch port, edge switch configuration, router/routing switch configuration, and firewall all are impacted by the wireless network. Beyond the firewall, the WAN infrastructure may also be in the equation.
The edge port must support the power over Ethernet (PoE) requirements of the AP as well as bandwidth requirements, with a reminder that new Wi-Fi 6E will oversubscribe a standard 1 Gbps edge port and multi-gigabit Ethernet may be needed.
The edge switch will have to meet the overall PoE load across all ports, and ideally also support always-on PoE that would keep APs up during a switch reboot. The edge switches also play a role in the high-availability design. Of course, the edge switch is center stage in bridged deployments where the ports require configuration to support any bridged client networks.
The router or routing switch has an especially active role in bridged topologies, likely the point of access control through ACLs, and also DHCP proxy. Moving further north in the traffic path, the firewall will (at a minimum) be configured for inward-facing routes and firewall policies allowing traffic to and from the wireless networks from the Internet. Those firewall policies also define any security inspection of the traffic. A firewall may also be the point of traffic filtering for segmentation.
Beyond the firewall, the WAN infrastructure may need tweaking to support wireless traffic efficiently, specifically through proper routing of both client and management traffic. Where VLANs are in use, IEEE 802.1Q (aka QinQ tunneling) may need to be configured along with jumbo frame support. In fact, throughout the wired infrastructure, frame sizes are also a consideration—there's a delicate balance required to minimize roundtrips with larger frames, but not introduce latency to sensitive applications (like voice) by stacking or aggregating too much data at once.
Consider the following when planning wired infrastructure elements:
Domain and network services such as DHCP and DNS will be dependent on the data paths and topology. Different wireless networks will likely have different data paths and therefore require configuration of network services at different places.
The wireless architecture will also determine the authentication (RADIUS) server policies to be configured, the user directories referenced, and the certificate services required (for servers and optionally endpoints). Consider the following when planning domain and network services:
Ah, we're finally here! The place most IT pros like to start is actually the last step in planning—the wireless network, or SSID in Wi-Fi.
Looking over the preceding half dozen topics, each of those will need to be decided and planned before configuring the wireless networks.
The example and language used here will be 802.11 WLAN specific (Wi-Fi), but the same concepts apply to other wireless technologies as well.
Once you have the prior elements figured out, you'll configure the wireless network and designate the following:
Availability still being one of the three security pillars, the design should address all aspects of high availability and resiliency from the AP to switch and controller. Consider the following when planning system availability:
The design may call for security features not natively supported in the infrastructure you have. One very common example is the need to validate or authenticate both a user and a device on an 802.1X-secured network. In a Microsoft Server environment, the logic AND
statement is not supported in Microsoft NPS RADIUS. The options are to use the EAP-FAST with chaining (most likely via Cisco ISE), find devices that support the standards-based EAP-TEAP, and/or purchase a different authentication server with advanced policy support (such as Cisco ISE, Aruba ClearPass Policy Manager, Fortinet FortiNAC, Forescout, or similar).
Along the same lines, the design may call for an endpoint agent (software) to be added for feature support or feature expansion such as supporting additional EAP methods for authentication.
Throughout the process, known limitations and security vulnerabilities may have been identified and documented, and the design may call for additional tools for testing and validation, or for security monitoring and alerting. At a minimum, there may be an overlay testing tool for troubleshooting or for continuous testing and validation of application SLAs. Consider the following when planning additional software or tools:
Whether greenfield or brownfield, the secure design should include updating or creating related processes and policy suites. It's the job no one wants to do—documentation—but it's essential to maintaining a secure wireless infrastructure. In fact, many security standards (such as NIST) include documentation as part of the scoped requirement.
If this book has demonstrated nothing else so far, it's shown that secure wireless infrastructures touch almost every aspect of an organization—from endpoints to servers and Internet and from compliance regulations to wired switch configurations. The processes are no exception; expect to address processes ranging from end-user support to secure device provisioning and ongoing security monitoring.
In addition, the documented policy suite (policies, standards, processes) will need to be updated. As an organization moves (for example) from support for legacy WPA and WPA2 protocols to WPA3, network configurations will need to be updated, additional segmentation may need to be enforced, and the list is a long domino of changes.
The processes and policies that will likely need to be reviewed and/or updated include those addressing topics, such as:
Infrastructure hardening bolsters the integrity of the network and works toward a trusted infrastructure design. It involves disabling unused protocols, securing management access, removing unsecured protocols in favor of encrypted ones (such as disabling telnet and enabling SSH), and authenticating the infrastructure components (such as controllers and APs) to one another.
At a minimum, every organization, regardless of size, should plan for a few basic best practices:
These are considered the bare minimum effort; many organizations have requirements that extend well beyond these tasks—topics covered in the next chapter. The federal government and U.S. Department of Defense (DoD) and peer organizations outside the U.S. all have relatively extensive guidelines for network and system hardening.
The next task is to correlate inputs from define and characterize phases and map to outputs of define, optimize, and validate. Working with the ecosystem of wireless technologies can be more of an art than a science, and your design will require iterative phases of tweaking and repeated validation—validation here meaning validation against the originally defined requirements.
For example, you may design an ideal 802.1X-secured network with FT for fast secure roaming to support a new cloud-hosted VoIP deployment, only to find out the desktop phones and some users' personal smartphones don't support FT. In which case, you may have to re-architect for PMK caching, opportunistic key caching (OKC), or even sacrifice security and move some devices to a passphrase-secured network to eliminate the latency of key distributions during roaming.
Figure 5.3 offers a visualization of the relationship of inputs from the discover stage (define and characterize tasks) to the outputs of architect and iterate stages (design, optimize, and validate tasks). This example is a general-use map, and yours may look a little different. It's possible not all inputs influence the same design outputs, and it's very likely your project might include custom considerations not reflected here.
Take this mapping as a template to start with and adjust as needed for your projects. Once settled, the map will allow you and other team members to quickly identify dependencies in the architecture. If nothing else, the generic map here is a great tool to help other teams understand the depth of interdependencies of wireless network architecture.
In case you're interested, Figure 5.3 was created with a free tool found at https://miro.com/templates/mind-map/
.
Following are a few planning and design templates, modified slightly from the versions I've used in scoping and documenting client projects. As with the mind map in Figure 5.3, I encourage you to take these and make them your own.
This chapter thus far has summarized the considerations of the various elements to be considered as inputs, as well as how those affect the outputs of design. It's a lot of information and (in my opinion) too much to attempt to aggregate in one table or chart. Instead, there's a sequence of planning templates and guides that are interrelated but used at different phases.
The first template helps organize data and requirements from the define and characterize stages (discovery stage tasks). Following that is a sample SSID planner for Wi-Fi networks, and then a NAC Policy Matrix for planning access rights (authorization) for users and devices.
Just as the header implies, the Requirements Discovery Template is a form designed to capture and organize the technical and business requirements for security of the system, users, and endpoints.
Referring to our borrowed Design for Six Sigma (DFSS) lingo, this document captures detailed scoping information such as types and counts of endpoints (define), and then characterizes their security requirements (characterize). At the end of the exercise, the deliverable is a well-organized description of security requirements.
The table in Figure 5.4 is meant to serve as an example of one way you might go about collecting and organizing data. The tables are populated with sample data for context.
As you're planning, here are a few considerations about this template example:
The table in Figure 5.4 is populated with generic but real-world data common in many enterprise environments. In these organizations, it's expected to have a mix of corporate-owned and personally owned devices and a blend of traditional OS-based systems along with non-user-attached endpoints like printers and VoIP phones, plus IoT-type devices for cameras, door entry systems, facilities monitoring, and screen casting.
In this exercise, don't worry about it being perfect or pretty. Just gather as much information as you can and organize it in a way you can sort, sift, and group later.
Figure 5.4 is a sample table, which captures the following information for each row (group or classification of endpoints):
The description column is just to capture a commonly accepted label or descriptor of the group of endpoints.
Form factor describes the endpoint such as a laptop, phone, tablet, printer, biomedical device, etc. Just as with description the form factor isn't a fixed set of options; use descriptors that are meaningful to you and as granular or broad as needed.
An estimated quantity is to capture a rough order of magnitude for each type of endpoint.
Ownership describes whether the endpoint is owned by the organization, an employee (such as BYOD), a third party, or perhaps even a specific department in the company.
Management of the device may also be by the organization, or personal/employee user, a third party, or as shown in the BYOD example it could be managed by the organization specifically with an MDM tool.
The column of access requirements is a rough estimation of the type of access the endpoint group needs. Some will require broad internal and Internet access, while specific subsets such as printers or handheld scanners may only require access to a specific server(s).
Capturing known capabilities or limitations of endpoints at this stage is helpful in planning network authentication and security profiles.
Inevitably you'll have some notes-to-self, links, or reminders that can go in an ad hoc notes column.
While best practices pervade across industries, there are some environments that require special attention when planning wireless security, and healthcare is one of those.
Figure 5.5 uses the same template as Figure 5.4, populated with a subset of data from a representative healthcare environment.
There are numerous special considerations for planning both wired and wireless network security in healthcare—specifically those with patient services and/or biomedical devices where both availability and security are equally important for ensuring services are available and meeting HIPAA requirements while keeping biomedical devices protected.
Along with healthcare, manufacturing, warehouse, and retail use cases bring similar complexity. For parallels, healthcare's nurse paging and biomedical devices can easily be substituted by manufacturing's needs to support handheld scanners and automated forklifts. Both have similar IoT-like qualities and demands for security and availability. Retail also includes heavy use of handheld scanners, has requirements for point of sale solutions, and may also be using location services.
Healthcare comes in many forms, ranging from hospitals to outpatient and ambulatory care facilities, labs and testing, and small primary care offices. Most of my experience has been with mid to large healthcare systems that include several hospitals as well as numerous outpatient clinics. When working in smaller doctor's offices or clinics, there's a bit less complexity with the biomedical devices, but it's still present.
This is a bit of a sidebar topic, but the timing is relevant while you're in the define and characterize phases. One important task you'll likely have is to work with various stakeholders to characterize what BYOD means in your organization; and it may mean different things to different people. Don't make any assumptions when working through the discovery phase.
I've found it helps to outline straightforward options and ask which scenario is intended.
Of course, there should be an organizational policy around BYOD that defines what users have access to from personal devices, what type of visibility or management the organization has over the device, and what happens in the event of an incident—will the phone be wiped, will the corporate container and accounts be wiped, what's the policy for using a personal account for business communication, what are expectations should the device be in scope of a legal investigation and e-discovery.
Legal and policy issues aside, there are a few technical descriptors for defining what BYOD really means, and ultimately, we're just aiming to understand if they're treated more like guests or corporate assets.
What does the user need access to when on their personal device? This answer varies depending on form factors, users, applications, management of the device, etc., but for our purposes at this stage you can categorize BYOD into two main headings.
In these cases, you'll want to tentatively plan for some method of device registration with a longer duration than a standard guest user. This can be accomplished with some vendors' Wi-Fi captive portals natively. Other solutions may involve a NAC or guest management solution with the option to register a device for an extended period of time.
The ideal scenario is to register the personal device to the corporate user and set it to expire after a predetermined time. In an enterprise, personal devices might be authorized for 90 days up to a year. In universities, it's more common to authorize them for the semester or year.
If a user-attached registration is not possible, a basic captive portal for this purpose with a longer account life is perfectly reasonable.
There's only one hard-and-fast rule here. You never want to allow corporate users to connect an unmanaged personal device to the secured internal networks using their domain credentials (specifically applicable to networks configured for 802.1X with a tunnel like PEAP and MSCHAPv2 as the inner authentication).
This is another opportunity to remind you that Microsoft NPS as a RADIUS server does not support restricting access based on both a user and endpoint—it's either or. To meet this recommendation requires an advanced authentication server or NAC product.
If this is the scenario, be sure to review information on BYOD planning in Chapter 8 before getting too far along.
The truncated advice is that this should only be allowed if the organization has a well-defined executive-sponsored policy on the topic and has security controls in place to mitigate risk—specifically the organization should enforce use of a corporate-managed mobile device management (MDM) or other endpoint agent for visibility and control of the corporate data.
In addition, if personal devices are to have unfettered access to internal resources, they should all connect to the network securely; on wireless that means using 802.1X-secured SSIDs, which requires some onboarding or configuration of that device for the selected EAP method for authentication.
Summarizing the recommendations for planning in the preceding text:
It seems most organizations don't document their wireless networks unless forced to do so by regulation. It's really a missed opportunity to streamline planning, memorialize the configuration for others to reference, and for you to use in iterative updates, troubleshooting, and enhancements as new security features become available.
The sample forms here are very generic and capture the minimum information required for planning and documenting a wireless network (see Figure 5.6). Additional implementation- or product-specific details may be warranted, such as integrations with NAC or security monitoring tools.
The SSIDs in Wi-Fi networks should be planned and documented carefully and capture not only the various 802.11 and RF specifications, but also key elements of the security architecture such as the VLAN, DHCP server, default gateway, authentication, and secure roaming protocols (see Figure 5.7).
This format is designed for gathering planned configuration details with guidance. A different format such as a spreadsheet or script may be preferable for the implementation.
The earlier template for cataloging endpoints, capabilities, and requirements included abstract information on what access might be required—Internet-only, certain internal networks or resources, or some combination of both.
The Access Rights Planner (something I refer to as the Policy Matrix when used for NAC planning) is a tool to further refine access rights based on multiple static and dynamic conditions. This form can be modified to be more VLAN or ACL-centric but in its current form is intended to specify authorizations at a higher level. How and where you apply the control or segmentation is implementation- and product-dependent.
Two versions of the planner are provided: a full NAC-based planner that takes into account endpoint security posture, and a simplified planner for wireless connections only and without security posture variables.
If you're planning at this level, this should happen before the Network Planner (shown prior) to inform decisions around VLANs and other access control or role enforcement.
This version of the planner would be used with advanced authentication services or products with NAC features (such as Aruba ClearPass Policy Manager, Fortinet FortiNAC, Cisco ISE, Forescout, and others).
As with the other templates, this is just one example of how to organize the information and serve as a starting point (see Figure 5.8).
In most cases, I group sections based on who owns the device—the organization, employee/personal, contractor, or guest. For each group, the table then outlines what access rights and segmentation is to be used depending on (in this example) the security posture of the device, the type of device, and the user logged on to the device.
Defines whether the device is owned by the organization, employee (personal/BYOD), a contractor, or guest. In some cases you may prefer to group by department ownership as well.
Describes the type, class, or form factor of the devices, such as laptop, printer, smartphone, VoIP phone, handheld scanner, biomedical device, etc. The language here is meant for ease of identifying and communicating internally so use what makes sense to your team.
Identifies the condition of what user is logged on to the device, such as a domain user, no user, or guest
Some access policies may only apply to specific locations or network segments. In the example planner there are different policies for wired versus Wi-Fi versus VPN remote access. They may also vary for roles in different countries or regions.
Defines how segmentation will be imposed. This basic example set includes VLANs and VRF references. With some Wi-Fi products you may also be able to specify a role or policy with an associated set of access rules or ACLs already defined. Access rights should also address duration if the access is only for a predetermined amount of time.
Devices accessing the production resources should have some level of visibility or control by the organization. For domain devices, that's usually accomplished with a software agent. For personal, contractor, and guest devices, options vary depending on touch but typically include MDM (for BYOD control) or no additional controls (as for guests).
Figure 5.8 is an advanced access rights planner for a typical enterprise organization broken down by organization-managed, employee-owned, and guest. Additionally, a sample healthcare clinical device is included to demonstrate the flexibility of the template.
Universities and other institutions of higher education bring a bit of a twist to network security planning since the bulk of their use models are BYOD—students with personal devices both in the classroom and in residential halls.
This sample form (Figure 5.9) outlines authorization for college-owned devices, student-owned devices, and guest devices under varying conditions. Note this environment plans for agents on school-owned devices, and calls out requirements for MDM for the school-owned smartphones that have access to internal resources.
Just as healthcare has some quirks when it comes to planning wireless security, so too does higher education where environments are predominantly glorified BYOD models.
If all of that feels overwhelming, or you simply don't need to plan for posturing and agents, you can simplify the model drastically.
In the sample form in Figure 5.10, the location column has been removed, along with any rows that didn't correlate to the wireless network. In addition, columns for the security agent posture and associated rows for endpoints that were out of compliance or at risk have also been eliminated.
This template can be further enhanced by adding context around the access—specifying the SSID or network name, along with the authentication schema to be used.
For more complex environments, an additional column could reference the directory to lookup the user or endpoint details—such as Active Directory, a NAC server, or other database or repository for MAC addresses.
This section summarizes key findings and recommendations appropriate for technical and non-technical executive leaders, offering fourteen bullet points organized into three overarching themes:
It's impossible to summarize an entire book's worth of content into a few pages, but the selections here speak to the most common non-technical errors organizations make when planning, deploying, and managing secure wireless networks.
Managers and executive leadership have an exceptional opportunity to help the organization meet its security objectives in the earliest stages of planning and budgeting—before network architects are restrained by Wi-Fi and endpoint product selection—with these six key tips:
Secure wireless architectures permeate every aspect of IT, cyber security, and digital transformation initiatives. The considerations, decision factors, and inputs into a secure wireless design are innumerable. When the wireless architect is brought in after scoping, they can't always just “make it work.”
Security in wireless has deep interdependencies on not only the wired infrastructure but also endpoint capabilities—an often overlooked and critical component. As such, you should involve all contributing architects early to collaborate at the onset of any ideas or projects. You'll save a lot of time and money if you don't pick a technology or product and don't purchase new endpoints or infrastructure until the entire team has been read in. If you don't have a qualified wireless architect in-house, use a consultant.
If there's one lesson I learned in fifteen years of leading advanced network security projects, it's that collaboration is critical. Whether you're planning a digital transformation program, a zero trust strategy, network access control, or just enhancing the wireless security, you need input from several teams or people.
The days of siloed networking, wireless, security, and identity management are over. Cross-functional teams will advance your mission, facilitate communication and collaboration, and build the trust required for these more complex projects.
Most CXOs I work with have a gut instinct that newer technology equals greater range, but the opposite is true. Wireless standards are evolving rapidly. Sparing you the gory technical details, in general the faster speeds of Wi-Fi (due to modulation and encoding plus new spectrum) means the effective range of the Wi-Fi is much smaller.
That means the organization needs to stop trying to replace APs 1-for-1. The design you did nine years ago for Wi-Fi 4 (802.11n) simply won't cut it for today's Wi-Fi 6 (802.11ax) and tomorrow's Wi-Fi 6E deployments. Plus, the use cases and applications running on Wi-Fi a decade today pale in comparison to today's demands.
Proper RF design specifies AP counts and placements. A wireless architect or consultant can provide a brownfield design, reusing cabling drops and mounts, but you'll need to budget for additional APs. A completely unscientific but data-driven estimate is that you should allocate an additional 5–10 percent of AP count with each generation of technology. So if you're going from Wi-Fi 4 (802.11n) to Wi-Fi 6 (802.11ax) plan to increase the AP count by 10–20 percent.
In addition to procuring the proper count of APs based on a qualified design, it's smart to budget for at least an additional 5 percent overhead for spares or to fill in coverage or quality gaps.
Having said that, adding APs willy-nilly is also a poor strategy for wireless. Additional APs it not always the answer; if you have user or application issues, work with a qualified wireless architect to survey and recommend remediation.
Choosing not to follow the design and instead reducing the AP count (or simply repeating a 1:1 upgrade) not only impacts coverage and quality, but also security.
Secure wireless relies on 802.1X networks that are authenticated and encrypted, with the downside being additional overhead and delay associated with the authentication and key exchanges. As users physically move, their device will roam from AP to AP. Wi-Fi networks support fast secure roaming to reduce latency, but if the APs are too far apart or otherwise not properly configured, the endpoint experiences a hard roam where the full authentication process is repeated.
A hard roam can easily take 10 to 20 times as long as a fast secure roam.
While the user may not notice, the applications will. Streaming media, video, voice, and online collaboration tools will be affected. That impact is devastating to any latency-sensitive application including mobile clinical devices and nurse paging technology as well as push-to-talk apps, handheld scanners, plus inventory and warehouse automation.
The unintended consequence of this all-to-common scenario is that wireless manufacturers instruct admins to put these critical devices on (unsecured) passphrase-based networks, which offer encryption but not authentication, and in current form of WPA2-Personal are very vulnerable to attack.
Poor RF design is also the leading cause of users plugging in rogue devices, which presents a litany of even more serious security concerns.
By getting a qualified RF design, following proper AP placement and radio settings, fast secure roaming can be supported, and more devices, users, and networks will be secured properly.
AP placement and RF design impacts:
The worlds of wireless, networking, and IoT are moving at a fast pace, and the intricacies of the technology plus the vendor products and myriad monitoring and management tools are too much for even the most astute IT professional to keep up with. Wireless technology is its own beast, and even a seasoned network engineer will need ongoing training.
If security is a priority for your organization, then an annual budget for training and tools is vital.
Not sure where to start? I strongly suggest sending your primary architect to at least one in-person event or training a year and ad-hoc and online training throughout. If budget allows, two events or combination of event and training is ideal.
Mileage and pricing vary by region. For more junior engineers and admins, you may either need to spend more to get them up to speed, or alternatively rely more heavily on free online resources and allocate a smaller budget for those professionals.
If your organization really can't budget for professional development, or has temporary budget holds, there are free online resources and content from vendors and industry (vendor-neutral) events. Having said that, if an IT pro I'm mentoring repeatedly tells me their organization won't allocate budget for professional development, my recommendation to them is to find a new employer.
Wireless (including and especially Wi-Fi) is complex and multi-dimensional, and the technology evolves quickly, meaning proper and current tooling is critical. Wireless devices are dependent on the physical radio and your wireless architect simply cannot run a software upgrade on most RF tools to support the latest tech.
If you're lucky enough to have a highly skilled wireless architect in-house, then you're leaps and bounds beyond most organizations. What's more common is a network architect or other system administrator fitted with multiple hats, wireless being one.
Whatever your team's expertise, consultants and third parties can be invaluable during the planning and budgeting phases or wireless projects.
And while, yes, I'm a consultant in this space, this isn't a sales pitch. You likely have resources available through your vendor or integrator. Not all systems engineers (SEs) are created equally, and you'll definitely want to seek out a professional who's steeped deeply in both wireless and security. Hey, maybe even someone reading this book!
Just remember that the vendor's team—sales or engineering—will have bias and possibly a very narrow scope to assist. Over many years, I can recall only a handful of wireless vendor sales engineers that were exceptionally knowledgeable both in their own product and in the industry technology.
Your reseller or integrator likely has a broader view and often isn't tied to one product or manufacturer, making them an ideal source for assistance.
If you're looking more for security best practices and answers to “can we” or “should we” then a more specialized advisor with knowledge of compliance requirements may be a better fit.
Often, the selection of wireless products and vendors occurs before the technical team is afforded any opportunity for input. Not only is it demoralizing to the technology professional, but it often results in poor product selection and an inadequate security architecture. Also, my hope is that leaders will embrace, or at least explore, novel solutions to meet business objectives.
I offer CXOs the following considerations when selecting products and technologies:
Wi-Fi is one of many wireless technologies that may be appropriate for your enterprise projects. Technology selection depends on the use case and varies based on:
Details of these are covered in Chapter 8, and include:
Wi-Fi, for in-building and short-range outdoor applications
New technology, for both in-building and long-range outdoor applications and support of use cases where Wi-Fi doesn't meet the connectivity and security requirements
Include LoRa, Sigfox, and modified cellular technology for long-range communication
Including the suite of protocols based on 802.15.4 such as Zigbee Matter, ISA100.11a, WirelessHART, 6LoWPAN, Thread, plus BLE and others for shorter-range communication
Through my many years of security consulting for midmarket up through Fortune 5 clients, the question asked most often is “what are my peer organizations using/doing?”
There's value to running with the pack on certain matters, but when it comes to product selection, what your peer organization chose may not work for you.
One of the consistent roles I've had over the years is consulting with clients both ad-hoc and through structured readiness assessments for refreshes or disruptive and emergent technologies. Throughout those projects, there have been numerous considerations including a few that repeatedly appear as analysis inputs:
Selecting the right product can make or break a project, but there's another side to this coin. With wireless technologies, there are many times the issue is not with the product but with the implementation. There have been scores of times I've been brought in to make suggestions to replace an inadequate wireless product only to discover the system was not properly designed and/or installed.
Others, such as NAC products, don't have the same feature parity and 70 percent of the time, a failed NAC project is due to improper product selection.
Every time an executive selects a vendor based purely on where they fall in an analyst ranking, an angel loses its wings. Okay, maybe that's not true, but often the best and brightest solutions aren't necessarily in the Gartner Magic Quadrant Leaders' block. There's a place for the Visionaries, Challengers, and Niche solutions.
The world of industry analyst services is really bizarre:
It's a rare breed—the analyst with true industry expertise who can meld their understanding of real-world needs with a forward-looking strategy. Gartner has a lot of great industry information, especially with the Peer Insights, and sometimes they do get it right on the Quadrant. Other firms to watch are Forrester (www.forrester.com
) with their Forrester Wave analysis. As an aside, if you compare Gartner's Magic Quadrants for datacenter and wireless against Forrester's Waves of the same segments in recent years, you'll notice the Gartner analysis trails the Forrester findings by one to two years.
There are also niche players like IANS Research (www.iansresearch.com/
) who specializes in cyber security topics and uses practitioners instead of analysts as advisors. I have a relationship with IANS and serve as advisory faculty.
The vendors, too, bring a lot of hype to the process. The shiny new security features they promise may or may not work in your environment; may have dependencies they're not up front about and may not work nearly as well as advertised.
All of that to say—please involve your technologists and architects in planning and decisions before you or other executive leadership select a product. If you feel your technology professionals aren't equipped to participate in that decision, then involve a consultant.
“I want one throat to choke” is a popular sentiment among CXOs. Yep, I hear you. But the reality is the next few years are defining moments for the technology industry. Zero trust strategies, digital transformation projects, and the convergence of IT, OT, and IoT along with a climate of significant security restrictions will strain even the most mature organizations.
The growing demands of our secure infrastructures require agility, flexibility, and scalability—all characteristics that rely on interoperability.
There are always exceptions, but these recommendations will help prepare your organization for whatever may come:
New security standards, new technologies, and new threats bring with them new recommendations. Expect to move away from PSK-secured networks and be prepared—the organization's relying on you to step up and help define BYOD security, privileged access management, and more.
Here are a few things to know:
Oh, and please help your technologists get the scheduled maintenance windows they need for critical patching and testing.
What does that mean? Networks secured with pre-shared keys (specifically networks that allow WPA2-Personal) are exceedingly vulnerable to a host of attacks including both online and offline dictionary attacks, among others.
Years ago, the mantra was “WEP is insecure, upgrade your networks.” Well, today's mantra is “PSK is insecure, upgrade your networks.”
Your organization should eliminate PSK-secured networks and instead move toward these options:
As an executive, there are a few key points to know:
More often than not, the security controls in a network are not implemented in the way a CISO or compliance officer believes them to be; or perhaps they're just not implemented in alignment with how security is described on paper through policies or compliance attestations. This book is one of the many ways I'm pursuing the lofty goal of better aligning security and networking, and my hope is that it arms technologists and executives with the information to make better informed security decisions.
This content is filled with concepts, examples, and guidance for building a secure wireless architecture. One representative topic is that of migrating from legacy WPA2 generation security to new WPA3. What the architect has learned is that the journey to WPA3 is not straightforward, and the opportunity for invalidating all the enhancements of WPA3 with a poor transition strategy is high. They've also learned the network security posture depends heavily on the organization's ability to update, upgrade, or replace endpoints that don't support the new standards.
Following are a few thoughts for consideration by executives as it relates to the overall security posture of the network:
The practitioners out there may harangue me for this, but it's a topic that warrants discussion. Many organizations lack visibility and control of their IT teams exercising privileged access including remote access.
Network engineers, admins, and architects often have the keys to the kingdom when it comes to privileged access. Depending on the size of the organization, they likely have unrestricted management access to wired and wireless network devices including routers, domain and application servers, virtual hosts, user directories, and even firewalls.
In addition to their own access, they often extend management access to third parties including the vendor field and support teams, integrators, and other consultants.
Logon credentials are often shared among teams, stored in personal password managers, or even shared via spreadsheets or text documents without any encryption. Many technologists use their own applications for managing connectivity, such as personalized terminal services, which also have local (and unmanaged) credential storage.
While none of this behavior is malicious, it does put the business at risk. If your organization doesn't have policies around administrative access, storage and sharing of credentials, and remote privileged access, please consider leading that initiative. If the policies do exist, they should be communicated early and often to IT team members, with an opportunity for them to provide feedback. The goal is to enhance the security posture without inhibiting the professionals' work.
Some recommendations and points to consider include:
Bring your own device (BYOD) and consumerization were hot topics ten years ago, but the pandemic has brought them front-and-center yet again.
With no warning or preparation, supporting a remote workforce was foisted upon companies across the globe. Decommissioned laptops were resurrected; VPN access expanded exponentially; employees were suddenly positioned to use personal devices for work. Security was sacrificed for availability in the name of business continuity.
Many organizations, even those with mature security programs, have found themselves now needing to retroactively address the use of personal devices for corporate access. BYOD is covered in depth in Chapter 8. The guidance for architects is that BYOD is complicated and policies around it aren't for IT to decide; it requires legal and executive guidance.
Here are a few thoughts when considering BYOD policies:
This chapter introduced a planning and design methodology loosely based on borrowed constructs from Design for Six Sigma. The planning entails five phases organized in three stages, which collectively comprise the inputs and outputs of the security architecture.
Discover Stage
Architect Stage
Iterate Stage
It starts with the define phase to scope the project and collect requirements, followed by a characterize phase to refine and map requirements to the discrete design elements (such as client networks, infrastructure hardening) against known security requirements documented in policies or compliance mandates. Together, define and characterize compose the discovery tasks and serve as the inputs for the architect stage.
The output of the planning exercise was described through three additional phases—design, optimize, and validate, which comprise the architect and iterate stages.
The optimize and validate phases are entangled and non-linear, where optimize affords the architect the opportunity to further refine the design plans based on changing or additional inputs, while the validate phase serves as the opportunity to compare the design against the original requirements and validate the objectives are being met.
Instead of presenting a canned approach to planning, the content here continued with actionable templates and guidance for making decisions based on inputs and how those correlate to the outputs.
Sample templates, forms, and tables were provided along with representative data to illustrate the use of the templates.
Finally, the chapter concluded with pointed guidance written for an executive audience who wields the power to help make secure wireless more attainable.