32,99 €
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.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 930
Veröffentlichungsjahr: 2022
Cover
Title Page
Foreword
Preface
Who This Book Is For
Distinctive Features
Introduction
Overview of the Book and Technology
How This Book Is Organized
Why Read This Book
What's on the Website
Congratulations
Part I: Technical Foundations
CHAPTER 1: Introduction to Concepts and Relationships
Roles and Responsibilities
Security Concepts for Wireless Architecture
Wireless Concepts for Secure Wireless Architecture
Summary
CHAPTER 2: Understanding Technical Elements
Understanding Wireless Infrastructure and Operations
Understanding Data Paths
Understanding Security Profiles for SSIDs
Summary
CHAPTER 3: Understanding Authentication and Authorization
The IEEE 802.1X Standard
RADIUS Servers, RADIUS Attributes, and VSAs
Change of Authorization and Disconnect Messages
EAP Methods for Authentication
MAC-Based Authentications
Certificates for Authentication and Captive Portals
Captive Portal Security
LDAP Authentication for Wi-Fi
The 4-Way Handshake in Wi-Fi
Summary
CHAPTER 4: Understanding Domain and Wi-Fi Design Impacts
Understanding Network Services for Wi-Fi
Understanding Wi-Fi Design Impacts on Security
Summary
Part II: Putting It All Together
CHAPTER 5: Planning and Design for Secure Wireless
Planning and Design Methodology
Planning and Design Inputs (Define and Characterize)
Planning and Design Outputs (Design, Optimize, and Validate)
Correlating Inputs to Outputs
Planning Processes and Templates
Notes for Technical and Executive Leadership
Summary
CHAPTER 6: Hardening the Wireless Infrastructure
Securing Management Access
Designing for Integrity of the Infrastructure
Controlling Peer-to-Peer and Bridged Communications
Best Practices for Tiered Hardening
Additional Security Configurations
Summary
Part III: Ongoing Maintenance and Beyond
CHAPTER 7: Monitoring and Maintenance of Wireless Networks
Security Testing and Assessments of Wireless Networks
Security Monitoring and Tools for Wireless
Logging, Alerting, and Reporting Best Practices
Troubleshooting Wi-Fi Security
Training and Other Resources
Summary
CHAPTER 8: Emergent Trends and Non-Wi-Fi Wireless
Emergent Trends Impacting Wireless
Enterprise IoT Technologies and Non-802.11 Wireless
Final Thoughts from the Book
Appendix A: Notes on Configuring 802.1X with Microsoft NPS
Wi-Fi Infrastructure That Supports Enterprise (802.1X) SSID Security Profiles
Endpoints That Support 802.1X/EAP
A Way to Configure the Endpoints for the Specified Connectivity
An Authentication Server That Supports RADIUS
Appendix B: Additional Resources
IETF RFCs
IEEE Standards and Documents
Wi-Fi Alliance
Blog, Consulting, and Book Materials
Compliance and Mappings
Cyber Insurance and Network Security
Appendix C: Sample Architectures
Architectures for Internal Access Networks
Architectures for Guest/Internet-only Networks
Determining Length of a WPA3-Personal Passphrase
Appendix D: Parting Thoughts and Call to Action
The Future of Cellular and Wi-Fi
MAC Randomization
Security, Industry, and The Great Compromise
Index
Copyright
Dedication
About the Author
About the Technical Editor
Acknowledgments
End User License Agreement
Chapter 2
Table 2.1: Example of planes in wireless
Table 2.2: Cloud architecture and planes
Table 2.3: Current SSID security options in products
Table 2.4: WPA3-Enterprise cipher and AKM suites
Table 2.5: WPA3-Enterprise 192-bit TLS cipher suites
Chapter 3
Table 3.1: Examples of standard RADIUS attributes in Wi-Fi
Table 3.2: Standard RADIUS attributes and values for dynamic VLAN assignment...
Table 3.3: Examples of Vendor-Specific Attributes
Table 3.4: Sample list for planning RADIUS clients
Table 3.5: CoA and DM RADIUS code descriptions
Table 3.6: Comparison of EAP outer tunnels
Table 3.7: Comparison of EAP inner authentication methods for Wi-Fi
Table 3.8: Recommended EAP outer and inner combinations for enterprise Wi-Fi...
Table 3.9: Security differences in 802.1X vs. MAB
Table 3.10: Server certificate requirements for various EAP methods
Table 3.11: Summary of server certificate recommendations by use case
Chapter 4
Table 4.1: Summary of key exchanges with roaming facilitation
Chapter 6
Table 6.1: Overview of file transfer protocol security
Table 6.2: Summary of management protocols and recommended encrypted version...
Table 6.3: Comparing TACACS+ and RADIUS for management
Table 6.4: AP provisioning models supported
Table 6.5: Comparison of AP-to-switch authentication options
Chapter 7
Table 7.1: Comparison of common rogue classifications
Table 7.2: Summary of recommended logging, alerting, and reporting by type
Table 7.3: MAC address delimiter formats
Chapter 8
Table 8.1: Management and ownership models for devices
Table 8.2: Table of BYOD access planning
Table 8.3: Cellular generations and technologies
Table 8.4: Excerpt of 3GPP releases and IoT-friendly classes
Table 8.5: Private cellular vs. Wi-Fi
Appendix B
Table B.1
:
NIST 800-53 control families
Table B.2
:
Sample excerpt rows from NIST to ISO mapping
Appendix C
Table C.1
:
WPA3-Personal passphrase length recommendations
Appendix D
Table D.1
:
Overview of cellular, Wi-Fi, and MNO augmentation
Chapter 1
Figure 1.1: Elements of integrity, availability, and confidentiality are per...
Figure 1.2: As security requirements increase, risk tolerance decreases, and...
Figure 1.3: In the hierarchy of policies, standards, and procedures, one bro...
Figure 1.4: Recap of the intent and relationship of policies, standards, and...
Figure 1.5: Overview of the seven layers of the OSI model. Layer 2 is the MA...
Figure 1.6: A simplified view of public and private key use in public key cr...
Figure 1.7: A side-by-side comparison of pros and cons of symmetric and asym...
Figure 1.8: IEEE logo
Figure 1.9: The Wi-Fi Alliance manages the testing and certification of 802....
Figure 1.10: The IETF creates most of the world's Internet protocols in use ...
Figure 1.11: Summary of three classes of SSID security profiles with use cas...
Figure 1.12: In campus topologies, the users, infrastructure, and internal r...
Figure 1.13: With remote branch topologies, satellite locations are connecte...
Figure 1.14: In remote worker environments, the user either has a remote AP ...
Figure 1.15: Sample remote AP products from Aruba Networks and Juniper Mist...
Chapter 2
Figure 2.1: Management, control, and data planes
Figure 2.2: A sample architecture for bridged versus tunneled client data in...
Figure 2.3: Sample local cluster management architecture
Figure 2.4: Sample remote AP architecture
Figure 2.5: Comparison of tunneled (left) versus bridged (right) client traf...
Figure 2.6: A hybrid data path model using both tunneled and bridged traffic...
Figure 2.7: Sample overview of segmenting on the Wi-Fi infrastructure versus...
Figure 2.8: Comparison of the segmentation behavior of VLANs (left) versus V...
Figure 2.9: This endpoint's default gateway is on the wired network
Figure 2.10: Aruba Central's security profile options for the Enterprise cla...
Figure 2.11: High-level view of required components for 802.1X in secure Wi-...
Figure 2.12: Sample screenshots of 802.1X security options from Juniper Mist...
Figure 2.13: Screenshot from Aruba Central showing Personal network options...
Figure 2.14: Screenshot from a Fortinet FortiGate-managed AP showing Persona...
Figure 2.15: WPA2-Personal PSK versus WPA3-Personal SAE
Figure 2.16: This image demonstrates the exchanges during SAE and the deriva...
Figure 2.17: Adoption of encrypted Internet traffic from Google
Figure 2.18: The 802.11 Open System Authentication
Figure 2.19: Enhanced Open Transition Mode uses two SSIDs
Figure 2.20: Snapshot from NetAlly EtherScope nXG showing the two networks f...
Chapter 3
Figure 3.1: High-level view of 802.1X components
Figure 3.2: The use of EAPoL and RADIUS protocol during authentication Wi-Fi...
Figure 3.3: The two logical 802.1X port entities
Figure 3.4: Relationship between endpoints, Wi-Fi infrastructure, and the RA...
Figure 3.5: Sample attributes for dynamic VLAN assignment
Figure 3.6: Example of RADIUS policy conditions, constraints, and settings
Figure 3.7: RADIUS clients can be added by IP address, IP network, or hostna...
Figure 3.8: Microsoft NPS options for logging targets
Figure 3.9: Microsoft NPS options for level of logging detail and logging fa...
Figure 3.10: Markup of default Microsoft NPS text file log
Figure 3.11: View of CoA operations within 802.1X authentication
Figure 3.12: Comparison of CoA configurations
Figure 3.13: Conceptual representation of the EAP framework using an outer t...
Figure 3.14: A correct PEAP with MSCHAPv2 configuration on the top, and an i...
Figure 3.15: RSA SecureID USB token
Figure 3.16: MAB authentication process
Figure 3.17: Process of an endpoint validating a server's certificate
Figure 3.18: Microsoft Active Directory Group Policy options for validating ...
Figure 3.19: A Windows 10 device, showing MAC randomization options
Figure 3.20: An Apple iPhone private address (MAC randomization) settings...
Figure 3.21: An Android device MAC randomization settings
Figure 3.22: A view of the 4-way handshake between an endpoint (defined as a...
Figure 3.23: The 4-way handshake after 802.1X authentication
Chapter 4
Figure 4.1: Machines and microservices use certificates, signatures, and tok...
Figure 4.2: DHCP request paths using proxy from wired and wireless infrastru...
Figure 4.3: Alternate configurations demonstrating ability of certain networ...
Figure 4.4: Windows ipconfig output showing the endpoint's default gateway o...
Figure 4.5: Exchanges required for a hard roam on a WPA2-Personal with PSK n...
Figure 4.6: Exchanges required for a hard roam on an 802.1X-secured network...
Figure 4.7: PMK derivation and key distribution for roaming facilitation
Figure 4.8: Conceptual view of Fast Reconnect
Figure 4.9: PMK caching, or roam back, offers benefits only in cases where a...
Figure 4.10: OKC eliminates the 802.1X re-authentication when roaming to nea...
Figure 4.11: An endpoint roaming on an 802.1X network with FT is faster than...
Figure 4.12: A high-level comparison of spectrum availability and channels i...
Figure 4.13: 6 GHz channel allocations in detail
Figure 4.14: In Wi-Fi, the white spaces are the only times the RF medium is ...
Figure 4.15: Sample rate limiting options on Juniper Mist
Figure 4.16: Sample output of CDP on the same AP and switch
Figure 4.17: Sample output of LLDP-MED of an AP connected to a switch
Figure 4.18: Sample output of LLDP-MED on a VoIP device
Chapter 5
Figure 5.1: The five phases of the planning and design methodology
Figure 5.2: Example of a simplified RACI matrix for a wireless project
Figure 5.3: Visualization of the relationship of inputs to outputs
Figure 5.4: Sample requirements discovery template for endpoints and users i...
Figure 5.5: Sample requirements discovery template populated with sample hea...
Figure 5.6: Sample planner template for controller and AP management network...
Figure 5.7: Sample planner to be used per SSID
Figure 5.8: An advanced access rights planner that factors ownership along w...
Figure 5.9: An advanced access rights planner for higher education
Figure 5.10: A simplified access rights form for wireless connections only, ...
Chapter 6
Figure 6.1: Sample PEM certificate file format
Figure 6.2: Sample DER certificate file format
Figure 6.3: In most products you can enable HTTPS and disable HTTP in the we...
Figure 6.4: Creation of an ECDSA SSH key pair with PUTTYGEN
Figure 6.5: Many enterprise Wi-Fi products support public key authentication...
Figure 6.6: Where possible, always change the APs' default username and pass...
Figure 6.7: Figure 10 from the Verizon DBIR 2021 report, showing privilege a...
Figure 6.8: The report highlights credentials as top data varieties in breac...
Figure 6.9: Demonstrating three AP to switch authentication options
Figure 6.10: Example of a mounting enclosure with tamper-resistant screws (u...
Figure 6.11: Example of a mounting enclosure with a key lock
Figure 6.12: An Aruba 7200 series Mobility Controller. Notice the console po...
Figure 6.13: Diagram of the front panel components of a Cisco 9800-80 Contro...
Figure 6.14: Image of an Aruba Networks 600 series AP with mini USB console...
Figure 6.15: An example of a tamper-evident label
Figure 6.16: Peer communication through an enterprise AP vs. ad-hoc networks...
Figure 6.17: On most devices, it's trivial for a user to share network conne...
Figure 6.18: Juniper Mist options for inter-station blocking and multicast c...
Figure 6.19: Aruba Networks Central Cloud SSID configuration
Figure 6.20: Excerpt from Trustwave's post on the security vulnerabilities o...
Figure 6.21: Tiered guidance for securing management access for low, medium,...
Figure 6.22: Tiered guidance for designing for integrity in low, medium, and...
Figure 6.23: Tiered guidance for controlling peer-to-peer and bridged commun...
Figure 6.24: Conceptual comparison of connecting to a hidden SSID versus a b...
Figure 6.25: A Windows configuration option to connect to an SSID even if it...
Figure 6.26: The Hide SSID option in Juniper Mist
Figure 6.27: The Hide SSID option of Aruba Networks Central Cloud platform
Figure 6.28: The option to share a passphrase credential via QR code from an...
Figure 6.29: Screenshot from Apple on sharing network passwords
Chapter 7
Figure 7.1: Sample data from vulnerability scanning in a lab environment
Figure 7.2: CVE-2020-26140 was one of many vulnerabilities exploited in Frag...
Figure 7.3: The level of touch varies from audits and assessments to penetra...
Figure 7.4: Visibility of WIPS vs. wired IPS
Figure 7.5: For any given radio, an AP also serving as a WIPS sensor will sp...
Figure 7.6: Juniper Mist has limited WIPS configuration in the web UI.
Figure 7.7: WIPS configuration options on Aruba Central cloud
Figure 7.8: In AP impersonation (top), an AP is advertising the same network...
Figure 7.9: Image from a Cisco article detailing how to identify randomized ...
Figure 7.10: In request-to-send (RTS) and clear-to-send (CTS) attacks, airti...
Figure 7.11: Screenshot from a Windows laptop showing the option for a user ...
Figure 7.12: After configuring the bridged interface, an end user can specif...
Figure 7.13: In a client misassociation, an enterprise client associates wit...
Figure 7.14: APs are commonly classified a few ways.
Figure 7.15: Over-the-air mitigation by a WIPS using spoofed broadcast and u...
Figure 7.16: The cover of a nine-page order issued by the FCC to Marriott re...
Figure 7.17: Spectrum analyzers, protocol analyzers, and packet analyzers op...
Figure 7.18: Visualization of spectrum analysis overlaid with Wi-Fi channel ...
Figure 7.19: NetAlly's AirMagnet Spectrum XT software
Figure 7.20: NetAlly dual band USB spectrum analyzer
Figure 7.21: Vendor 7Signal offers an app-based agent and hardware sensors i...
Figure 7.22: The NetAlly EtherScope nXG is a great handheld tool for testing...
Figure 7.23: Heatmap output from a live RF survey
Figure 7.24: A Wireshark Wi-Fi packet capture can parse from layers 2 and hi...
Figure 7.25: Connected components with numbers designating each troubleshoot...
Figure 7.26: Sample port-level configuration of a switch using 802.1X with M...
Chapter 8
Figure 8.1: Gartner's predictive analysis shows a continued increase in remo...
Figure 8.2: Zero trust terminology is just an upcycle of NAC
Figure 8.3: Simplified view of cloud-routed versus direct-routed zero trust ...
Figure 8.4: LAN-based IoT vs. protocol-translated IoT vs. protocol-routed Io...
Figure 8.5: Comparison of power consumption and range for common IoT technol...
Figure 8.6: Visual map of IoT technologies, their topologies, coverage areas...
Figure 8.7: Excerpt table from a network connectivity datasheet for a Wi-Fi-...
Figure 8.8: The Bluetooth-enabled Azure Medtronic pacemaker was just one of ...
Figure 8.9: Visualizing the ratio of IPv4 to IPv6 addresses (top) and 802.15...
Figure 8.10: The Thread communication stack
Figure 8.11: 5G network slices can divvy up airtime and bandwidth to meet va...
Figure 8.12: Cellular LANs are deployed much like Wi-Fi.
Figure 8.13: Cellular LANs can be integrated into the enterprise LAN several...
Figure 8.14: As an example of the coverage capabilities, this vendor’s rough...
Figure 8.15: Comparison of roaming decisions on Wi-Fi (left) versus cellular...
Figure 8.16: Cellular nodes (or cellular APs) look and operate very much lik...
Figure 8.17: Sigfox adoption is focused in about a dozen European countries ...
Figure 8.18: Diagram of WirelessHART architecture
Figure 8.19: ISA100.11a sample architecture
Appendix A
Figure A.1: Most non-standard endpoints such as network printers and VoIP ph...
Figure A.2: Microsoft NPS can be instructed to forward or proxy RADIUS reque...
Figure A.3: The Network Policies of Microsoft NPS, which set the criteria fo...
Figure A.4: This view shows the details of a policy specifying Microsoft PEA...
Figure A.5: Network Policy configuration showing the attributes for dynamic ...
Appendix B
Figure B.1: Sample IETF RFC header
Appendix C
Figure C.1: Architecture summary for internal access by managed users with m...
Figure C.2: Architecture summary for internal access by headless devices
Cover
Table of Contents
Title Page
Copyright
Dedication
About the Author
About the Technical Editor
Acknowledgments
Foreword
Preface
Introduction
Begin Reading
Appendix A: Notes on Configuring 802.1X with Microsoft NPS
Appendix B: Additional Resources
Appendix C: Sample Architectures
Appendix D: Parting Thoughts and Call to Action
Index
End User License Agreement
iii
xxix
xxx
xxxi
xxxii
xxxiii
xxxv
xxxvi
xxxvii
xxxviii
xxxix
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
365
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
iv
v
vii
ix
xi
xii
585
Jennifer (JJ) Minella
With all the innovations and alphabet soup of the different 802.11 standards, Wi-Fi security is one of those functions at the core of all modern protocol development. We are in an age of ensuring that we protect not only the information in transit, but also the identity of the user and device, and we need to balance this with protecting the access to personal and corporate resources. Modern-day security development and deployment for Wi-Fi is a delicate balancing act where all these nuances must be considered. If you make security too difficult to use/deploy, people will bypass it or turn it off; if it's not secure enough, you will surely make the headlines.
Full disclosure, Wi-Fi security is a topic near and dear, so I am slightly biased to its importance. My journey started by asking a simple question: how is Wi-Fi Protected Access different than WEP and could this be deployed for use in government agencies? Years later this continued interest in Wi-Fi security led to an opportunity to participate in the Wi-Fi Alliance Security Working Groups, where I was introduced to a talented group of individuals focused on advancing wireless security capabilities. Fast forward 10+ years and this group has addressed vulnerabilities in Wi-Fi Certified WPA2, launched Wi-Fi Certified WPA3 (multiple releases), addressed the challenges of Open networks with Wi-Fi Certified Enhanced Open, and finally, set a new bar for wireless security by eliminating WPA2 and Open networks in new MAC/PHY bands starting with 6 GHz. Introducing new security requirements is hard and not always fast. Status quo is easy and change is difficult specifically with security, but sometimes ripping the bandage off may need to be done because the major headlines get made when there is an issue with Wi-Fi security.
When asked to write the foreword for JJ's book on Wireless Security Architecture, I needed to think about how to frame the journey readers will take because the context of the title is important. The topic isn't securing wireless—it's wireless security architectures, which is an overarching defense-in-depth approach to creating an architecture that meets your business objectives, starting at the wireless access layer with security at the forefront and continuing that into the enterprise network. Most don't look past the 802.11 layer when we talk about Wi-Fi security, however 802.11 is now the dominant access layer and care must be taken on its integration into your enterprise.
Entire books have been written on the intricacies, nuances, and in-depth protocol discussions of 802.11 security. They have done so from the point of view of the interpretation of the standards bodies (IEEE 802.11) or the certification organizations such as the Wi-Fi Alliance, but not from the perspective of the CXO, network operator, network architect, or the user. Where this book is different is that it is all about context. JJ takes a unique approach to making wireless security relevant and peels back the complexities to show how security at the wireless access layer should be integrated as part of your overall architecture design and strategy, as opposed to bolted on as an independent afterthought. Additionally, the discussions and insights on how compliance will cause decisions to be made and impact architecture designs are invaluable for those dealing with customers that must meet requirements set forth by PCI, HIPAA, NIST, etc.
I hope you enjoy reading the book as much as I did, and I will leave everyone with a few final thoughts.
Security is a continual process; requirements and designs must always be reevaluated. What was good three years ago may not provide the same security levels that you need today; “good enough” security is never “good enough.”
Raise the bar. Security can and should be at the forefront of the discussions with your vendors, consultants, and architects during the acquisition process, not after. Certifications are critical to the security conversation—not only do they define interoperability, but they ensure conformance. You shouldn't fall back to compromising your network because the latest security standards are not supported (remember you will make the news, not them).
Ensure your use cases are driving development by asking questions, contributing to forums, and getting involved.
Stephen Orr
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.
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 [email protected] with the subject line “Possible Book Errata Submission.” For other feedback you can contact me on LinkedIn or at [email protected].
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.
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.
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
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.”
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.”
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.
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 (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.
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 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.
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.
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.
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.
