Lesson A19.4
A strong threat model turns a security diagram into a structured defensive argument. It identifies what matters, where trust changes, what could plausibly go wrong, which controls reduce the concern, and what deserves attention first.
This lesson teaches threat modeling as safe design review. You will use only fictional Northbridge architecture and synthetic evidence. The work does not involve probing, exploiting, scanning, testing, or changing any real system.
Lesson Progress
High School Advanced • A19: Cybersecurity Portfolio Projects • Lesson 4 of 10
Readiness Check
0/4 ready
Professional Hook
Security diagrams are useful because they show where components, identities, data, and responsibilities connect. But a diagram can still leave an important question unanswered: what assumptions are we making about those connections? A threat model asks that question deliberately.
When a user request crosses from an external portal into an authenticated application, the system assumes identity and authorization controls will behave correctly. When a worker service updates protected records, the design assumes the service identity has only the required permissions. When monitoring supports incident response, the team assumes telemetry will arrive with enough coverage and freshness to support a decision. Threat modeling turns these assumptions into reviewable security work.
The goal is not to imagine the most dramatic failure possible. The goal is to identify credible defensive concerns, explain why they matter, understand which controls address them, record uncertainty, and improve the design before a real problem occurs.
Learning Objectives
Explain what a threat model is, why defenders use one, and how it differs from a vulnerability list, incident report, security diagram, or risk register.
Identify fictional assets, actors, trust boundaries, entry points, dependencies, security assumptions, and defensive objectives without drifting into offensive testing instructions.
Write bounded threat statements that connect an asset, a plausible adverse event, an affected security property, available evidence, and a defensive concern.
Prioritize threat-model findings using impact, exposure, control strength, uncertainty, dependency importance, and business context rather than dramatic labels alone.
Create a portfolio-ready Threat Model Project that demonstrates structured reasoning, clear diagrams, traceable assumptions, defensive recommendations, and publication-safe documentation.
Core Teaching
Threat modeling is a structured way to examine a system from a defensive point of view. It starts with the system's purpose and important assets, then examines actors, trust boundaries, flows, dependencies, controls, and assumptions. From there, the defender writes bounded statements about what could go wrong and how the design should reduce the concern.
A threat model is not the same thing as a vulnerability assessment. A vulnerability assessment looks for specific weaknesses in an implementation. A threat model can begin before implementation exists because it reasons from architecture, trust, privilege, data flow, and business impact. It is also not an incident report, because the model describes plausible future concerns rather than reconstructing an event that already happened.
A system design always contains assumptions: which identities are trusted, which service owns a decision, which boundary separates contexts, which data flow is expected, and which dependency must remain available. Threat modeling brings those assumptions into the open so defenders can review them.
A security diagram shows components and flows. A threat model asks what could go wrong at those boundaries, what matters if it does, what evidence supports the concern, and which controls or design choices reduce the exposure.
Not every hypothetical problem has the same importance. Threat modeling helps teams focus on assets, flows, privileges, and dependencies whose failure, misuse, or loss of trust could create meaningful impact.
Threat modeling is most useful when it informs architecture, requirements, ownership, logging, resilience, and review decisions early enough to change the design safely.
A good model lets another reviewer understand why a concern exists, what evidence or assumption supports it, which control addresses it, what remains uncertain, and who owns the next decision.
Model Vocabulary
A portfolio threat model should be readable by someone who did not build the original diagram. These elements give the reader enough context to understand what is protected, where trust changes, which dependencies matter, and why the recommendations exist.
The data, service, capability, identity, workflow, decision, reputation, or business function that needs protection.
Review question: What would matter if confidentiality, integrity, availability, authenticity, or accountability were weakened?
People, services, devices, applications, partners, administrators, automated workloads, or other entities that interact with the fictional system.
Review question: Which actors are expected, which are external, and which require elevated trust or privilege?
Places where data, identity, authority, responsibility, or assumptions change between zones, services, organizations, or security contexts.
Review question: What must be re-verified when information or authority crosses this boundary?
Approved interfaces through which actors or systems begin an interaction, such as a fictional user portal, API gateway, admin workflow, partner integration, or message queue.
Review question: Which controls govern the interaction before trust is extended?
How information, requests, approvals, events, and decisions move between system components.
Review question: Where could a flow lose integrity, confidentiality, context, attribution, or availability?
Services, identity providers, storage, networks, logging systems, approval workflows, third parties, and operational processes required for the design to function safely.
Review question: What happens if the dependency is unavailable, stale, misconfigured, or no longer trustworthy?
Defensive measures that reduce likelihood or impact, including authentication, authorization, validation, segmentation, logging, review, recovery, and governance.
Review question: What does the control actually prevent, detect, limit, recover, or prove?
Conditions believed to be true but not yet fully proven, plus evidence gaps that affect confidence.
Review question: Which conclusions would change if this assumption were false?
Security Properties
Threat statements become clearer when they identify the security property that could be weakened. This prevents the model from becoming a generic list of problems and helps connect the concern to the right kind of control.
Information should be available only to approved identities, roles, services, and processes.
Portfolio use: Describe which fictional information requires protection and where a boundary or flow could expose more than intended.
Data, configuration, approvals, software, messages, and decisions should remain accurate and protected from unauthorized change.
Portfolio use: Show where validation, authorization, provenance, or separation of duties helps preserve trustworthy state.
Important services, dependencies, monitoring, and recovery capabilities should remain usable when needed.
Portfolio use: Identify critical dependencies and resilience assumptions without turning the exercise into disruption instructions.
The system should have reasonable evidence that an identity, message, service, or source is what it claims to be.
Portfolio use: Document where identity proof, service trust, certificate validation, or ownership evidence matters conceptually.
Important actions and decisions should be attributable through appropriate logging, ownership, approvals, and review records.
Portfolio use: Show which events must be observable enough for later investigation and governance without exposing real logs.
Threat Statements
Weak threat statements are difficult to act on because they do not say what is protected, why the concern is plausible, or what kind of defensive response is appropriate. A stronger statement connects the concern to architecture and evidence.
Name the fictional data, service, identity, workflow, or decision that could be affected.
Describe the concern at a high level, such as unauthorized access, incorrect privilege, loss of availability, untrusted input, stale authorization, or missing visibility.
State whether confidentiality, integrity, availability, authenticity, accountability, or several properties are at stake.
Explain which trust boundary, dependency, assumption, or design condition makes the concern plausible.
Describe the realistic operational or business effect without exaggeration.
Identify the control, architecture change, validation, monitoring, ownership, recovery, or governance action that reduces the concern.
A useful pattern
If a defined condition at a trust boundary or dependency occurs, then a protected asset could experience a bounded security consequence because a control or assumption may be insufficient. The defensive response should identify the control, owner, validation, or recovery improvement that reduces the concern.
Writing Quality
Weak
The API could be hacked.
Stronger
If a request reaches the fictional API from an external zone without the expected identity and authorization checks, protected records could be disclosed or changed outside approved access. The model therefore requires authenticated identity, least-privilege authorization, input validation, logging, and owner review at that trust boundary.
Why it improves: The strong statement names the boundary, protected asset, security properties, defensive controls, and decision owner instead of using a vague dramatic claim.
Weak
The cloud is risky.
Stronger
The fictional application depends on a shared cloud identity service. If role ownership becomes stale or access reviews stop occurring, unnecessary privileges could persist and weaken accountability. The design should maintain named role owners, recurring access review, expiration for temporary grants, and evidence of review completion.
Why it improves: The concern is tied to a specific dependency and governance condition rather than treating an entire technology category as dangerous.
Weak
Logs will stop attackers.
Stronger
Logging does not prevent every adverse event, but reliable identity, application, and authorization telemetry can improve detection, investigation, accountability, and validation. The threat model should record what must be observable and what happens if visibility is degraded.
Why it improves: Controls should be described according to what they actually do, not as universal guarantees.
Weak
Use more security everywhere.
Stronger
The admin workflow crosses a higher-trust boundary and can change sensitive configuration. It deserves stronger authentication, limited role membership, approval evidence, session accountability, and a defined recovery path because the potential impact is greater than a normal read-only user flow.
Why it improves: Security effort should be proportional to privilege, impact, exposure, and dependency importance.
Fake Dashboard
Synthetic portfolio dashboard showing the status of a fictional design review.
Model elements
8
Assets, actors, trust boundaries, entry points, flows, dependencies, controls, and assumptions
Threat statements
8
Curated concerns linked to fictional architecture evidence
Priority items
3
Admin privilege, API authorization, and monitoring coverage need owner review first
Open assumptions
4
Review cadence, telemetry freshness, recovery evidence, and role ownership require confirmation
Fake SOC Alert
Source: Synthetic Architecture Governance Queue • Time: Portfolio review checkpoint
Fake Log Panel
[TM-01] Portal -> Identity Gateway crosses from external context to authenticated identity context. [TM-02] Identity Gateway -> API carries user identity and role context; API remains responsible for resource authorization. [TM-03] API -> Queue changes from synchronous request context to asynchronous processing context. [TM-04] Queue -> Worker delegates a task to service identity SVC-NB-8. [TM-05] Worker -> Data Service crosses into protected data context with write capability. [TM-06] Admin Console -> Configuration service uses restricted role and approval evidence. [TM-07] Monitoring receives telemetry from identity, application, queue, and logging sources. [TM-08] Recovery workflow is documented as required but validation evidence is not part of this student model.
Training note: this is fake data for defensive analysis practice only.
Fictional Architecture
The following records extend the fictional security diagram from A19.2. They are intentionally abstract. There are no real addresses, credentials, hostnames, production routes, or exploitable configuration details. The goal is to reason about trust, privilege, dependencies, and controls.
Asset
Fictional account profile data, session state, service availability, and user trust
Dependency
Identity Gateway IG-NB-4 and Application API API-NB-14
Trust Boundary
Untrusted internet context to authenticated application context
Assumption
Only authenticated sessions with expected authorization can request protected profile data
Asset
Authentication decisions, role context, session assertions, and identity audit evidence
Dependency
Directory DIR-NB-2 and approved federation configuration
Trust Boundary
External authentication request to trusted identity decision
Assumption
Role mappings and federation relationships are reviewed and owned
Asset
Business logic, authorization decisions, profile records, and service integrity
Dependency
Identity Gateway, Data Service DS-NB-6, Queue Q-NB-5
Trust Boundary
Authenticated user context to service-to-service execution context
Assumption
The API validates identity context and applies resource-level authorization before returning protected data
Asset
Synthetic student preference records and application configuration
Dependency
Managed storage, service identity, backup workflow
Trust Boundary
Application service context to protected data context
Assumption
Only the designated service identity and approved administrative roles can reach the data service
Asset
Processing integrity, delivery order, workload availability, and event context
Dependency
Worker WK-NB-8 and Monitoring MON-NB-3
Trust Boundary
Application request context to asynchronous processing context
Assumption
Messages preserve expected context and failures remain observable through fictional telemetry
Asset
Automated processing decisions and downstream update integrity
Dependency
Queue Q-NB-5, service identity SVC-NB-8, Data Service DS-NB-6
Trust Boundary
Queued task to privileged service operation
Assumption
The worker identity has only the permissions required for its defined task
Asset
Configuration changes, privileged approvals, and operational accountability
Dependency
Identity Gateway, approval workflow APR-NB-7, logging service LOG-NB-9
Trust Boundary
Normal workforce context to privileged administrative context
Assumption
Administrative actions require stronger authentication, narrow role assignment, and attributable approval evidence
Asset
Alerts, service-health evidence, authentication evidence, and investigation visibility
Dependency
Application, identity, queue, and logging sources
Trust Boundary
Operational systems to centralized observation context
Assumption
Telemetry arrives with enough freshness, provenance, and coverage to support defensive decisions
Analyze the Evidence
Threat Register
Notice that each record avoids offensive detail. The statements focus on an asset, a trust or dependency condition, a realistic consequence, current controls, uncertainty, and a defensive response. That is enough to demonstrate professional threat-model reasoning in a school portfolio.
If the external portal accepts an authenticated session but the API does not enforce resource-level authorization, one user context could receive a fictional profile record that belongs to another account.
Evidence / reason
Architecture review shows the portal relies on API-NB-14 for final authorization; no independent portal-side assumption should replace the API control.
Current controls
Identity Gateway authentication, API authorization policy, application logging
Uncertainty
The portfolio evidence does not include a production configuration; the model therefore records the control as a design requirement rather than claiming implementation proof.
Defensive response
Keep authorization enforcement at the API, document resource ownership rules, log denied and allowed decisions, and require owner validation of the design.
If administrative role membership becomes stale, an identity that no longer requires elevated access could retain the ability to change sensitive fictional configuration.
Evidence / reason
The admin console crosses a higher-trust boundary and depends on role ownership plus approval records.
Current controls
Restricted role, stronger authentication, approval workflow, administrative logging
Uncertainty
The review cadence is a governance assumption and must be confirmed by the fictional service owner.
Defensive response
Maintain named role owners, scheduled access review, expiration for temporary grants, approval evidence, and review of privileged activity.
If worker identity SVC-NB-8 receives permissions beyond its processing purpose, an error or unintended service action could affect a broader set of fictional records than necessary.
Evidence / reason
The worker can update downstream records and therefore operates with more authority than a read-only service.
Current controls
Dedicated service identity and scoped application role
Uncertainty
Exact permissions are intentionally not represented in this fictional student exercise.
Defensive response
Define minimum required capabilities, assign a named owner, review grants when the workload changes, and preserve evidence of authorization.
If the internal queue is unavailable or loses processing context, time-sensitive fictional updates could be delayed or processed inconsistently.
Evidence / reason
API-NB-14 depends on Q-NB-5 for asynchronous processing and the worker depends on the same queue.
Current controls
Queue health monitoring, worker status monitoring, retry policy concept, recovery procedure
Uncertainty
The exercise does not model exact throughput or failure thresholds.
Defensive response
Define service-level health criteria, preserve message context, monitor backlog condition, test recovery in an authorized synthetic environment, and document owner escalation.
If authentication or authorization telemetry is delayed or incomplete, defenders may not have enough evidence to evaluate unusual activity or validate a recovery decision.
Evidence / reason
MON-NB-3 receives data from identity, application, queue, and logging sources and is used for defensive review.
Current controls
Centralized telemetry and source-health monitoring
Uncertainty
The model does not assume that every event source has equal freshness or coverage.
Defensive response
Record required telemetry sources, monitor source health, identify evidence gaps explicitly, and avoid treating missing telemetry as proof that nothing occurred.
If an external identity trust remains enabled after its business relationship changes, identities from that relationship could retain access beyond the intended lifecycle.
Evidence / reason
IG-NB-4 depends on an approved federation configuration and maintained role mappings.
Current controls
Federation approval, relationship owner, role mapping, access review
Uncertainty
The fictional model does not include a live partner or real federation metadata.
Defensive response
Require named relationship ownership, lifecycle review, mapping validation, expiration or removal when the relationship ends, and evidence of the review.
If an application service reaches DS-NB-6 without the expected service identity or scope, protected fictional records could be exposed to an unintended workload context.
Evidence / reason
The data service sits behind a trust boundary and is expected to accept only designated application and administrative identities.
Current controls
Service identity, authorization policy, network segmentation concept, logging
Uncertainty
No real network path, address, or production policy is included in the exercise.
Defensive response
Document approved service identities, preserve least privilege, separate normal and administrative access, and validate the architecture through fictional review evidence.
If backup or recovery evidence is assumed rather than verified, the team could overestimate its ability to restore an important fictional service after disruption.
Evidence / reason
DS-NB-6 and the application workflow depend on documented recovery capability.
Current controls
Backup workflow, recovery ownership, service-health validation
Uncertainty
The student portfolio does not connect to any real backup or recovery system.
Defensive response
Define recovery objectives conceptually, assign an owner, use safe synthetic recovery exercises, and retain evidence that the recovery process was reviewed.
Analyze the Evidence
Prioritization
A mature threat model is selective. Teams rarely have unlimited time, and not every concern deserves the same response. Prioritization should explain why one issue matters more than another using context that a reviewer can understand.
How important is the fictional service, data, identity, or decision to users and business operations?
Caution: Importance should be grounded in the scenario, not inferred from a dramatic technical label.
What realistic confidentiality, integrity, availability, authenticity, accountability, safety, or operational effect could result?
Caution: Describe bounded consequences instead of assuming worst-case outcomes without evidence.
Which actors and contexts can legitimately reach the boundary or workflow?
Caution: Keep this architectural and conceptual; do not turn portfolio work into scanning or probing instructions.
How much authority does the identity, role, service, or workflow hold if something goes wrong?
Caution: Higher privilege increases the need for least privilege, ownership, review, and accountability.
Which preventive, detective, recovery, or governance controls already reduce the concern?
Caution: Do not count a control as effective merely because it appears in a diagram; distinguish design intent from validated evidence.
Does one identity, service, queue, logging source, or external relationship support several critical functions?
Caution: Shared dependencies can create correlated impact even when individual components look well protected.
How much of the concern is supported by supplied evidence versus assumption or missing information?
Caution: High uncertainty may call for better evidence, not automatically a higher or lower risk rating.
Can the fictional organization detect, contain conceptually, restore service, and validate recovery if the concern becomes real?
Caution: Recovery planning is part of threat modeling because prevention is never the only defensive layer.
Control Reasoning
A threat model becomes misleading when every control is described as though it prevents every problem. Different controls serve different roles. Some reduce the chance of an adverse event, some limit its scope, some improve detection, some support recovery, and some ensure that decisions remain owned and reviewable.
Authentication, authorization, validation, secure defaults, and segmentation can reduce the chance that an unapproved action reaches a protected asset.
Least privilege, separation of duties, narrow service roles, segmentation, quotas, and scoped access can reduce how much one failure or misuse can affect.
Logging, alerting, anomaly review, service-health monitoring, and source-health checks improve awareness when conditions depart from expectations.
Backups, failover, rollback planning, recovery procedures, owner communication, and validation criteria help restore trusted operation.
Access reviews, approvals, ownership, exception records, due dates, and risk acceptance keep decisions accountable over time.
Evidence review, testing in authorized synthetic environments, monitoring, and post-change checks help confirm that a control or recovery decision works as intended.
Evidence Discipline
Strong portfolio work does not pretend to have evidence that it does not have. Threat models often mix architecture facts, design requirements, assumptions, and future validation needs. Those categories should remain visible so the reader understands the confidence level of each finding.
| Category | Meaning | Portfolio example |
|---|---|---|
| Architecture fact | A relationship explicitly shown in the supplied fictional design. | API-NB-14 depends on IG-NB-4 for identity context. |
| Design requirement | A control or property the design should provide. | Resource-level authorization should be enforced by API-NB-14. |
| Assumption | A condition believed to be true but not fully proven in the supplied evidence. | Privileged role membership is reviewed on an appropriate schedule. |
| Unknown | A missing fact that affects confidence or priority. | Exact telemetry freshness for every fictional source is not specified. |
| Validation need | Evidence an authorized owner would need before claiming a control is effective. | Review evidence should confirm privileged-role ownership and lifecycle. |
Portfolio Workflow
State the purpose, scope, fictional organization, included services, excluded areas, audience, and security objectives before listing threats.
Portfolio output: A short scope statement plus the security diagram from A19.2 or a simplified derivative.
Name what matters, who or what interacts with it, where trust changes, and which privileges or dependencies deserve closer attention.
Portfolio output: Asset table, actor list, trust-boundary annotations, and key assumptions.
Describe plausible adverse events in terms of asset, condition, security property, consequence, and defensive response.
Portfolio output: A curated threat register with clear evidence and uncertainty notes.
Map each material concern to the controls that prevent, detect, limit, recover, or govern it. Note where control evidence is incomplete.
Portfolio output: Control mapping and gap notes without pretending design intent equals implementation proof.
Use impact, privilege, exposure, dependencies, control strength, evidence confidence, and recovery readiness to decide what deserves attention first.
Portfolio output: A defensible priority order with short rationale rather than unexplained colors or scores.
Turn high-priority findings into specific defensive improvements with responsible roles, validation evidence, and review points.
Portfolio output: Owned recommendations linked back to threat IDs.
Remove or fictionalize anything that could expose real internal architecture, credentials, private records, security weaknesses, or confidential incident information.
Portfolio output: A publication-safe final model and a short revision note.
Safe Fictional Lab
Use the supplied architecture and threat records as if you were reviewing a design document. Do not test anything. Your job is to decide which statements are well-supported, which assumptions need owner confirmation, which controls are missing or under-specified, and which findings deserve the highest defensive priority.
Write a six-to-eight sentence scope statement naming the fictional service, users, assets, zones, dependencies, and explicit exclusions.
Select four trust boundaries from the model and explain what should be re-verified when identity, authority, data, or responsibility crosses each one.
Choose five THR-NB records and rewrite each in your own words while preserving the asset, condition, consequence, evidence, uncertainty, and defensive response.
Classify the controls for those five records as prevent, limit, detect, recover, validate, or govern. A control may serve more than one role if you explain why.
Choose the top three concerns and justify the order using impact, privilege, exposure, dependencies, control strength, uncertainty, and recovery readiness.
Assign a fictional accountable role to each priority recommendation and define the evidence that would show the review action is complete.
Scenario Decision Lab
The fictional admin console is restricted and uses stronger authentication, but the threat model cannot confirm how often privileged membership is reviewed.
Scenario Decision Lab
The fictional model expects identity and API logs to support detection, but one synthetic review note says source freshness is not yet documented.
Advanced Challenge
A good threat model should survive questions from people with different priorities. Prepare a short explanation for each fictional reviewer below. Keep the technical facts consistent while changing the emphasis to fit the audience.
Explain the most important trust boundaries, privilege decisions, control assumptions, and architecture changes. Be ready to show which threat IDs support each recommendation.
Explain business impact, dependencies, ownership gaps, recovery needs, and which changes should be prioritized without overwhelming the reader with every technical detail.
Explain how the artifact demonstrates structured reasoning, evidence discipline, ethical boundaries, communication, revision, and clear separation between design requirements and validated evidence.
Defender Habits
Assessment
Answer all seven questions before reviewing the explanations. Focus on purpose, trust boundaries, evidence discipline, bounded threat statements, prioritization, controls, uncertainty, and publication safety.
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a polished fictional Northbridge Threat Model Project. Include scope, security objectives, a simplified system diagram or architecture summary, assets, actors, trust boundaries, dependencies, assumptions, at least six bounded threat statements, control mapping, a top-three priority section with rationale, defensive recommendations with owners and validation evidence, key unknowns, and a short revision note.
Confidence / Readiness Reflection
A19.5 moves into the Risk Assessment Project. Before continuing, make sure you can explain how threat modeling identifies and organizes defensive concerns before risk assessment turns those concerns into business-oriented decisions about likelihood, impact, treatment, ownership, and residual risk.
I can explain how a threat model differs from a security diagram, vulnerability list, incident report, and risk register.
I can identify assets, actors, trust boundaries, dependencies, controls, assumptions, and unknowns in a fictional design.
I can write a bounded threat statement without turning it into offensive instructions or an unsupported incident claim.
I can prioritize concerns using context such as impact, privilege, exposure, controls, dependencies, uncertainty, and recovery.
I can explain why a portfolio artifact should distinguish design intent from validated implementation evidence.
Portfolio Build Guide
A reviewer should understand the fictional service, who uses it, what it protects, and why it matters before reading individual threats.
You do not need a brand-new architecture. Add trust boundaries, assets, assumptions, and threat IDs to a simplified version of the existing fictional diagram.
A smaller set of well-reasoned threats is more professional than dozens of vague possibilities. Choose concerns that teach something about trust, privilege, dependencies, or resilience.
IDs make it easier to connect the diagram, threat register, priority decisions, recommendations, and revision notes without repeating full paragraphs everywhere.
Use labels such as confirmed architecture fact, design requirement, assumption, unknown, or validation need so the reader understands what the model can and cannot prove.
A color or score can help scanning, but include a short reason tied to impact, privilege, exposure, controls, dependency concentration, evidence confidence, or recovery.
A recommendation should identify who is accountable and what evidence would demonstrate that the review action has been completed.
A professional student portfolio uses fictional architecture and safe abstraction. Real internal diagrams, private identifiers, credentials, or unpatched weaknesses should never be used as proof of skill.
Key Takeaways
Lesson Safety Boundary
Do not scan, probe, enumerate, exploit, fuzz, guess credentials, test access, bypass controls, collect private data, change configurations, or investigate real systems for this lesson. Do not publish real internal diagrams, credentials, private records, security weaknesses, or confidential architecture details. Use only the synthetic Northbridge systems and evidence supplied in the curriculum. The purpose is to practice architecture reasoning, trust analysis, control design, prioritization, governance, and professional portfolio communication safely.
Lesson Complete
You now have the structure for a portfolio-ready threat model that connects architecture, assets, trust boundaries, assumptions, controls, priorities, ownership, and safe publication. Next, A19.5 converts this kind of security concern into a formal Risk Assessment Project.