Jennifer Minella outlines a five-phase methodology for designing an enterprise wireless security architecture that is adapted from Design for Six Sigma (DFSS). The phases are: 1. Define 2. Characterize 3. Design 4. Optimize 5. Validate These phases are grouped into three broader stages: - Discover: Define and Characterize - Architect: Design - Iterate: Optimize and Validate Here’s how they work together in practice: 1) Discover stage – inputs into the architecture - **Define**: You identify project requirements and the scope of the environment. This includes: - Which teams and roles are involved - Existing wired and wireless infrastructure and topology - Types and numbers of users and endpoints - Applications that must be supported over Wi‑Fi - Geographic coverage (campus, branches, home users, etc.) - Existing security policies or regulatory guidance - **Characterize**: You align requirements to the scoped elements. In this phase you: - Map qualitative and quantitative security needs to endpoints, users, applications, and infrastructure - Identify elements that need specific controls (e.g., PCI‑scoped segments) - Group elements with similar needs - Document policy- or regulation-driven requirements (e.g., authentication, encryption) - Flag cases needing elevated controls such as extra monitoring, posture checks, or MFA Together, Define and Characterize give you structured inputs for the architecture work. 2) Architect stage – designing the architecture - **Design**: This is where you do the “heavy lifting” of functional mapping. You: - Map the defined requirements to concrete designs for wired and wireless infrastructure and endpoints - Document conditions, variables, and known or anticipated design gaps (e.g., future IoT projects, WPA3 support uncertainty, upcoming M&A) - Evaluate whether current tools and infrastructure can meet the objectives - Identify vendors, products, and configuration options to achieve the desired security and connectivity - Define metrics and outputs for monitoring and testing - Produce as‑built design documentation for infrastructure devices 3) Iterate stage – continuous improvement - **Optimize**: You refine the design to improve performance and security over time. This is not a one‑time activity. Typical tasks include: - Tracking changes in security protocol standards and updating the architecture accordingly - Evaluating new vendor features for security benefits - Using validation outputs to fine‑tune the architecture - Communicating major security guidance changes to stakeholders - Updating internal standards and process documents - **Validate**: You verify that the architecture still meets the original requirements from Define and Characterize. This includes: - Evaluating the design against those requirements - Documenting gaps to be addressed in the next Optimize cycle - Presenting findings to stakeholders and gathering feedback - Using the metrics defined in the Design phase - Running tests such as security assessments, penetration tests, and leveraging compliance audit outputs Optimize and Validate are intentionally iterative and often non‑linear. You may also run proofs of concept (PoCs) during these phases, ranging from simple internal test SSIDs to more structured vendor-led pilots. Overall, the five phases help you systematically collect inputs and turn them into actionable design outputs, while keeping the architecture aligned with evolving threats, technologies, and business needs.

The Define and Characterize phases form the “discover” stage of Jennifer Minella’s methodology and are critical because they prevent teams from jumping straight into configuration without a clear plan. Many networking teams tend to “wing it,” skipping formal scoping and documentation; these two phases are designed to correct that. Here’s what each phase contributes and what you should do in practice: 1) Define phase – clarify scope and requirements The goal is to understand **what** you’re building for and **where the boundaries are**. Key activities include: - **Identify teams and roles** - Determine who is involved: networking, security, compliance, operations, application owners, and possibly facilities or HR. - **Discover the environment** - Document wired and wireless infrastructure components, capabilities, and topology. - Note current controller models, AP types, authentication systems, and monitoring tools. - **Scope users and endpoints** - Identify user groups (employees, contractors, guests, partners, remote workers). - Catalog endpoint types and capabilities (laptops, smartphones, IoT devices, medical devices, etc.). - **Identify applications over wireless** - List business-critical applications that rely on Wi‑Fi (e.g., collaboration tools, ERP, VoIP, industrial systems). - **Define geographic coverage** - Clarify which locations are in scope: campuses, branch offices, warehouses, home users. - **Gather policies and guidance** - Collect internal security policies and any external regulations or standards that apply. Outcome: You get a clear, documented view of the environment and the project boundaries, which becomes the foundation for all later design decisions. 2) Characterize phase – map requirements to elements Once you know what’s in scope, Characterize focuses on **how each element should be protected**. This is where you align requirements to specific users, devices, applications, and infrastructure. Key activities: - **Map security characteristics to elements** - Capture both qualitative (e.g., “high confidentiality”) and quantitative (e.g., “must use WPA3‑Enterprise”) requirements. - **Identify elements needing specific controls** - For example, network segments in scope for PCI DSS may require stricter authentication, segmentation, and logging. - **Group and categorize elements** - Cluster endpoints, users, or applications with similar needs (e.g., guest users vs. corporate users, IoT vs. managed laptops). - **Document policy- or regulation-driven requirements** - Note where encryption, strong authentication, or specific logging and monitoring are mandated. - **Flag cases needing elevated controls** - Identify where you need extra monitoring, posture checks, or multi-factor authentication. Outcome: You end up with a structured mapping of “who/what needs which controls and why.” This mapping feeds directly into the Design phase, where you translate these needs into concrete architectures, products, and configurations. Why this matters for security: - It reduces the risk of misaligned controls (e.g., over-securing low-risk areas while under-securing regulated segments). - It creates traceability from business and compliance requirements to technical design decisions. - It sets you up for more effective validation later, because you can test the design against clearly documented requirements from Define and Characterize.

In Jennifer Minella’s methodology, the Optimize and Validate phases make up the “iterate” stage. This stage recognizes that wireless security is no longer a set‑and‑forget exercise. Changes in standards, endpoints, applications, and threats mean the architecture needs regular review and adjustment. Here’s how to approach each phase after initial deployment and on an ongoing basis: 1) Optimize phase – refine and enhance the design The focus is on improving robustness, performance, and security of the **architecture**, not just tweaking implementation details. Typical activities: - **Track protocol and standards changes** - Monitor updates in Wi‑Fi and security standards (e.g., WPA3 enhancements) and assess how they should influence your architecture. - **Evaluate new vendor features** - Review new capabilities from your wireless and security vendors for potential security benefits (e.g., improved threat detection, better segmentation options). - **Use validation outputs to tune the design** - Take findings from tests, assessments, and audits and feed them back into architectural changes rather than only point fixes. - **Communicate major changes** - Inform stakeholders when security guidance or architectural patterns change, so operations, support, and business teams understand the impact. - **Update internal standards and processes** - Reflect architectural changes in design standards, configuration baselines, and operational runbooks. 2) Validate phase – confirm the design still meets requirements Validation checks whether the architecture continues to satisfy the requirements defined in the earlier Define and Characterize phases. Key activities: - **Evaluate design against original requirements** - Compare the current architecture to the documented security and business requirements. - **Document gaps and feed them into Optimize** - Record where the architecture falls short and prioritize these items for the next Optimize cycle. - **Engage stakeholders for feedback** - Present findings to relevant teams and confirm that scope and expectations haven’t changed. - **Use defined metrics** - Leverage the metrics and outputs you defined in the Design phase to measure effectiveness. - **Conduct testing and assessments** - Perform security assessments, penetration testing, and use compliance audit outputs as part of validation. 3) Using proofs of concept (PoCs) During Optimize and Validate, it’s common to run PoCs to test architectural changes: - Simple PoCs might involve internal teams creating test SSIDs and validating behavior against the intended design. - More complex PoCs can be structured engagements with vendors, including temporary hardware or software deployments. 4) Why this iterative approach matters - It keeps the architecture aligned with evolving threats and technologies. - It ensures changes in endpoints, applications, or network infrastructure are reflected in your security design. - It provides a structured loop: **Validate → identify gaps → Optimize → re‑Validate**, rather than ad‑hoc fixes. By treating Optimize and Validate as ongoing, interconnected activities, your team can reimagine wireless security as a living architecture that adapts to new requirements instead of a one-time project that quickly becomes outdated.