I9.2 Threat Modeling and Attack Surface Review
Learn how fictional development teams map assets, users, data flows, trust boundaries, entry points, dependencies, privileges, misuse cases, existing controls, evidence gaps, business impact, and residual risk before choosing and validating defensive controls.
Lesson Progress
Threat Modeling and Attack Surface Review
High School Intermediate • I9: Secure Coding Basics • Lesson 2 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
Threat Modeling Makes Security Decisions Visible Before Failure
A fictional application may have strong login controls while a teacher can request another teacher’s record. A secure API may still send data to an overbroad third-party integration. A protected administrator route may rely on an unreviewed recovery process. Threat modeling asks where assumptions change, what could fail, which controls exist, what evidence supports them, and who owns the risk.
Weak model
“The fictional application is internal and uses login, so the remaining risk is low.”
Strong model
“Map each identity, object, route, trust boundary, privileged action, data flow, dependency, control, misuse case, evidence source, owner, and residual risk.”
Objective 1
Explain how fictional threat modeling connects users, assets, data flows, trust boundaries, entry points, dependencies, privileges, misuse cases, and business impact.
Objective 2
Distinguish attack surface, threat event, weakness, control, evidence, likelihood, impact, residual risk, assumption, and evidence gap.
Objective 3
Build a fictional data-flow and trust-boundary model for a web application without probing, exploiting, or testing any real system.
Objective 4
Prioritize fictional risks using evidence strength, exposure, control effectiveness, asset value, business consequence, and remediation ownership.
Objective 5
Create a professional fictional Threat Model and Attack Surface Review with findings, owners, validation, monitoring, exceptions, and closure criteria.
Why This Matters
The Most Important Risks Often Appear Between Components
Fictional security failures frequently occur when one component trusts another component’s identity, role, input, output, route, destination, session, file, secret, or business decision. By mapping transitions and assumptions, teams can choose controls before unsafe patterns become difficult to remove and can design evidence that proves whether those controls work.
Asset Review
Eight Assets with Different Protection Needs
Student-support records
Fictional nonpublic summaries and case notes used by teachers and authorized support staff.
Security needs
Confidentiality, object authorization, tenant isolation, accurate updates, limited retention, controlled export, and auditability.
Failure impact
Unauthorized viewing, incorrect changes, privacy harm, loss of trust, or reporting errors.
Owner: Student Services Technology
Teacher and administrator identities
Fictional accounts, roles, factors, devices, sessions, permissions, and recovery state.
Security needs
Strong authentication, secure recovery, session rotation, revocation, least privilege, and access review.
Failure impact
Unauthorized actions, wrong-role access, account misuse, or inability to attribute activity.
Owner: Identity and Access Team
Application API
Fictional service enforcing input contracts, authorization, workflow rules, and data access.
Security needs
Schema validation, object authorization, safe operations, rate controls, error safety, logging, and service identity.
Failure impact
Data exposure, incorrect updates, service abuse, broken workflows, or unreliable evidence.
Owner: Web Platform Team
Reporting and export workflow
Fictional district reports, export jobs, files, approvals, and business records.
Security needs
Privileged access, reauthentication, dual approval, idempotency, secure files, expiry, and monitoring.
Failure impact
Unapproved data export, duplicate actions, incorrect reporting, or privacy and compliance impact.
Owner: District Applications Team
Announcement and messaging content
Fictional plain text, approved rich text, notifications, previews, and audience selections.
Security needs
Safe rendering, sanitization, approval, destination control, audience authorization, and browser policy.
Failure impact
Misleading content, unsafe rendering, wrong audience, deceptive links, or operational confusion.
Owner: Communications Technology
Secrets and service identities
Fictional API credentials, signing keys, database identities, certificate keys, and deployment identities.
Security needs
Managed storage, narrow access, rotation, audit logging, no code exposure, and retirement.
Failure impact
Service impersonation, unauthorized data access, deployment compromise, or loss of trust.
Owner: Platform Engineering
Application availability
Fictional login, record access, support workflows, reporting, recovery, and monitoring services.
Security needs
Capacity controls, graceful failure, dependency resilience, rollback, recovery, and health monitoring.
Failure impact
Interrupted support, delayed decisions, user frustration, operational cost, or missed deadlines.
Owner: Infrastructure Operations
Security and audit evidence
Fictional request IDs, identity events, application decisions, database transactions, alerts, cases, and owner approvals.
Security needs
Integrity, time accuracy, privacy, retention, access control, source health, correlation, and safe display.
Failure impact
Weak investigations, missing accountability, false conclusions, delayed response, or unsupported closure.
Owner: Security Operations
Trust Boundaries
Eight Places Where Assumptions Must Be Revalidated
Public browser to reverse proxy
Fictional requests move from an untrusted client environment into owned infrastructure.
Required checks
TLS, host validation, request limits, safe headers, method rules, content type, routing, request ID, and edge logging.
Assumption
The reverse proxy is the only approved external entry point.
Evidence
DNS, certificate, listener, route policy, request logs, and architecture inventory.
Reverse proxy to application API
Fictional network and forwarding context becomes application identity, session, route, object, and business context.
Required checks
Trusted forwarded headers, authenticated session, input schema, authorization, anti-forgery control, and safe errors.
Assumption
Only approved proxies can set trusted client and scheme headers.
Evidence
Proxy trust configuration, application logs, route tests, and deployment template.
Application API to identity service
Fictional application requests depend on external identity claims, factors, session state, and risk decisions.
Required checks
Issuer, audience, signature, time, account state, factor, session, revocation, and application policy.
Assumption
The application validates current identity metadata rather than trusting client-supplied role claims.
Evidence
Identity configuration, token metadata, session logs, policy records, and negative tests.
Application API to database
Fictional user intent becomes service-authorized data operations under a service identity.
Required checks
Object and tenant authorization, prepared operations, least privilege, transaction rules, row limits, and audit logging.
Assumption
The database accepts requests only from approved service identities.
Evidence
Service policy, prepared-operation record, database logs, network policy, and access review.
Application to third-party integration
Fictional owned data and requests move to a provider with separate ownership and security practices.
Required checks
Business need, exact destination, authentication, minimum data, schema validation, timeout, retry, error handling, monitoring, and contract ownership.
Assumption
The provider handles only the approved data and does not become a trusted authorization source.
Evidence
Integration inventory, data-flow record, contract, configuration, test, and provider-owner review.
Administrator to privileged function
Fictional ordinary authenticated access becomes high-impact export, role, account, configuration, or recovery authority.
Required checks
Privileged role, reauthentication, step-up verification, dual approval, confirmation, idempotency, and enhanced logging.
Assumption
Privileged actions cannot be completed through ordinary user routes.
Evidence
Role policy, approval record, session event, transaction log, and positive and negative tests.
Stored content to browser rendering
Fictional database or message content becomes HTML text, rich text, attribute, URL, preview, notification, or export output.
Required checks
Output-context handling, safe binding, sanitization, destination allowlist, content policy, isolation, and viewer review.
Assumption
Stored content is treated as untrusted at every new output boundary.
Evidence
Source-to-sink map, component review, sanitizer policy, browser result, and regression tests.
Production service to monitoring platform
Fictional operational events become centralized evidence used for detections and investigations.
Required checks
Structured fields, request correlation, redaction, source health, time normalization, retention, access control, and safe rendering.
Assumption
Monitoring receives complete and timely events from all critical paths.
Evidence
Source inventory, parser status, event counts, time checks, retention, and access review.
Core Concept
Use the Asset–Flow–Boundary–Threat–Control Chain
Asset
Which fictional data, identity, service, secret, workflow, decision, or evidence needs protection?
Flow
Where does the fictional asset move, transform, wait, render, or become a business action?
Boundary
Where do fictional identity, ownership, privilege, or trust assumptions change?
Threat
Which fictional misuse, failure, mistake, defect, dependency, or unsafe condition could occur?
Control
Which fictional design, code, configuration, process, monitoring, or owner reduces the risk?
Evidence
Which fictional test, log, transaction, owner review, and business record proves the result and residual risk?
Attack Surface
Eight Entry-Point Groups to Review
Sign-in and recovery
Inputs and actions
Fictional account identifiers, factors, recovery evidence, devices, sessions, and redirects.
Threats
Account guessing, unsafe recovery, session fixation, misleading redirects, or weak revocation.
Controls
MFA, rate controls, recovery separation, rotation, safe redirects, device and risk policy, and monitoring.
Validation
Approved sign-in and recovery work; invalid factors, expired sessions, unapproved redirects, and disabled accounts fail.
Record lookup and editing
Inputs and actions
Fictional record IDs, filters, fields, text, attachments, and workflow actions.
Threats
Unassigned record access, wrong-tenant access, invalid updates, unsafe files, or excessive data exposure.
Controls
Server-side object authorization, schemas, file policy, least privilege, field allowlists, and safe errors.
Validation
Assigned records work; unassigned, wrong-tenant, malformed, excessive, and unauthorized requests fail before data access.
Search and reporting
Inputs and actions
Fictional queries, filters, sort choices, date ranges, page sizes, report types, and export requests.
Threats
Dynamic construction, excessive resource use, unapproved export, duplicate jobs, or sensitive result exposure.
Controls
Strict schemas, server-defined mappings, bound values, quotas, privileged approval, idempotency, and secure files.
Validation
Approved reports work; unsupported choices, excessive ranges, unauthorized roles, and duplicate submissions do not create extra results.
Announcements and messages
Inputs and actions
Fictional plain text, approved rich text, links, audience selection, scheduling, and previews.
Threats
Unsafe rendering, misleading destinations, wrong audience, unauthorized publishing, or stale content.
Controls
Safe binding, narrow sanitization, destination allowlists, audience authorization, approval, expiry, and content policy.
Validation
Approved formatting and audience work; unsupported content and unauthorized publishing are denied.
File upload and download
Inputs and actions
Fictional documents, names, metadata, content types, storage locations, previews, and download actions.
Threats
Unsafe content, misleading files, oversized uploads, public exposure, path mistakes, or long-lived download links.
Controls
Type and size policy, isolated processing, safe names, private storage, authorization, expiry, and viewer isolation.
Validation
Approved files work; unsupported, oversized, unauthorized, expired, and cross-tenant access fail safely.
Administrative console
Inputs and actions
Fictional role changes, account state, exports, configuration, recovery, and approval actions.
Threats
Privilege misuse, hidden sensitive actions, stale sessions, duplicate approvals, or overbroad access.
Controls
Privileged roles, reauthentication, dual approval, confirmation, idempotency, route gating, and detailed evidence.
Validation
Approved administrators succeed; ordinary users, stale sessions, missing approvals, and duplicate requests fail.
API and integration
Inputs and actions
Fictional tokens, service identities, JSON data, callbacks, webhooks, third-party responses, and retries.
Threats
Wrong audience, overbroad scopes, replay, untrusted callbacks, schema drift, or provider outage.
Controls
Exact identity and audience checks, schema validation, replay controls, destination allowlists, timeouts, retries, and monitoring.
Validation
Approved integration messages work; wrong identity, malformed, duplicate, expired, and unapproved-destination cases fail.
Operations and deployment
Inputs and actions
Fictional builds, packages, images, feature flags, environment variables, secrets, migrations, and configuration changes.
Threats
Unsafe dependency, secret exposure, debug mode, drift, wrong identity, excessive ports, or failed rollback.
Controls
Artifact verification, managed secrets, secure baselines, peer approval, least privilege, smoke tests, monitoring, and rollback.
Validation
Approved build and configuration deploy; altered artifacts, debug settings, unnecessary services, and failed health checks block release.
Threat Categories
Eight Questions for Defensive Review
Identity misuse
Could a fictional user, service, device, or session be mistaken for another identity or retain access after trust changes?
Fictional examples
Weak recovery, stale sessions, shared accounts, overbroad service identities, or unvalidated identity claims.
Control focus
MFA, secure recovery, session rotation and revocation, named identities, claim validation, and access review.
Authorization failure
Could a fictional authenticated identity access another object, tenant, action, workflow state, or privilege level?
Fictional examples
Missing object checks, client-trusted roles, exposed administrator routes, or inconsistent API enforcement.
Control focus
Central server-side authorization, tenant isolation, trusted object resolution, least privilege, and negative tests.
Unsafe data interpretation
Could fictional data become query structure, command structure, markup, navigation, file behavior, or configuration?
Fictional examples
Dynamic queries, raw markup, untrusted destinations, unsafe filenames, or configuration injection.
Control focus
Schemas, strict allowlists, parameterization, safe APIs, context output handling, and isolated processing.
Information exposure
Could fictional private data, secrets, internal details, or evidence be returned, logged, cached, exported, or shared too broadly?
Fictional examples
Verbose errors, parent-domain cookies, overbroad exports, secret logging, or public download links.
Control focus
Data minimization, safe errors, redaction, access control, private storage, cache policy, and retention limits.
Integrity and workflow abuse
Could fictional data, approvals, roles, transactions, or records be changed incorrectly or without clear user intent?
Fictional examples
Request forgery, duplicate approval, missing confirmation, weak business rule, or stale workflow state.
Control focus
Anti-forgery controls, authorization, confirmation, reauthentication, idempotency, transaction rules, and audit logs.
Availability and resource exhaustion
Could fictional requests, files, queries, dependencies, retries, or administrative actions reduce service availability?
Fictional examples
Excessive search range, oversized upload, retry storm, slow dependency, unbounded export, or missing capacity limit.
Control focus
Bounds, quotas, timeouts, circuit breaking, queues, graceful failure, capacity monitoring, and recovery.
Dependency and configuration risk
Could fictional packages, services, build steps, runtime settings, certificates, or manual changes weaken the application?
Fictional examples
Unsupported runtime, debug mode, exposed port, stale certificate, broad permission, or compromised package source.
Control focus
Inventory, lockfiles, trusted sources, supported versions, secure baselines, drift detection, and rollback.
Evidence and accountability failure
Could fictional actions occur without reliable identity, request, decision, object, transaction, time, or owner evidence?
Fictional examples
Missing request IDs, incomplete logs, parser failure, shared accounts, weak retention, or unowned alerts.
Control focus
Structured logs, correlation, time accuracy, named identities, source health, retention, access control, and case governance.
Risk Prioritization
Eight Factors for an Evidence-Based Priority
Asset value
Lower concern
Fictional public or low-impact content with easy recovery.
Higher concern
Fictional nonpublic student data, privileged identity, secrets, exports, or critical support workflows.
Evidence
Data classification, business owner, workflow dependency, recovery requirement, and impact statement.
Exposure
Lower concern
Fictional isolated test feature available only to a small approved group.
Higher concern
Fictional public route, broad authenticated population, third-party integration, or internet-facing service.
Evidence
Route inventory, listener, user population, integration list, network path, and access policy.
Exploitability or misuse difficulty
Lower concern
Fictional issue requires several privileged approvals and unusual conditions.
Higher concern
Fictional issue occurs through ordinary browser requests, common user actions, or default workflow behavior.
Evidence
Preconditions, roles, sessions, route behavior, required approvals, and supplied safe test results.
Existing control strength
Lower concern
Fictional independent controls prevent or limit the result and are validated.
Higher concern
Fictional controls are missing, inconsistent, bypassable, unmonitored, or unsupported by evidence.
Evidence
Design, code, configuration, control decisions, positive tests, negative tests, and monitoring.
Scope
Lower concern
Fictional one user, one object, one test environment, or one isolated path.
Higher concern
Fictional many users, tenants, records, routes, environments, or shared services.
Evidence
Affected inventory, user count, object count, tenant list, route list, and deployment map.
Business consequence
Lower concern
Fictional minor inconvenience with no sensitive data or critical workflow effect.
Higher concern
Fictional privacy harm, incorrect decision, unapproved payment, loss of evidence, outage, or legal and trust impact.
Evidence
Business owner, transaction state, user effect, data state, availability, and policy requirement.
Detection and response
Lower concern
Fictional activity is reliably logged, alerted, owned, investigated, and reversible.
Higher concern
Fictional activity may be silent, unattributed, retained briefly, or difficult to reverse.
Evidence
Source health, rule coverage, owner, retention, case process, rollback, and recovery evidence.
Evidence confidence
Lower concern
Fictional conclusion depends on assumptions, stale diagrams, missing logs, or one ambiguous event.
Higher concern
Fictional multiple independent sources support the same conclusion and limitations are documented.
Evidence
Source count, raw records, normalized timeline, user confirmation, system-of-record state, and evidence gaps.
Threat-Model Workflow
Build and Maintain the Model in Six Steps
Define scope and assets
List fictional users, data, identities, secrets, services, workflows, environments, owners, and business consequences.
Map data and trust boundaries
Draw fictional sources, destinations, protocols, transformations, identities, privilege changes, and storage locations.
Inventory attack surface
Review fictional routes, APIs, files, messages, integrations, administrative paths, dependencies, services, and deployments.
Describe misuse and controls
Write fictional threat events, preconditions, affected assets, existing controls, evidence, alternatives, and gaps.
Prioritize and assign
Evaluate fictional exposure, asset value, control strength, scope, business effect, reversibility, confidence, owner, and due date.
Validate and maintain
Run fictional positive and negative tests, monitor, update after changes, review exceptions, prepare rollback, and document residual risk.
Traceable Threat Timeline
Follow a Fictional Object-Authorization Threat from Model to Monitoring
Day 1
Scope
A fictional team defines the student-support portal, administration console, identity service, API, database, proxy, and monitoring platform.
The initial system boundary and major owners are established.
Day 2
Asset review
Student-support records, privileged identities, exports, secrets, availability, and audit evidence are classified as important assets.
Protection priorities are connected to business value.
Day 3
Data flow
The fictional browser sends record requests through the proxy and API to the reporting database.
Several trust boundaries and evidence sources are identified.
Day 4
Attack surface
The team inventories sign-in, recovery, record access, reports, announcements, files, APIs, administrator routes, and deployment paths.
The reachable feature set is documented.
Day 5
Misuse case
TM-07 describes a teacher requesting another teacher’s assigned student record.
An object-authorization failure scenario is made specific and testable.
Day 6
Existing control
The fictional route verifies authentication and role but does not resolve the trusted assignment relationship.
The existing control is incomplete.
Day 7
Negative test
A fictional teacher retrieves an unassigned record in the safe test environment.
The threat event produces a confirmed unauthorized result under the supplied conditions.
Day 8
Risk review
The team rates the issue high because the data is nonpublic, the route is broadly available to teachers, and the result is reproducible.
Asset value, exposure, control weakness, and evidence strength drive priority.
Day 9
Containment
The feature is blocked from release while the central authorization policy is corrected.
A narrow release control prevents known exposure.
Day 10
Remediation
The server resolves tenant, record, assignment, role, action, and session using trusted data.
The control now matches the misuse case and security requirement.
Day 11
Positive test
A fictional teacher can retrieve an assigned record.
Legitimate workflow remains available.
Day 11
Negative test
Unassigned, wrong-tenant, wrong-role, expired-session, and missing-session requests are denied before data access.
Several related misuse cases are controlled.
Day 12
Threat model update
The data-flow diagram, attack-surface inventory, risk record, tests, and owner status are updated.
The threat model becomes traceable to remediation and validation.
Day 19
Monitoring
Assigned access remains normal and no unexplained cross-tenant result appears.
Short-term operational evidence supports the control.
Day 30
Change review
A new third-party messaging integration triggers a threat-model and data-flow update.
The model remains a living lifecycle artifact.
Key Vocabulary
Threat Modeling and Attack Surface Terms
Threat model
A fictional structured review of assets, users, data, components, trust boundaries, entry points, dependencies, possible failures, controls, and residual risk.
Attack surface
The fictional collection of reachable interfaces, features, accounts, services, files, dependencies, trust transitions, and administrative paths that could affect security.
Asset
A fictional system, data set, identity, secret, service, workflow, decision, or business capability that requires protection.
Trust boundary
A fictional transition where data, identity, privilege, ownership, or control assumptions change and must be revalidated.
Entry point
A fictional interface through which data, requests, files, messages, users, services, or administrators interact with the system.
Threat event
A fictional condition or action that could cause loss of confidentiality, integrity, availability, privacy, accountability, or business trust.
Misuse case
A fictional scenario describing how a feature, role, workflow, dependency, or integration could be used incorrectly, abused, or misunderstood.
Existing control
A fictional design, code, configuration, process, monitoring, or governance measure already reducing the risk.
Residual risk
The fictional risk remaining after existing and planned controls are considered.
Assumption
A fictional statement believed to be true for the model but requiring validation or periodic review.
Evidence gap
A fictional missing, stale, inconsistent, or unavailable record that limits confidence in the threat model or risk decision.
Abuse case
A fictional defensive test scenario that checks how the system behaves when inputs, identities, objects, timing, or workflows are used in an unsafe or unauthorized way.
Fake Dashboard
Fake Threat Model and Attack Surface Dashboard
Training dashboard for the fictional Meadowbrook student-support portal.
Modeled assets
24
Fictional data, identities, services, secrets, workflows, availability, and evidence assets.
Trust boundaries
17
Browser, proxy, application, identity, database, third-party, privileged, rendering, and monitoring transitions.
Open threat items
9
Authorization, input, rendering, recovery, export, dependency, configuration, availability, and evidence-gap reviews.
Fake SOC Alert
Threat Model Finds Missing Object-Assignment Check
Source: Fake Threat Modeling Review Console • Time: 10:30 AM
Fake Log Panel
Fake Threat Model Traceability Timeline
DAY1 SCOPE systems='portal,admin,identity,api,database,proxy,monitoring' DAY2 ASSET student_support_records='high_value' DAY3 DATA_FLOW browser='proxy' proxy='api' api='database' DAY4 ATTACK_SURFACE entries='signin,records,reports,announcements,files,api,admin,deploy' DAY5 MISUSE_CASE id='TM-07' scenario='teacher_unassigned_record' DAY6 CONTROL authentication='present' role_check='present' assignment_check='missing' DAY7 NEGATIVE_TEST unassigned_record='allowed' DAY8 RISK asset='nonpublic' exposure='teacher_population' reproducible='true' priority='high' DAY9 RELEASE_GATE result='blocked' DAY10 REMEDIATE tenant='verified' assignment='verified' object='verified' action='verified' DAY11 POSITIVE_TEST assigned_record='pass' DAY11 NEGATIVE_TEST unassigned='deny' wrong_tenant='deny' wrong_role='deny' expired='deny' DAY12 MODEL_UPDATE data_flow='updated' risk='updated' tests='linked' owner='assigned' DAY19 MONITOR unexplained_cross_tenant_results='0' DAY30 CHANGE_REVIEW third_party_messaging='model_update_required'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Threat-Model Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Threat Models
Safe Practice Lab
Build a Fictional Threat Model and Attack Surface Review
Fictional Evidence Set
Meadowbrook Student-Support Portal
Review forty-two supplied fictional records covering assets, users, data flows, trust boundaries, entry points, dependencies, identities, privileges, misuse cases, code and configuration controls, tests, monitoring, owners, exceptions, and residual risk.
Required Analysis
- Define fictional scope, owners, environments, users, assets, data, secrets, and business workflows.
- Create a data-flow diagram with sources, destinations, protocols, identities, storage, transformations, and trust boundaries.
- Inventory routes, APIs, files, messages, third parties, administrative paths, dependencies, services, and deployments.
- Write at least eight misuse cases with preconditions, assets, controls, evidence, alternatives, and gaps.
- Prioritize risks using asset value, exposure, control strength, scope, business consequence, detection, reversibility, and confidence.
- Document owners, remediation, positive tests, negative tests, monitoring, rollback, exceptions, residual risk, and closure criteria.
Scenario Decision Lab
A Threat Model Assumes Internal Users Are Trusted
A fictional design note says object authorization is unnecessary because only teachers can access the application.
Scenario Decision Lab
A New Third-Party Messaging Integration Is Proposed
A fictional provider will receive selected announcement text and audience identifiers, but the existing threat model does not include the provider.
Defender Habits
Threat Modeling and Attack Surface Review Checklist
Check Your Understanding
I9.2 Mini Quiz: Threat Modeling and Attack Surface Review
Choose your answers first. Explanations appear only after submission.
1. What is the primary purpose of a fictional threat model?
2. What makes a fictional trust boundary important?
3. Which item belongs in an attack-surface inventory?
4. A fictional route checks authentication but not object assignment. What is the strongest conclusion?
5. Which risk-prioritization approach is strongest?
6. When should a fictional threat model be updated?
7. Which portfolio practice is safest?
Portfolio Prompt
Portfolio Prompt
Create a fictional Threat Model and Attack Surface Review using at least forty-two architecture, asset, user, data-flow, trust-boundary, route, API, file, integration, dependency, misuse-case, control, test, monitoring, owner, exception, and residual-risk records. Include an architecture diagram, data-flow map, attack-surface inventory, eight misuse cases, risk ranking, evidence references, owners, remediation, positive tests, negative tests, rollback, evidence gaps, and closure criteria.
Key Takeaways
What You Should Remember
Navigation