Cybersecurity / Advanced: architecture, recovery, and governance / Lesson 13
Threat modeling and security architecture
Turn an explicit service model into owned security requirements and review evidence. Treat trust boundaries and dependencies as architectural decisions rather than relying on a diagram label.
On this page
Lesson goals
- Model assets, actors, data flows, and changing trust assumptions.
- Derive verifiable requirements and maintain the model through change.
Model the real service and its sensitive decisions
Threat modeling starts with a bounded description of what a service does and what harm would matter. For a fictional learning portal, distinguish public lesson reading from private record export and staff account recovery. Identify people, processes, stores, and external dependencies, including support tools and backup access. Record who owns each important asset and decision. A component inventory alone does not explain where authority changes or how data leaves the system. Keep uncertain assumptions visible, and involve the people who understand delivery and operations rather than drawing an ideal architecture detached from the running service.
Document each crossing and its required protection
A data flow describes source, destination, information, purpose, and the controls expected where assumptions change. The record below models a staff export request crossing from a browser into a service that holds private records. It is an application-defined teaching artifact, not executable access policy or an official standard template. Transport protection addresses one part of the flow; it does not establish the requesterโs authority or make an exported copy safe afterward. Follow the response through storage, download, support handling, and retention so the model covers the complete outcome rather than stopping at the first encrypted connection.
{
"flow": "staff-record-export",
"source": "staff-browser",
"destination": "portal-export-service",
"dataClass": "synthetic-private-records",
"boundary": "client-to-service",
"requirements": ["authenticated-subject", "scoped-export-permission", "protected-transport", "owned-retention"],
"owner": "portal-service-owner"
}Expected meaning: four distinct requirements attach to one named crossing. The JSON grants no permission, configures no network, and contains no real identity or records. Each requirement still needs implementation and operating evidence.
Derive plausible harm and explicit assumptions
Ask how an asset could be disclosed, changed, made unavailable, or used outside its intended purpose along the modeled flow. Consider ordinary mistakes as well as deliberate misuse: a legitimate staff member may export the wrong scope or retain a copy indefinitely. Describe the preconditions and existing defenses instead of listing dramatic threats without a credible path. A trust boundary indicates a change in assumptions, not a statement that everything on one side is safe. Identify what a supplier controls and what the portal must still verify. Prioritize scenarios using consequence, exposure, evidence, and uncertainty, with accountable decisions about remaining risk.
Give every important requirement an evidence question
Translate a scenario into a requirement with a responsible owner, intended behavior, and a way to demonstrate it safely. The offline check below identifies incomplete requirement records; it does not verify the portal or decide whether a defense is effective. A test reference is useful only when its scope, result, version, and limitations are available. Prefer precise statements such as an export retaining the selected organization scope over broad claims such as secure exports. Include negative behavior and failure handling in the design, then attach safe unit tests, review records, or authorized exercise results appropriate to the claim.
requirements = [
{"id": "LOCAL-EXPORT-SCOPE", "owner": "service-owner", "evidence": "scope-unit-tests"},
{"id": "LOCAL-EXPORT-RETENTION", "owner": "service-owner", "evidence": ""},
]
incomplete = [r["id"] for r in requirements if not r["owner"] or not r["evidence"]]
assert incomplete == ["LOCAL-EXPORT-RETENTION"]The assertion identifies the retention evidence gap exactly. LOCAL identifiers belong only to this exercise and are not OWASP or NIST requirement numbers. A nonempty evidence label would still require substantive review.
Review the model when service assumptions change
Threat modeling is a recurring design activity rather than a release document to archive and forget. Adding an export supplier, changing identity recovery, or allowing a new administrator role can alter flows and authority without changing the main database schema. Review the affected model, requirements, tests, and recovery dependencies together. Record which scenarios were addressed, deferred, or accepted and by whom. OWASP guidance supports systematic questions and validation, while NIST security engineering connects protection to system lifecycle needs. Neither a completed diagram nor a framework mapping establishes that a deployed system is free of weaknesses or formally certified.
Common errors and fixes
A network location is treated as sufficient trust
- Why it happens
- Connectivity is confused with verified subject and action authority.
- How to fix it
- State identity, scope, and operation requirements at the crossing.
- Prevent it next time
- Review each trust assumption separately from the diagram placement.
A model ends when the export leaves the service
- Why it happens
- Downstream copies and retention were omitted.
- How to fix it
- Follow the data through recipients, storage, and disposal.
- Prevent it next time
- Require an owner for every meaningful copy and flow.
A requirement has a test name but no assessed result
- Why it happens
- A reference label substitutes for evidence quality.
- How to fix it
- Record the test scope, result, version, and limitations.
- Prevent it next time
- Review evidence substance before closing a scenario.
Check your understanding
1. An external reporting supplier is added without changing the portal database. Should the threat model be reviewed?
Show worked solution
Yes. A new recipient and dependency can change disclosure, retention, authentication, and recovery assumptions. Update the flow, supplier responsibility, allowed data scope, evidence, and exit/recovery plan. A stable database schema does not mean the architecture or risk remains unchanged.
2. A team says TLS resolves the staff-export scenario. What must the reviewer ask next?
Show worked solution
Ask how the requester is authenticated, how export scope is authorized, where the resulting copy goes, and how retention and recovery are owned. TLS protects an appropriate transport channel under its trust assumptions; it does not answer those separate business and lifecycle questions.
Key takeaways
- Threat models connect assets and flows to owned requirements.
- Trust boundaries mark assumptions to verify, not guaranteed safety.
- Maintain evidence and review changes throughout the lifecycle.