Wireless Security Architecture: Designing and Maintaining Secure Wireless for Enterprise

By Jennifer Minella and Stephen Orr

Reduce organizational cybersecurity risk and build comprehensive WiFi, private cellular, and IOT security solutions

Wireless Security Architecture: Designing and Maintaining Secure Wireless for Enterprise offers readers an essential guide to planning, designing, and preserving secure wireless infrastructures. It is a blueprint to a resilient and compliant architecture that responds to regulatory requirements, reduces organizational risk, and conforms to industry best practices. This book emphasizes WiFi security, as well as guidance on private cellular and Internet of Things security.

Readers will discover how to move beyond isolated technical certifications and vendor training and put together a coherent network that responds to contemporary security risks. It offers up-to-date coverage—including data published for the first time—of new WPA3 security, Wi-Fi 6E, zero-trust frameworks, and other emerging trends. It also includes:

• Concrete strategies suitable for organizations of all sizes, from large government agencies to small public and private companies
• Effective technical resources and real-world sample architectures
• Explorations of the relationships between security, wireless, and network elements
• Practical planning templates, guides, and real-world case studies demonstrating application of the included concepts

Perfect for network, wireless, and enterprise security architects, Wireless Security Architecture belongs in the libraries of technical leaders in firms of all sizes and in any industry seeking to build a secure wireless network.

• Language: English
• Publisher: Wiley
• Release date: Mar 7, 2022
• ISBN: 9781119883074

Book preview

Preface

This book was envisioned with the goal of empowering a broad category of network and security professionals to design and maintain secure wireless networks in enterprise environments.

It focuses on the most current and relevant details and offers appropriate background information and explanations that will persist for years, even as technology evolves. This book teaches network, wireless, and security architects how to fish and make ongoing decisions about how best to secure networks.

Wi-Fi-connected devices alone have tripled in the past six years, surpassing 20 billion in 2021. That growth, coupled with the projected 75 billion connected IoT devices by 2025 means network and security teams will be faced with new challenges securely connecting all of these things and protecting enterprise assets from the ones that introduce risk. With wireless connections growing exponentially, security threats increasing, ransomware rampant, and new initiatives like zero trust strategies and digital transformation, yesterday's technologies and techniques aren't sufficient to secure tomorrow's enterprise. And in fact, they're not even adequate to protect us today.

Plus, these new initiatives necessitate tighter integration between network and security disciplines. Cross-functional teams mean greater communication and knowledge sharing, and this book bridges the divide between risk management and network architecture.

This book merges the concepts of enterprise security architecture with wireless networking and teaches professionals how to design, implement, and maintain secure enterprise wireless networks. It covers everything a technology professional needs to know to make sure the organization's wireless matches the organization's risk models and compliance requirements.

Who This Book Is For

The reader is assumed to be an IT or infosec professional with basic networking knowledge (in line with Network+ or Cisco CCNA). Wi-Fi experience, while helpful, is not required. There are portions of the book written for technical and non-technical leadership, summarizing more complex technical recommendations into business requirements.

For organization size, this book is appropriate for security-conscious organizations of all sizes and industries from small schools to universities, healthcare systems, state and local government, commercial enterprise, and even federal agencies. The only requirement being that this content is most relevant for environments using fully managed switches.

Wireless, and especially Wi-Fi, touches so many aspects of the enterprise network, from wired infrastructure to authentication servers, endpoint management, and security monitoring. This book is for you if you are:

Network, wireless, and security architects responsible for designing secure network and wireless infrastructures. You're the primary audience for the book.

IT professionals, network engineers, and system admins interested in learning more about securing wireless. Even if your role isn't architecting, you'll learn a lot about supporting and maintaining secure wireless systems, devices, and users.

Technical leaders with strategic responsibility for network security and security controls compliance. While you may prefer to skip some of the more technical minutia, this book provides valuable insight into what's possible, what's practical, and the complexity of meeting stringent security postures.

Non-technical executive leadership and boards with oversight of risk management. Only portions of this book are appropriate for non-technical audiences, but they provide valuable actionable business-level guidance.

While the vast majority of my own experience has been with clients in the United States, this book addresses the variations in policies and compliance requirements across the globe, and the standards and technologies used are applicable in all parts of the world, with slight variations in implementation such as the RF frequencies, which are localized.

I truly hope this book will spark conversations in the networking and infosec communities, and that each professional will take aspects of this content, make it their own, and further expand the reach of not only the book, but of their own experiences and contributions.

As always, we have done our best to be as complete and accurate as possible, but alas we are human, and errors are to be expected. Although I had amazing technical editors, I accept full responsibility for any errors or omissions, and graciously appreciate any feedback including corrections. If you come across an error, please email [e-mail] with the subject line Possible Book Errata Submission. For other feedback you can contact me on LinkedIn or at [e-mail].

Distinctive Features

This book separates itself from others in many ways. While other books, authors, and publishers of network security topics add valuable content and context, this book offers these unique features:

This book is vendor-neutral, but references vendor-specific features and documentation where applicable to ensure guidance is actionable. Many vendors call the same feature by different names, and that's addressed throughout the book.

Advice throughout this book is based on hundreds of real-world implementations, not academic or theoretical research.

This book addresses current and, at times, relevant future technologies, and anticipated changes.

While other books focus on technical standards and specifications, this book provides an applied how-to approach to use that knowledge in practice.

Unlike many training programs and books, this book seamlessly merges security, risk, and compliance considerations with network architecture at each step.

This book prepares professionals for successfully executing their work, not merely for passing a certification test.

The content is presented in a casual and conversational tone, making it accessible to a wide audience by not relying on niche terminology and acronyms.

Introduction

In business environments, wireless and especially Wi-Fi networks are configured and maintained by a breadth of technology professionals—from Wi-Fi specialists to the sole IT professional left to juggle everything from networking to managing endpoints, applications, and servers. This book brings deep technical details to the seasoned wireless professional and summarizes best practices in easy-to-follow advice for those wearing many hats.

After fifteen years of stale Wi-Fi security suites and a limited focus on IoT security, the world of wireless is finally putting the spotlight on security. But designing secure wireless networks isn't nearly as straightforward as it seems. The newest WPA3 security suite greatly enhances security, but also introduces complexity as organizations move from legacy security to the latest standards.

This book reframes and redefines architecting secure wireless, opposing outdated guidance in favor of more robust security practices meant to address today's and tomorrow's evolving wireless networks. Its contents walk professionals through the decision-making steps of architecting secure networks, starting from risk and compliance considerations to detailed technical configurations. Along the way, it offers practical guidance, best practices, and specific recommendations for a variety of environments, vendor implementations, and security needs.

Overview of the Book and Technology

Securing wireless networks today requires a new way of thinking and a new set of tools. The best tool in the architect's toolbox is knowledge, and that's what this book delivers.

Along with recommendations for designing with best practices, Wireless Security Architecture also offers deep technical journeys into areas of encryption, authentication, authorization, segmentation, certificates, roaming, hardening, and more. Each chapter offers practical guidance along with technical details, empowering professionals to make informed decisions about how best to secure their environments.

One unique aspect of this book is that the full work is presented in a conversational tone, eliminating the rigidity of academic wording that can be a barrier to easy comprehension. Also, all chapters have been written by a single author, and common connected topics are woven and cross-referenced throughout.

This book addresses the full breadth of enterprise wireless products, with a strong focus on Wi-Fi. In it, architecture and security design considerations are offered for:

Controller-managed Wi-Fi

Cloud-managed Wi-Fi

Autonomously managed Wi-Fi

Small, medium, and large environments

Specific manufacturers including Cisco, Aruba, Juniper Mist, and Extreme, among others

Specific industries such as healthcare, government, and education

Non-traditional endpoints and IoT devices

How This Book Is Organized

Wireless Security Architecture is sure to become the definitive guide for designing and maintaining secure wireless networks in any size organization. With content for wireless specialists and technology generalists alike, this book covers deep technical topics with appropriate introductory concepts that will allow non-wireless IT professionals to learn and follow along. And while it includes foundational knowledge, extraneous historical details such as the history of WEP have been deliberately omitted to keep the reader's focus on current technologies.

To remain vendor-neutral, the language used in this book is based on natural language. Where appropriate, in the more technical areas of the book, current vendor terminology and features are called out, allowing readers to easily find and further research topics within the context of their environment. Some vendors' configuration guides exceed 2,000 pages for a single product, and most enterprise Wi-Fi deployments incorporate several integrated solutions for management and monitoring, easily bringing the total to more than 5,000 pages of documentation—which often don't include details on security hardening.

At times, the terminology used may be purposefully deviant from a particular vendor feature name to avoid confusion. As one example, Cisco has a feature called Infrastructure MFP, which is easily confused with (but very different from) the IEEE 802.11w standard for Management Frame Protection (MFP), also known as Protected Management Frames (PMF) by the Wi-Fi Alliance. To avoid confusion, PMF is used when referring to 802.11w.

You may also notice some acronyms are intentionally repeated along with their full text, breaking traditional editorial conventions. Just within wireless, acronyms can be frequently re-used: PSK for example may mean pre-shared key but can also refer to phase-shift keying. Introducing security and IoT disciplines only complicates matters further: in this book SOC could mean security operations center, or system on a chip. To avoid confusion and make the text more accessible to a broad audience, these are often spelled out repeatedly.

The following is a brief summary of each chapter's content. In many cases, the chapters build on one another, adding technical context at each step. Expect to see topics repeated as the book progresses but presented in evolving context along the way. To help readers that may be skipping to specific portions of the book, cross references are included.

Part I, Technical Foundations, introduces technical foundations for the reader and encompasses Chapters 1–4.

Chapter 1, Introduction to Concepts and Relationships, is a level-set to get diverse professionals on the same page with foundational concepts of information security, high-level technical concepts that impact security, and an overview of wireless technologies and architectures. This chapter sets the tone by defining identity, authentication, and offering an entry to cryptography concepts.

The first technical content, Chapter 2, Understanding Technical Elements, provides the underpinning of all content that follows with a deeper dive into data paths, segmentation methodologies, and the first dive into security profiles for Wi-Fi including the new WPA3 security suite.

Chapter 3, Understanding Authentication and Authorization, is filled with every detail a professional ever wanted to know about authentication and authorization, including 802.1X, EAP, RADIUS, certificates, and MAC-based authentications.

Rounding out Part I, Chapter 4, Understanding Domain and Wi-Fi Design Impacts, explains the symbiotic relationship of secure wireless architecture to network design elements and RF planning, with a strong focus on secure roaming protocols.

In Part II, Putting It All Together, the reader is taken on the journey of planning the network and security architecture based on technical concepts from Part I.

Chapter 5, Planning and Design for Secure Wireless, walks the reader through the author's own design methodology for planning secure wireless. It includes pointed questions to ask during scoping, and several planning templates and worksheets for the reader to use or modify—including complex policy matrices as well as simplified planners.

Hardening the infrastructure is the focus of Chapter 6, Hardening the Wireless Infrastructure, with extensive guidance, tiered recommendations, and relevant vendor-specific sidebars.

Part III, Ongoing Maintenance and Beyond, picks up where planning and design of Parts I and II left off.

Chapter 7, Monitoring and Maintenance of Wireless Networks, addresses monitoring and maintenance of wireless networks including pen testing and audits, along with ongoing management with WIPS, and specific recommendations for logging, alerting, and reporting. As an added bonus, troubleshooting tips are included here as well.

Chapter 8, Emergent Trends and Non-Wi-Fi Wireless, segues into the less evergreen topics, covering the more variable technologies of IoT and emergent trends such as remote workforces, BYOD, and zero trust.

The appendices present four topic areas, starting with Appendix A, Notes on Configuring 802.1X with Microsoft NPS. Appendix B, Additional Resources, offers hints on navigating IETF and IEEE documents, and Appendix C, Sample Architectures, includes the much-requested examples of secure wireless architectures. A few niche topics are covered in Appendix D, Parting Thoughts and Call to Action.

Why Read This Book

This book delivers insightful knowledge based on hundreds of real-world implementations and aggregates data and recommendations from thousands of pages of standards, vendor documents, and best practices white papers.

Offering a blend of relevant technical details alongside summarized best practices, the book offers advice within the context of a flexible framework that allows network and security architects to adapt and layer concepts as needed to meet their needs.

Whether you're a Wi-Fi professional, network admin, security architect, or anything in between—this book will be your go-to resource for planning and maintaining secure wireless networks.

What's on the Website

In addition to the material provided in the book, additional and updated supplemental materials such as downloadable planning templates and cheat sheets can be found online at the books' website www.securityuncorked.com/books.

The contents of Chapter 5's section Notes for Technical and Executive Leadership are also made available to download and share. Our hope is this messaging will empower you to further negotiate within your organization and create allies with non-technical stakeholders.

Congratulations

On behalf of the author, technical editors, and the Wiley team, we appreciate the opportunity to share this body of work with the technology community at large, and hope you find it a useful tool for helping to make our world a safer place.

Oh, and one last note. We may be technologists, but we're all still just human. Don't be afraid to ask questions, ever. If this book teaches you nothing else, it should demonstrate the complexity and breadth of information technology. Asking what an acronym means, how a technology works, or how something is done when you don't know is the only way to learn, grow, and share.

Part I

Technical Foundations

In This Part

Chapter 1: Introduction to Concepts and Relationships

Chapter 2: Understanding Technical Elements

Chapter 3: Understanding Authentication and Authorization

Chapter 4: Understanding Domain and Wi-Fi Design Impacts

CHAPTER 1

Introduction to Concepts and Relationships

Before we dive in to the how-to, I want to introduce some concepts at a high level and explain the relationships among them so there's at least a baseline context moving through the subsequent chapters.

The overview here will look at the roles and responsibilities of the various technical teams involved in wireless architecture and security, then touch on basic security concepts that will be referenced throughout this book, and after that will cover some key foundational wireless concepts.

Since this book is written for a variety of technology professionals, some of you will have deep knowledge in one or more areas, and others may be looking to fill some gaps. The following sections serve to get us all on the same level of understanding and taxonomy, so we have a common starting point for the architecture conversations that follow.

NOTE While this chapter introduces concepts that will be referenced in the context of wireless security, the terms and constructs here transcend wireless or even network security topics. I've purposefully avoided confounding textbook-style definitions and tried to maintain a focus on the application of the definitions within the scope of this book's content.

First, we'll look at the roles and responsibilities of various people and teams within the organization, how they may relate to your wireless security architecture, and what to do if that person or role is nonexistent in your organization. After that is an introduction to basic security concepts relevant to wireless security and an explanation of each specifically in the context of wireless security (vs. diving into lengthy definitions). Finally, we'll cover a few foundational wireless concepts that will impact your architecture, since we're not assuming everyone reading this book has deep (or possibly any) enterprise wireless experience.

This chapter covers an introduction to concepts and relationships organized in three parts:

Roles and Responsibilities

Security Concepts

Wireless Concepts

Roles and Responsibilities

Organizations of different sizes, industries, and security profiles will have different types of teams and resources. This discussion of roles and responsibilities will help outline some common titles and roles within an organization to provide context of how these different people and teams interact throughout the secure wireless planning and implementation. Also, this section should help you identify areas and roles for which your organization may not have specific people assigned. Whether officially or unofficially, where there is a role absent in the organization, there's an opportunity (and expectation) for you or your team to fill those gaps (yourself or with help from other teams or third parties).

As an example, in its purest form some might say this book is written for people with the title of enterprise security architect. However, many organizations don't have a single person or team dedicated to this task, in which case you as a network or wireless architect have an opportunity to use the guidance here to fill some of that void. With each section there's an explanation of how to engage with the various roles, and some tips and tricks for navigating the organization.

Network and Wireless Architects

We'll start with covering the roles and responsibilities of network and wireless architects since it's likely most readers will identify most closely with this area of expertise.

Depending on the size of the organization, the wired and wireless teams may be the same, or may be different groups or people. For purposes of brevity, network and wireless architects will be discussed as simply network architects for this section. Aside from LAN networking and Wi-Fi professionals, organizations are likely to have specialists for other networking specialties such as datacenter, WAN, and cloud—all of which we'll consider lumped into the networking category here.

The role of the network architect is to design the systems, interactions, and integrations that provide the appropriate connectivity, availability, quality of service, and security for an organization's networked communications. Typically, the network architect will participate in or define requirements for configurations and specify or recommend products to meet the objectives.

The network architect and (if existent) the enterprise security architect (or teams) should work together to define the wireless architectures covered in this book and specifically to ensure the security controls (including policies/procedures, configurations, and monitoring) are in line with the organization's risk management strategy. In the absence of the enterprise security architect, the majority of work described here will fall to the network architect, with input from other security resources.

SIZING IT UP: IDENTIFYING WHO HAS WHAT ROLE

In large organizations, once a system is in place the organization may rely on different teams with operations, engineering, and system admin roles to manage the daily operations and maintenance of the systems that were defined and designed by the architect. Of course, in small organizations it is quite likely the network architect, network admin, wireless professional, and help desk escalation contact may be one person or a small team.

Security, Risk, and Compliance Roles

Discussing the roles of the various security, risk, and compliance resources gets a bit dodgy since only the most mature organizations will have these roles well defined. Having said that, almost every organization should have someone responsible for making decisions about the organization's risk tolerance. Risk tolerance may not be well defined and may be more qualitative than quantitative, but there will be a risk manager, a Chief Information Security Officer (CISO), a compliance officer, a board of directors, and if nothing else—an owner who cares and makes decisions about risk tolerance.

Risk and Compliance Roles

In many organizations, and specifically any organization that falls under industry or governmental regulation, there will be a risk and/or compliance officer. This person or team is responsible for ensuring the organization adheres to any regulatory requirements. They'll be accountable for audits, documenting policies and processes, and ensuring compliance.

For example, in healthcare there will always be someone responsible for managing compliance with the Health Insurance Portability and Accountability Act (HIPAA). In regulated power and utilities organizations, someone is responsible for North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) compliance. Organizations processing certain volumes of credit card transactions will have someone responsible for Payment Card Industry Data Security Standard (PCI DSS) compliance. There are similar risk and compliance requirements covering IT systems for manufacturing, pharmaceuticals, and any organization working with the US federal government, such as requirements for the Defense Federal Acquisition Regulation Supplement (DFARS) and Cybersecurity Maturity Model Certification (CMMC), and the list goes on. Some of these regulations will require the organization to designate a person responsible for that compliance program, while others may simply require specific reporting and auditing.

As it relates to our wireless security architecture, the risk and compliance requirements will be a primary driver in dictating certain documented policies, product configurations, monitoring, and mitigation of risks. Note that in many industries, the risk and compliance officer likely resides outside of the IT organization and therefore may not be our first hop toward getting risk information. If there's a CISO or similar title or office, that person or group will be intimately familiar with the organization's compliance requirements and will have the added benefit of some familiarity with information technology. We'll talk about the CISO role next since that's a likely starting point for risk conversations.

Chief Information Security Officer Roles

The role of the CISO may be covered in a different title. First let's set the expectation that the reporting structure of a CISO role and the expertise of that professional will vary wildly from organization to organization. While in many instances, the CISO or Chief Security Office (CSO) will report to a Chief Information Officer (CIO) or Chief Technology Officer (CTO), sometimes the CISO may report directly to the Chief Executive Officer (CEO), other executive leadership, or even to a board of directors. In other cases, the CISO role may even be a dual responsibility of a CIO, CTO, or other technical leadership.

To add to that complexity, the role of the CISO is not always defined consistently across organizations, and therefore the expectations of that person's skills and experience may vary greatly. Some CISOs will have a technical background, while others a governance, risk, and compliance (GRC) background. I've worked with clients whose CISO was a web developer two years prior, and I've worked with clients whose CISO ran a full security practice with exceptional risk management maturity.

This is worth noting because if we're relying on the CISO (or similar security professional) to help us in our endeavor, we need to understand what to ask for, and what to expect in terms of a response.

If there is a CISO (or similar role) in your organization, start there. Ask about the organization's risk framework, and specifically what policies and compliance requirements you need to consider as it relates to network security architecture and wireless connectivity. We'll cover this more in depth throughout the topics under Security Concepts for Wireless Architecture later in this chapter, but for context, the answers will likely include requirements for specific encryption, device inventory and management, hardening the systems, and segmentation, among other things.

If there isn't a CISO available to you, or if the CISO is not equipped with the answers to your questions, the risk and compliance person should be your next stop for answers. If that's how you get your answers, you may have a bit more work to do—something we'll cover in the section Considering Compliance and Regulatory Requirements.

Security Operations and Analyst Roles

Depending on the organization, security operations and the roles of technical security professionals can range from security analysts in mature security operations centers (SOC) to the person designated to monitor firewall logs. Because of that, there will be expected inconsistencies in how we interact with security teams while planning our architecture.

In general, the security operations and analyst teams are responsible for managing the security tools, and more specifically, they're responsible for monitoring the infrastructure for security including vulnerability management as well as incident detection and response. These teams have tools and workflows that ingest logs and configuration files, help identify indicators of compromise, prioritize patching based on risk, and generally monitor for and investigate potential incidents. If your organization has a SOC team, they'd be the ones managing the logging and event correlation, with tools such as security information and event management (SIEM), security orchestration, automation, and response (SOAR), and any detection and response tools such as endpoint detection and response (EDR) or the newer extended detection and response (XDR) platforms, which encompass more than just endpoints. The SOC and analyst teams would also be responsible for forensics as part of incident response handling.

For your secure wireless architecture, you'll want to talk to the security team to understand what they need to monitor the wireless infrastructure, how they're connecting to and monitoring key components such as endpoints and wireless APs, controllers, and your wireless-specific security tools such as wireless intrusion prevention systems (WIPS). This team is also involved in determining how to identify incidents, how to manage threats/vulnerabilities, defining what constitutes an incident, and how to respond to and mitigate any attacks. The SOC team, likely responsible for vulnerability management, should also communicate with you about patching the wireless infrastructure to address security vulnerabilities as they're discovered.

SIZING IT UP: YOUR ROLE WITH AND WITHOUT A SOC

As noted, the capabilities and responsibilities of the security operations and analyst teams can vary greatly. Large, highly regulated, or very mature organizations will most likely have a full SOC practice either internally or with a managed service platform such as a managed detection and response (MDR) provider. Due to regulatory requirements, these organizations likely have well-defined practices for everything security-related including patching and vulnerability management as well as security monitoring and incident response. These teams will be a great resource to the network architect in planning security for wireless.

However, many organizations don't have experienced security analysts, SOC infrastructures, or well-defined security processes. In many cases, the only technical resource with a security title may be a firewall or other system administrator. If that's the case, you'll have a bit of extra work to do to ensure your architecture has robust security throughout the system's life cycle. You may get a bit of relief and help if you have a mature network operations center (NOC) team at your disposal, which we'll cover next.

Identity and Access Management Roles

Identity and access management (IAM) teams dole out the access rights for users and digital identities such as non-person entities (NPEs), controlling access to data, applications, and other resources.

The IAM group has principal responsibility for account and identity life cycles including provisioning, authorization, maintenance, governance, and deprovisioning. As such, the group will most likely be responsible for access policies and processes around users and endpoints accessing the network.

It's also possible a different team may be responsible for subsets of users or endpoints—such as in healthcare where clinical engineering groups have ownership of the biomedical device life cycle, or digital transformation teams that may be responsible for managing Internet of Things (IoT) devices. It's common also for organizations with operational technology (OT) teams for that group to have express ownership of those systems, sometimes completely outside the visibility of IT teams.

Operations and Help Desk Roles

If you're reading this book, then you probably already have an intimate level of familiarity with network operations and user support structures. You've probably been a technical escalation point, and you may even have served in on-call rotations for after-hours support. We'll forego the 101-level overview and jump straight to how operations and help desk are related to your wireless security architecture.

Network Operations Teams

Network operations encompasses all the tactical daily care and feeding of the network infrastructure. Depending on the products deployed, the tools, and the team skillsets, they may or may not be monitoring and managing wired and wireless together. This team or toolset will usually manage uptime, configurations, software updates, and basic monitoring of the systems—for example, bandwidth and resource utilization. This is another area in which you likely have expertise directly or indirectly, so we'll skip the formalities beyond that overview.

The network operations team, if one exists aside from you, is a resource for you to collaborate with to ensure the wireless infrastructure is being monitored and managed in a way consistent with your expectations as the architect, with the business's expectations of security, and with the uptime service level agreements (SLAs), if any, set by management.

Some organizations have blurred the lines between network and security operations (NOC and SOC), and in fact in many cases, the NOC team has SOC-like responsibilities for some degree of security monitoring and response. They're likely managing some type of logging and may also have SIEM-like tools. If that's the case, then you'll work with the NOC team also for the vulnerability management (patching) and security monitoring.

Help Desk and End-User Support Roles

The help desk and end-user support teams have a thankless and often overlooked area of responsibility but play a critical role in maintaining secure environments.

With any technology, there will be problems, and with wireless now considered a critical business resource, uptime and availability of the system is top priority for organizations. As it relates to your wireless security architecture, you'll want to ensure the procedures for troubleshooting, workarounds, and end-user assistance fall within the accepted security practices you'll be identifying (or defining) in later sections.

External and Third Parties

Another often-overlooked area in security architecture is the role of external and third-party entities. This could entail everyone and everything from the wireless product manufacturer to your integrator or consultant, to the sources of your threat intel feeds.

Technology Manufacturers and Integrators

Between the product manufacturers' field teams (including the field systems engineer you work with) and the manufacturers' technical assistance centers (TACs) or support teams, as well as your integrator—you may have a lot of hands in your wireless network pot as it were. These should all be considered as valuable resources during the planning of your secure wireless, and can have input and offer assistance through upgrades, architecture changes, and support escalations. They are also a point of security vulnerability to consider and manage.

With more platforms moving to cloud-managed or cloud-monitored models, understanding who has access to your environment and to what degree is a crucial part of your security architecture. Often manufacturers have built-in backdoors for support or product development teams. You may have temporarily granted access to a support engineer or other field SE helping you with a support case. Identifying, tracking, and monitoring these privileges should be on your to-do list. As part of a longer-term strategy if there is an ongoing need, you may want to consider a secure privileged remote access (PRA) solution. In fact, it's very likely your organization already has a vendor management program or at least a PRA tool in place that you could piggyback on.

Vendor Management and Supply Chain Security Considerations

Your organization may have (or may soon have) more stringent supply chain and vendor management policies that may dictate how and when you're able to interact with and exchange information with vendors, and how you source and procure technology systems, usually including anything that stores or transmits data.

This is an important shift from traditional business operations where IT teams have been permitted to procure items however they wanted, and/or to allow remote access to various partners or TAC engineers. It's valuable to understand the organization's expectations up front and have any formal vetting done before there's an emergency or outage and you're stuck in paperwork hell or red tape in the midst of chaos.

Depending on the size of the organization, the vendor management process can be as simple as a requisition and single form to a full vetting by a third party who evaluates the risk posture of the vendor. Vendor management and supply chain policies are typically communicated down the chain from leadership, and in the absence of this you can proactively reach out to your manager, the CISO, or risk and compliance officer—probably in that order.

During the process of vetting vendor solutions from a technical perspective, there is a great opportunity for a network or security architect to participate. Their own security architecture should be assessed, either by requesting findings from a reputable audit framework such as System and Organization Controls 2 (SOC 2) or through direct testing.

Security Concepts for Wireless Architecture

This section covers foundational concepts in the domains of both security and wireless networking. Again, the purpose is to get us all to an even playing field with concepts and taxonomy before we dive into the architecture sections.

For the hard-core networking and wireless professionals, I understand some of these topics may seem mundane and not relevant to your objectives, but I promise great results if you stick through this section. This lays the groundwork for communicating everything you do in your architecture in terms of business objectives and risk, which puts you at a great advantage. It also provides a structure for organizing the threats and vulnerabilities in wireless you're already familiar with to a common nomenclature and model understood by other parts of the organization.

For the non-wireless professionals, the wireless architecture concepts covered here will give you greater insight into the parts of today's Wi-Fi solutions and context of how they're related. In later sections, we dive into more technical concepts and then into the architecture design itself.

The following sections in this chapter only serve to offer some preliminary perspectives of the relationships of various elements so you have a rough mental model before we get into the details. In them, we define integrity, availability, and confidentiality and describe them in the context of protecting your wireless infrastructures; then go on to describe how to get started with aligning your architecture to the organization's compliance and security requirements, based on risk tolerance. After that is a short tour through policies, standards, and procedures, followed by segmentation and then authentication concepts and the high-level view of their relationship to wireless security.

Security and IAC Triad in Wireless

Integrity, availability, and confidentiality (IAC) is the holy trinity of all things security. As much as I hate to even beat this drum, the truth is that everything we're going to do in our wireless architecture should (and does) map back to one or more elements of this trio. If you want to dive further into security concepts relevant for system engineering, you'll find resources later in the book. For now, let's just look at how integrity, availability, and confidentiality play a role in our planning; you're going to get my non-textbook definition of these words. See Figure 1.1.

By the way, if you're wondering why this isn't presented as CIA instead of IAC, I invite you to give a security presentation in the presence of government and academia outside the US. I made that mistake only once and decided the IAC acronym would raise fewer eyebrows.

Schematic illustration of the elements of integrity, availability, and confidentiality are pervasive in secure network architectures

Figure 1.1: Elements of integrity, availability, and confidentiality are pervasive in secure network architectures

(Source: https://falcongaze.com/en/pressroom/publications/articles/cia-triad.html)

Integrity in Secure Wireless Architecture

Integrity in security has to do with the validity or trustworthiness of the data. In this case, data may mean the wireless controller configuration, or it may mean the authenticity that the software updates we're getting from the manufacturer aren't tampered with. When it comes to wireless communications, integrity also has to do with assurance that each entity—each user, device, server, or controller—is who it says it is, and hasn't been spoofed or tampered with in any way. It also covers non-repudiation as an offshoot of that.

Some examples of integrity in network architecture include:

Verifying the integrity of software packages to ensure they were not tampered with, often by comparing hashes or validating certificates

Authenticating a server to an endpoint or vice versa to prove identity

Building a trusted infrastructure where only known APs are adopted and provisioned, with the ability to detect rogue APs

Implementing mechanisms that prevent device spoofing, including MAC spoofing

Using Protected Management Frames (PMF) between wireless infrastructure and endpoints

Enforcing change management processes and controlling management access to network devices to prevent tampering or unauthorized changes

For example, when a RADIUS server authenticates itself to a client with a server certificate, that is enforcing integrity. Following on from that the key exchanges and encryption would be an example of confidentiality, which we'll get to shortly. Chapter 3, Understanding Authentication and Authorization, covers authentication and authorization, including RADIUS in great detail.

Availability in Secure Wireless Architecture

Availability is as straightforward as it sounds—it's making the system or data available to the users or devices that need it. In networking, uptime is a great measurement of availability at the most basic level. As it pertains to our architecture designs, availability also factors into general resiliency, how we manage high availability across the system, and the accessibility of the resources as defined by the business requirements.

Some examples of availability in network architecture include:

Detection and mitigation of denial-of-service (DoS) attacks over the air

High availability and failover configurations for controllers

A proper wireless RF design with appropriate coverage and signal quality

Overlapping AP coverage and settings for dynamic power and channel settings

Redundant cable connections and power supplies for supporting wired infrastructure

Appropriate security and segmentation controls to allow users or devices access

Confidentiality in Secure Wireless Architecture

Confidentiality covers protecting data and systems, ensuring sensitive data remains inaccessible from unauthorized or unintended parties, primarily through the use of encryption and secure mutual authentication. With data privacy laws growing by the day, confidentiality is a central element of many compliance requirements, as you'll see later.

Some examples of confidentiality in network architecture include:

Secure key exchanges and encryption of client data with 802.1X-secured networks

Encryption of user traffic between an AP and controller or gateway

Secure authentication for accessing protected resources

Use of Protected Management Frames (PMF) in Wi-Fi

Proper segmentation of networks

As we get into sections mapping compliance and regulatory requirements, you'll see integrity, availability, and confidentiality are common threads that manifest in various requirements for our wireless security architecture.

Using the IAC Triad to Your Advantage

An important thing to note for network and wireless architects is that these three concepts in the IAC triad can be used to your advantage to justify just about anything you need in your infrastructure designs. As you see, even if a need doesn't strictly fall in what you may classify as security, many requests can be justified in the name of integrity or availability.

I can't emphasize enough the importance the business has placed on wireless connectivity and uptime. Network connectivity is considered a critical business resource just like power and phone services. You can use this to your advantage and justify your requests in these business terms throughout your projects—including requesting additional tools, switching products or manufacturers, budgeting for upgrades, and (as you'll see later) for requesting professional development in the form of training or conferences. Just some of the items that support the security triad include tools used for testing, analysis, and monitoring of the wired and wireless networks.

Now that we have some context of what integrity, availability, and confidentiality mean in the real world, let's look at how we use these concepts to align our wireless architecture to organizational risk.

Aligning Wireless Architecture Security to Organizational Risk

The primary objective of our secure wireless infrastructure is to design our systems in a way that is aligned with the organization's risk tolerance. That's easier said than done, and there are entire books written on this topic, so I'll refrain from a deep dive. The pertinent points here are to identify and understand whether you're designing a wireless infrastructure for a high, medium, or low risk tolerance organization, and then understand how your configuration options and designs play into that model.

Identifying Risk Tolerance

Identifying risk tolerance is another task in which your resources may vary greatly; you may have very specific guidance from your organization about their risk tolerance and a specific risk model to work from, or you may have nothing other than gut feelings and qualitative data. In the absence of specific guidance from your organization about the risk tolerance, you can move along with two inputs you can identify yourself—factors that influence risk tolerance, and a basic risk classification based on that.

Factors Influencing Risk Tolerance

Factors that influence risk tolerance include compliance requirements (covered next), privacy risk, security threats, classification of data or assets (how valuable they are), and corporate culture. Here are some questions to consider:

Does the organization or portions of the organization fall under compliance regulations such as PCI, GDPR, HIPAA, NER CIP, FedRAMP, etc.?

In the networked environments, is there personally identifiable information (PII) that requires special protection? Note that PII is defined differently not only by country but even by state within the United States.

Are there current security threats that are relevant to the scoped environment, target assets, or industry?

Has the organization classified data in the environment and were there high-value assets identified such as PII or intellectual property (IP)?

Does the executive leadership or general culture in the organization seem to prioritize security and privacy?

If you answered yes to any of these questions, you could safely assume the organization has a low to moderate risk tolerance, which we'll cover next.

Assigning a Risk Tolerance Level

With the preceding information and your knowledge of the environment, you can probably prescribe a risk tolerance level. These levels may apply to the entire organization, or they may apply to specific network segments. When we get into the architecture design, we'll talk about the security profiles for SSIDs in terms of a low, moderate, or high risk tolerance—or conversely a high, medium, or low sensitivity.

High Risk Tolerance High risk tolerance means an organization is willing and able to accept a higher level of risk for more operational flexibility. This is not a highly regulated environment, and the organization doesn't have compliance requirements or contractual relationships that demand strong security controls or processes.

Moderate Risk Tolerance Moderate risk tolerance means an organization has identified assets that need to be protected, likely has some compliance or reporting requirements, but affords some flexibility in trade-off with security controls.

Low Risk Tolerance Low risk tolerance applies to organizations that are in highly regulated industries such as finance, healthcare, utilities, and many federal government agencies. These organizations prioritize security over most everything else, other than requisite business operations. Figure 1.2 demonstrates the inverse relationship of an organization's risk tolerance to its security requirements.

Schematic illustration of the security requirements increase, risk tolerance decreases, and vice versa

Figure 1.2: As security requirements increase, risk tolerance decreases, and vice versa

As with everything in life, there are trade-offs when it comes to security. As security controls are increased, the related risk level decreases—but on the flip side, a reduction of risk as it relates to information security may cause an increase in opportunity loss and decrease in competitive advantage.

For example, when a hotel has a mobile app for online booking, it has surely increased its risk exposure and introduced more attack surface, but it would be at a huge competitive disadvantage if the only way guests could book was by calling. As a more relevant example to our tasks, it's more secure for an organization to determine it's not going to allow wireless connectivity to any of its networks, but it would again be a huge impediment to innovation and put the organization at a strategic disadvantage.

Along with external considerations, the impact of increased security on internal operations should also be considered. Additional security controls—especially ones that impact end users such as multi-factor authentication (MFA)—bring with them additional operational overhead and a general increase in friction for both users and IT teams.

The take-away is that organizations aren't aiming for zero risk. Instead, their goal is to identify and quantify risk and create an environment that allows the flexibility of competitive operations and digital transformation, while operating within the defined level of tolerated risk.

SIZING IT UP: IT AND ENTERPRISE RISK MANAGEMENT

Large and highly regulated organizations will have robust and mature risk management programs. An enterprise risk management program tracks not only information security and IT risks, but also general business risks such as reputational risks from bad press, and human resource and loss of life risks as well.

Considering Compliance and Regulatory Requirements

The first major undertaking in wireless security architecture will be to identify and then map designs to any compliance requirements that need to be met. If you've followed along in the chapter, you know to hunt down the CISO, risk, or compliance officer to get started. If you don't have any resources to guide you on compliance requirements, don't worry—the architectures and templates provided in this book will make sure you're following best practices.

The bad news is there are myriad compliance regulations and controls frameworks to track against. The good news is, for network security, a lot of the requirements are consistent across the various frameworks. Because there are so many, we're not going to cover them all here. Instead, we'll look at a few key examples of the controls we need to implement, and then in Chapter 5, Planning and Design for Secure Wireless, you'll get specific guidance with examples that will cover the majority of your use cases and specific recommendations for the various risk tolerance levels.

Compliance Regulations, Frameworks, and Audits

As you're working through the process, there are two terms you'll see throughout the book that might be easily conflated if you don't work in information security: compliance regulations and frameworks.

Cybersecurity compliance regulations are the rules or laws from industry or government that prescribe specific (usually auditable) requirements for an organization as it relates to its information security program. Common compliance regulations include programs such as PCI DSS for protecting payment card data, HIPAA for protecting patient health data, Europe's General Data Protection Regulation (GDPR), the California Consumer Protection Act (CCPA), the US government's Cybersecurity Maturity Model Certification (CMMC), and the list goes on. The compliance regulations are requisite and prescriptive to varying degrees.

Many of these regulatory standards are audited—you've probably heard of PCI DSS Qualified Security Assessors (QSAs) that assess and report on the organization's posture against those requirements. And for CMMC there are Certified CMMC Assessors (CCAs). Other regulations, like HIPAA, may not be audited formally, but there could be hefty fines and consequences for an organization that is found to be in violation. Many companies in the US also use SOC 2 Type II audits, which are performed by accredited auditing firms, to show adherence to one or more of Trust Services Principles—Security, Privacy, Confidentiality, Processing Integrity, and Availability. In the EU and other parts of the world, ISO 27001 and other ISO 27000-series audits may be used to certify their security programs.

Frameworks come in many flavors. There are frameworks for risk management, compliance, and controls as a few examples. Frameworks give us a common language to define and describe security controls and posture. Most of the frameworks we reference in enterprise security architecture are cybersecurity frameworks that describe or rate the maturity of security-related policies, processes, or controls.

We'll touch on policies and processes in a bit. Examples of cybersecurity frameworks include National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) as well as its more robust NIST SP 800-series, International Organization for Standardization's ISO 27001 and ISO 27002, Center for Internet Security (CIS) Controls, and HITRUST Cybersecurity Framework (CSF) for healthcare. Many of these compliance regulations will map to one or more frameworks. Some frameworks are also auditable, but most of the time in our role of doing enterprise security architecture, we're simply focusing on a subset of the controls that describe how we configure, manage, and monitor the network system for security.

Cybersecurity frameworks establish the minimum requirements for an organization to:

Not be considered negligent with reasonable expectations for security and privacy

Comply with applicable laws, regulations, and contracts

Implement the proper controls to secure your systems, applications, and processes from reasonable threats

Whether we're talking about compliance or a framework, or both, they're going to dictate certain aspects of our designs, such as:

The cryptographic strength of algorithms we need to use

How and when we need to authenticate users or devices

How and when to segment networks or apply role- or attribute-based access controls (RBAC/ABAC)

How to harden the management access to infrastructure devices

How to enforce auditable management access with logging

Direction on maintaining system inventory including endpoints, infrastructure, and applications

Policies and processes related to accessing resources and assets

Policies and processes for vulnerability and change management

Policies and processes for security monitoring and response

The world of compliance and frameworks is complicated and twisty. If you're working with the CISO or risk and compliance officer, you'll have some great resources already. Otherwise, don't get bogged down in too much detail here and just know that at times people may refer to compliance requirements. For the purposes of this book, the architecture design guidance is mostly aligned with guidance in the various controls frameworks, which can then be mapped to the compliance line items.

The Role of Policies, Standards, and Procedures

As technologists, we tend to throw around the word policy loosely when describing the rules of what users and systems are allowed to do within the organization. The more accurate depiction is an interrelated hierarchy, with policies living outside of our purview. When we say policy in this context we mean some blend of standards and procedures, as defined next and demonstrated in Figure 1.3. In this hierarchy, there are also guidelines that serve as more of an FYI with general statements and recommendations that complement the more formal structure. For our purposes, we're not covering guidelines and we'll instead focus on the hierarchy of policies, standards, and procedures.

NOTE Network and security administrators will of course recognize the phrase policy as a common component of access rights such as those in firewalls and access lists. Just to clarify and distinguish the two: here it's meant as organizational policies, not technical control policies.

A NOTE ON POLICIES

This overview is for informational purposes only to help guide conversations you may have with security, risk, and compliance professionals who use this model. In daily use, it's both common and acceptable within the IT community to refer to the collection of formal policies, standards, and procedures as simply policies.

Schematic illustration of the hierarchy of policies, standards, and procedures, one broad policy may have multiple standards and procedures to meet the policy objective

Figure 1.3: In the hierarchy of policies, standards, and procedures, one broad policy may have multiple standards and procedures to meet the policy objective

Policies

Policies are high-level statements from executive leadership, and they ultimately speak to expectations of the security.

Policies:

Focus on desired results, not on means of implementation

Are further defined by standards, procedures, and guidelines

Require compliance by users and outline consequences if they fail to comply

Change rarely and are meant to be more evergreen than the more detailed standards and procedures

Standards

Standards define a mandatory action designed to support the policy requirements. They're specific to an area of practice, technology, or system but are not as granular as procedures.

Standards:

Define models or methodologies required to meet policy objectives

Specify the mechanisms and application of controls without defining the discrete steps

Can be platform-specific and may include secure baseline configurations

Will change over time as product features and industry standards evolve

Procedures

Procedures (also called processes) document the operational steps necessary to implement the policy.

Procedures:

Describe who does what, when, how, and under what conditions

Include a series of steps and instructions

Are specific to systems and platforms

Change frequently as products are updated, techniques are improved, or new information is learned

Example with Wireless Security

Here's an example of the hierarchy using wireless security. The relationship is represented in Figure 1.4, as well.

Policy The organization will allow managed devices to connect to network resources including the wireless network. The managed devices should be permitted to connect only if both the device and the user are authenticated, and the connection must be encrypted.

Standard Internal secured SSIDs will be configured as minimum WPA2-Enterprise with 802.1X authentication with Microsoft PEAP-MSCHAPv2 or EAP-TLS. Managed client machines may be authenticated via the directory structure or machine certificate. Users will be authenticated by Microsoft login credentials. The encryption must be minimum of AES 256.

Procedure Includes a description of who does the work (e.g., an authorized network admin) and the exact steps of what they will do, such as the step-by-step instructions for logging in to the wireless controllers and configuring ACME-Corp SSID to be a 802.1X-secured network, and the steps to configure connection to the authentication server, as well as configuring a policy that requires machine and user authentication, selects the options in the menus for proper supported EAP methods as described in the standard, and the steps and checklist for configuration of any supporting infrastructure, network services, and endpoint configuration.

Snapshot shows recap of the intent and relationship of policies, standards, and procedures

Figure 1.4: Recap of the intent and relationship of policies, standards, and procedures

Segmentation Concepts

Segmentation plays a critical role in securing networks, including and especially wireless networks. Whether we're talking about standard 802.11 WLANs, private cellular/CBRS, or IoT-based sensor networks, there will be some need for segmentation to divide the environment into logical segments, and/or to control or filter traffic between the wireless and wired environments.

Why and When to Segment Traffic

Traffic is segmented in different ways and for different purposes such as to:

Secure management and control access from end users

Separate different classes of networks, defined by sensitivity or asset value

Isolate and protect legacy endpoints that present security