Chapter 5 introduces a planning and design methodology loosely based on borrowed constructs from Design for Six Sigma. The planning entails five phases organized in three stages, which collectively comprise the inputs and outputs of the security architecture.
This post is one tiny slice of Chapter 5 to share an image with context. Get the full Wireless Security Architecture book for more than 60 pages of planning and design, and 25 pages of sample architectures to get started.
Discover Stage
– Phase 1: Define (scoping)
– Phase 2: Characterize (requirements mapping)
Architect Stage
– Phase 3: Design (functional mapping)
Iterate Stage
– Phase 4: Optimize (design adjustment)
– Phase 5: Validate (validate design against requirements)
It starts with the define phase to scope the project and collect requirements, followed by a characterize phase to refine and map requirements to the discrete design elements (such as client networks, infrastructure hardening) against known security requirements documented in policies or compliance mandates.
Together, define and characterize compose the discovery tasks and serve as the inputs for the architect stage.
The output of the planning exercise is described through three additional phases—design, optimize, and validate, which comprise the architect and iterate stages.
The optimize and validate phases are entangled and non-linear, where optimize affords the architect the opportunity to further refine the design plans based on changing or additional inputs, while the validate phase serves as the opportunity to compare the design against the original requirements and validate the objectives are being met.
Instead of presenting a canned approach to planning, the content in the book continues with actionable templates and guidance for making decisions based on inputs and how those correlate to the outputs. Sample templates, forms, and tables are provided along with representative data to illustrate the use of the templates.
Finally, Chapter 5 concludes with pointed guidance written for an executive audience who wields the power to help make secure wireless more attainable.
Correlating Inputs to Outputs
The next task in planning is to correlate inputs from define and characterize phases and map to outputs of define, optimize, and validate. Working with the ecosystem of wireless technologies can be more of an art than a science, and your design will require iterative phases of tweaking and repeated validation—validation here meaning validation against the originally defined requirements.
For example, you may design an ideal 802.1X-secured network with FT for fast secure roaming to support a new cloud-hosted VoIP deployment, only to find out the desktop phones and some users’ personal smartphones don’t support FT. In which case, you may have to re-architect for PMK caching, opportunistic key caching (OKC), or even sacrifice security and move some devices to a passphrase-secured network to eliminate the latency of key distributions during roaming.
Figure 5.3 from the book offers a visualization of the relationship of inputs from the discover stage (define and characterize tasks) to the outputs of architect and iterate stages (design, optimize, and validate tasks). This example is a general-use map, and yours may look a little different. It’s possible not all inputs influence the same design outputs, and it’s very likely your project might include custom considerations not reflected here.
Take this mapping as a template to start with and adjust as needed for your projects. Once settled, the map will allow you and other team members to quickly identify dependencies in the architecture. If nothing else, the generic map here is a great tool to help other teams understand the depth of interdependencies of wireless network architecture.
Figure 5.3: Visualization of the relationship of inputs to outputs from “Wireless Security Architecture” page 253.
You can also download the PDF version of Figure 5.3.
More resources from the book can be found by viewing the Wireless Security Architecture book series here on the Security Uncorked blog.
Add comment