Phase 1: Define

The define phase includes identifying project requirements, elements of scoped environment, and scope limits.

During this time, the architect should perform activities such as:

• Identification of the teams and roles involved in the project
• Discovery of the environment (wired and wireless network infrastructure components, capabilities, and topology)
• Scope of user and endpoint population and capabilities
• Identification of applications to be supported over the wireless network
• Scope of geography/coverage areas (e.g., campus, branch offices, home users)
• Identification of security and compliance requirements
• Discovery of additional supporting policies or guidance for security
• Documentation of discovered items

This exercise of the define stage of discovery is enhanced by the characterize phase, which aligns requirements to the scoped elements.

Phase 2: Characterize

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:

• Identify elements (endpoints, users, infrastructure, or assets) that need specific security controls to meet business objectives or compliance requirements (e.g., network segments in scope of PCI)
• Group and categorize elements with similar needs or characteristics
• Identify and document which scoped elements have requirements dictated by policy or regulation, such as authentication or encryption
• Document requirements for cases requiring elevated controls such as additional monitoring or inspection, security posturing, multi-factor authentication

The define and characterize phases together comprise the discovery tasks and are the inputs to the architecture tasks of design, optimize, and validate.

Phase 3: Design

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:

• Begin mapping defined requirements to planned designs for scoped elements (wired and wireless infrastructure, endpoints)
• Document conditions and variables that may impact the expected outcomes and security posture (such as unknowns of planned but un-scoped projects based on wireless connectivity such as digital transformation or IoT programs, or unknown variables of endpoint support for WPA3, or an upcoming merger or acquisition)
• Evaluate current infrastructure and tools to determine if they can meet the objectives
• Identify vendors, products, and configuration options to meet the security and connectivity objectives
• Define metrics and outputs for monitoring and testing against mapped elements
• Produce documentation for as-built designs of the infrastructure devices

Phase 4: Optimize

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:

• Researching changes in security protocol standards and implementing enhancements in the architecture
• Evaluating new vendor product features for additional security benefits
• Consuming output from validation to further refine the architecture
• Communicating to stakeholders any major changes in guidance for security best practices
• Updating internal standards and process documents to reflect changes as needed

Phase 5: Validate

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:

• Evaluate the planned design against the requirements defined in design and characterize phases
• Document gaps to be addressed in an iterative optimize phase
• Communicate findings to participating teams
• Present findings to stakeholders and request feedback
• Incorporate data from identified metrics in design phase

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.

CISO, Risk, or Compliance Officer

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.

Security Analyst or SOC

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.

Identity and Access Management Team

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

Network Architect and Network Operations Team

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

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.

Help Desk

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.

Other System or Application Owners

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.

Vendors, Integrators, and Other Contractors

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.

Wireless Connection Type

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.

Form Factor

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.

Operating System

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.

Ownership

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.

Management

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.

Location

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.

User-Attached or Not

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.

Roaming Capabilities

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.

Security Capabilities

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.

Quantities

The volume of any class or group of endpoints will help inform requirements for IP address space, segmentation, and options for provisioning.

Classification or Group

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.

Sample Enterprise Requirements Discovery Template

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

• Description

  The description column is just to capture a commonly accepted label or descriptor of the group of endpoints.

• Form factor

  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.

• Estimated quantity

  An estimated quantity is to capture a rough order of magnitude for each type of endpoint.

• Owned by

  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.

• Managed by

  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.

• Access requirements

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

• Capabilities or limitations

  Capturing known capabilities or limitations of endpoints at this stage is helpful in planning network authentication and security profiles.

• Security or other notes

  Inevitably you'll have some notes-to-self, links, or reminders that can go in an ad hoc notes column.

Sample Healthcare Requirements Discovery Template

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.

Defining BYOD in Your Organization

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.

• Allow Personal Devices on the Network but with Internet-only Access If the organization intends to allow personal devices, but only grant Internet access, they usually want to reduce friction for users by not forcing them to re-register through a guest portal daily, or even multiple times a day. Personal devices may be smartphones, tablets, laptops, e-readers and the like, but should not include infrastructure devices such as Wi-Fi routers and switches.

  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.

• Allow Personal Devices on the Network with Some Level of Access to Internal or Protected Resources Alternatively, it may be the intention of the organization for users to use personal devices to access internal resources—internal meaning both on-prem but also protected IaaS and PaaS environments that may be hosted in the cloud.

  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:

• Internet-only BYOD is straightforward and can leverage a modified guest portal for longer-term access if desired.
• Internal access BYOD is more complicated, should be carefully considered, and should include MDM (or similar capability) and connectivity via 802.1X-secured networks.
• Looking forward toward zero trust strategies, even Internet-only BYOD models will have additional controls and likely a dissolvable or persistent agent to enforce security.

Sample Access Rights Planner for NAC

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.

• Device ownership

  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.

• Device type

  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.

• User

  Identifies the condition of what user is logged on to the device, such as a domain user, no user, or guest

• Location, network, or group

  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.

• Access rights

  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.

• Agent or security inspection

  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.

Sample Access Rights Planner for NAC in Higher Education

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.

Sample Simplified Access Rights Planner

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.

Involve Wireless Architects Early to Save Time and Money

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.

Collaboration Is King for Zero Trust and Advanced Security Programs

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.

Stop Planning 1:1 Replacements of APs

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.

Penny Pinching on AP Quantities Sacrifices Security

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:

• Basic wireless coverage and user experience
• Wireless quality including speed
• Roaming experience between APs
• Location services and asset tracking
• Security feature support

Always Include Annual Budget for Training and Tools

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.

Consultants and Third Parties Can Be Invaluable

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.

Wi-Fi Isn't the Only Wireless Technology

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:

• Endpoint types (traditional OS-based, IoT, etc.)
• Application use case and criticality (Wi-Fi may be less desirable for critical and latency-sensitive applications)
• Bandwidth requirements (how much data is being transmitted)
• Battery life and duty cycles of endpoints
• Distance or range of endpoint to AP

Details of these are covered in Chapter 8, and include:

• 802.11 WLANs (Wi-Fi)

  Wi-Fi, for in-building and short-range outdoor applications

• Private cellular 4G/5G LAN

  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

• Low Power WANs (LP-WANs)

  Include LoRa, Sigfox, and modified cellular technology for long-range communication

• Low Rate Wireless Personal Area Networks (LR-WPANs)

  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

The Product Your Peer Organization Uses May Not Work for You

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:

• Size, topology, and distribution of the networked environment
• Size and capabilities of internal teams for ongoing maintenance
• Related projects, technologies, and products within the organization
• Organization's long-term strategic vision
• Network infrastructure products in the environment currently
• Security and compliance requirements
• Budget and preferences of CapEx vs. OpEx spend models

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.

Don't Buy Into Vendor or Analyst Hype

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:

• Some firms rely heavily on academic researchers with no real-world experience; they just opine about the industry.
• Others are defined by ego-driven pundits who are more influenced by the snacks you had at the ready than with your product features.
• Plus, there is a pay-to-play aspect of many analyst reports; although a vendor can't pay for a ranking or position, it stands to reason an analyst will come to fully appreciate the depth of a vendor's offering by spending more time with the product. And there's a cost that accompanies an analyst spending time with the product.

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.

Interoperability Is More Important Now than Ever

“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:

• Seek out products that allow for scalable, open integrations, such as those based on APIs and SAML
• Look for products that have been tested and certified for interoperability such as Wi-Fi Alliance-certified products
• In general, avoid technologies based on closed/licensed standards (as an example Z-Wave was licensed until recently versus Zigbee, which is an open standard)
• Avoid clunky and complex custom integrations that will have to be reworked after even minor updates

Consider PSK Networks to Be the “New WEP”

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:

• WPA3-Personal secured with SAE (SAE is the replacement for PSK)
• WPA2- or WPA3-Enterprise secured with 802.1X/EAP (either is fine, but version 3 brings PMF and is preferred)

As an executive, there are a few key points to know:

• WPA3 is the new version of WPA security suite (replacing WPA2)
• Endpoints must be updated with software, upgraded, or replaced to support WPA3
• For Enterprise mode with 802.1X, both WPA2 and WPA3 are secure and okay to use but WPA3 is more secure
• Improperly configured transition modes that support WPA2-Personal and WPA3-Personal put your network at risk
• This book offers guidance to technical architects to properly design and secure transition-compatible networks

You're Not as Secure as You Think

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:

• New Wi-Fi security standards demand precision and capable endpoints
• Common practices aren't necessarily best practices
• Just because you can't see or monitor something doesn't mean it's not a risk
• Wi-Fi and other wireless including Bluetooth and private cellular require tools for over-the-air and network-based security monitoring
• Gaps and lack of communication about network security policies introduce risk
• Regular assessments and/or penetration tests by third parties are exceptionally helpful in evaluating posture
• K.I.S.S. (keeping it simple) is still king for security; and most environments get so focused on advanced security they miss the simple, basic controls

Get Control of Privileged Access, Especially Remote

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:

• Follow the principle of least privilege when possible
• Train IT teams at all levels/roles on the organization's policies around privileged access
• Provide easy-to-use secure credential vaulting and password management products
• Log and monitor privileged access and accounts
• Ensure devices are configured for user-based access and not shared credentials such as root or admin on shared accounts
• Include guidance for escalations and break glass emergency situations
• Ask for feedback from teams regularly to ensure the tools and policies are working and not being bypassed

Make Sure You've Addressed BYOD

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:

• Along with BYOD there are other ownership-management models including CYOD, COPE, and COBO—choose your own device, corporate-owned personally enabled, and corporate-owned business use only
• Exceptions to BYOD or any network security policies should be approved by a board (security, change management, or other) not an individual person regardless of their status
• BYOD brings many legal implications and should be carefully considered to address data ownership, rights for wiping data, e-discovery, and liability of the organization for personal data
• In zero trust strategies, BYOD models that provide access only to Internet resources should still include protections and visibility related to the access of SaaS, PaaS, and IaaS
• Your BYOD policy on paper should have controls to enforce and/or monitor the behaviors described