Capstone Scoping, Architecture Design, and Risk Planning

Why Scoping Comes First

Every cybersecurity project—whether a penetration test, a security audit, or a full program implementation—begins with a clearly defined scope. Without scope, work expands without limit, resources are wasted on systems that were never meant to be protected, and stakeholders disagree on what "done" looks like. In this capstone, you will define exactly what you are protecting, how you know you have succeeded, and what threats you must address before a single firewall rule is written.

Understanding the Scenario and Stakeholder Context

You will work from a written scenario brief describing a fictional 75-person company. Before drafting any document, read the brief carefully and identify the company's compliance obligations (for example, obligations related to payment card data, health information, or federal contracts), the types of data it processes, the systems it relies on, and any third-party relationships. Stakeholder context shapes every scoping decision: a system owned by a vendor but sitting on your network may be out of scope for remediation but still in scope for monitoring.

Writing a Project Scope Document

A professional scope document answers four questions:

1. What is in scope? List specific assets—servers, endpoints, cloud services, network segments, and data types—that the project will address.

2. What is out of scope? Name systems or locations explicitly excluded, and briefly explain why. This protects you and the organization from scope creep.

3. What does success look like? Success criteria must be measurable. "Improve security" is not measurable. "Reduce mean time to detect an intrusion to under 24 hours" or "pass a PCI DSS self-assessment questionnaire" are measurable.

4. How will work proceed? A weekly milestone schedule ties each capstone lesson to a deliverable, keeping the project on track.

Finally, state which security framework will guide decisions. The NIST Cybersecurity Framework (CSF) organizes security activities into five core functions—Identify, Protect, Detect, Respond, and Recover—and is widely accepted by both private industry and government. Briefly justify your choice: explain why the framework fits the scenario's risk profile and compliance requirements.

Threat Modeling with STRIDE

STRIDE is a structured threat-modeling methodology developed to categorize threats by the type of harm they cause:

• Spoofing – Impersonating a legitimate user or system
• Tampering – Unauthorized modification of data or code
• Repudiation – Denying an action without the ability to prove otherwise
• Information Disclosure – Exposing data to unauthorized parties
• Denial of Service** – Disrupting availability of a system or service
• Elevation of Privilege – Gaining rights beyond what is authorized

For each threat you identify, record it in the risk register with a brief description, the STRIDE category, a likelihood rating (typically 1–5 or Low/Medium/High), and an impact rating using the same scale. This lesson requires at least eight threats. Likelihood reflects how probable an event is given current controls; impact reflects the harm if it occurs. Together they guide prioritization: a high-likelihood, high-impact threat demands immediate attention.

Designing a Logical Network Security Architecture

A logical network diagram shows the relationships between network segments and the security controls protecting them. It does not need to show physical cables or hardware brands, but it must show boundaries clearly. Key elements for this capstone include:

• Firewall – Placed at the perimeter between the untrusted internet and the internal network, and between network zones internally
• DMZ (Demilitarized Zone) – A screened subnet that hosts public-facing services (web, email) so that a compromise does not give direct access to internal systems
• IDS/IPS – Intrusion Detection or Prevention System, placed where it can see relevant traffic, often inline or on a span port inside the perimeter
• SIEM – Security Information and Event Management platform, typically shown as a management-layer component receiving log feeds from all other controls

Annotate each control with the Security+ or CySA+ exam domain it most directly relates to (for example, a firewall maps to the Security+ domain covering network security; a SIEM maps to the CySA+ domain covering threat and vulnerability management).

Risk Register Essentials

A risk register is a living document. Each row typically contains: threat name, threat category, affected asset, likelihood rating, impact rating, risk score (often likelihood × impact), current controls, and recommended treatment (accept, mitigate, transfer, or avoid). A well-maintained risk register is required by frameworks such as NIST CSF and is evidence of due diligence in regulatory reviews.

Safe Practices in Documentation Work

Even in a classroom setting, treat scenario data as if it were real. Do not share fictional network diagrams or credentials outside the class environment. When working on shared platforms, use only school-approved cloud tools and ensure no actual company data or personal information is uploaded. These habits directly reflect professional obligations under frameworks such as ISC2's Code of Ethics, which requires protecting the confidentiality of information about principals.