High School AdvancedModule A3Lesson 3 of 10System Flow and Trust Analysis

A3.3 Data Flows and Trust Boundaries

Learn how professional defenders map fictional information, requests, identity assertions, events, files, decisions, administrative actions, evidence, failures, and recovery activity. Mark where trust assumptions change and connect every important boundary crossing to purpose, ownership, validation, authorization, privacy, monitoring, failure handling, evidence, uncertainty, and review.

Previous Lesson Module A3 Next Lesson

Lesson Progress

Data Flows and Trust Boundaries

High School Advanced • A3: Threat Modeling • Lesson 3 of 10

30% complete

Readiness Check

Before You Start

0/6 ready

Professional Hook

The Most Important Security Question May Be Hidden inside an Arrow

A fictional Northbridge diagram shows one arrow labeled “Data” from the student-support portal to an external processing supplier. That arrow does not explain which actor initiated the request, which identity represents the portal, which fields move, why they are needed, which trust assumptions change, which validations occur, what the supplier returns, how delayed or duplicate results are handled, which evidence exists, who owns each side, or how the integration is retired.

Weak flow description

“Portal sends data to supplier.” This hides purpose, fields, identity, authority, ownership, validation, privacy, evidence, failure, recovery, and lifecycle.

Decision-ready flow

“The fictional portal processing service uses one managed service identity to send a minimized case reference and document category through the approved supplier interface for document classification; both sides validate schema, authority, result, source health, failure state, and evidence.”

A trust boundary is not automatically dangerous. It is a place where the model must make assumptions, ownership, controls, evidence, failure behavior, and uncertainty explicit.

Exactly Five Learning Objectives

What You Will Be Able to Do

Objective 1

Create clear fictional data-flow diagrams that identify actors, processes, stores, transfer paths, destinations, owners, purposes, and system states.

Objective 2

Recognize meaningful fictional trust changes involving identity, authority, ownership, sensitivity, location, technology, administration, supplier relationships, and recovery conditions.

Objective 3

Document fictional trust boundaries with entry conditions, validation, authorization, monitoring, privacy, failure handling, recovery, evidence, assumptions, and review triggers.

Objective 4

Evaluate fictional flow evidence without treating diagrams, logs, dashboards, alerts, or architecture records as complete proof of actual behavior or control effectiveness.

Objective 5

Produce a portfolio-ready fictional data-flow and trust-boundary package that remains ethical, defensive, non-operational, privacy-safe, and completely invented.

Why This Matters

Flow Context Turns a Component List into a Security Model

A3.2 identified fictional assets, actors, and entry points. A3.3 connects them in motion. The model must show which actor uses which interface to send which request or information to which process or store, for which purpose, under which authority, across which trust change, with which controls, evidence, failure behavior, owners, and recovery path.

Without flow context

Teams cannot tell which actor affects which asset, which data is exposed, or which control should apply.

Without boundaries

Teams may accept identity, authority, data, supplier results, configuration, or recovery state without making trust assumptions visible.

Without evidence

Teams cannot distinguish intended design from current behavior, failure, delay, missing telemetry, or stale documentation.

Core Framework

The Six-Layer Data-Flow and Trust Model

1. Purpose

Why the fictional interaction exists, which mission or user outcome it supports, and who approved that purpose.

2. Participants

Which actors, services, devices, suppliers, processes, and stores originate, transform, receive, or observe the interaction.

3. Content and state

Which fields, files, events, assertions, commands, decisions, metadata, and statuses move, including timing, ordering, freshness, and retry state.

4. Trust change

Which identity, authority, ownership, sensitivity, environment, technology, supplier, administration, location, or recovery assumption changes.

5. Controls and evidence

Which validation, authorization, minimization, segmentation, monitoring, failure, recovery, and source-health checks support safe use.

6. Ownership and lifecycle

Who owns each side, which assumptions remain, how changes are reviewed, and how the flow, identity, interface, copy, or rule is retired.

Complete flow statement template

The fictional source actor uses a documented identity to send a defined request or information set through an approved entry point to a destination process or store for a documented purpose. The interaction crosses a named trust boundary, is validated and authorized under stated conditions, produces reviewable evidence, fails safely, supports recovery, and has owners, assumptions, confidence, and review triggers.

Advanced Vocabulary

Terms for Precise Flow and Boundary Reasoning

Data flow

A fictional movement of information, a request, an identity assertion, an event, a file, a command, a decision, or a status update between actors, processes, services, or stores.

Process

A fictional component, service, workflow, or human-supported function that receives input, performs an approved transformation or decision, and produces an output.

Data store

A fictional location where information, state, configuration, evidence, backups, messages, or workflow records are retained for an approved purpose.

External entity

A fictional actor or service outside the immediate modeled process that sends or receives data, requests, decisions, or identity information.

Trust boundary

A fictional point where an important trust assumption changes, such as identity, authority, ownership, sensitivity, administration, location, technology, supplier responsibility, or recovery state.

Boundary crossing

A fictional interaction in which data, a request, an identity, or authority moves across a trust boundary and therefore requires explicit control and evidence questions.

Trust assumption

A documented fictional belief about identity, ownership, configuration, service state, data quality, authority, availability, or control operation that requires validation and review.

Source

The fictional actor, service, process, device, workload, supplier, or store from which a flow originates.

Destination

The fictional actor, service, process, device, workload, supplier, or store that receives a flow.

Flow purpose

The approved fictional business, service, security, privacy, operational, support, or recovery reason for the interaction.

Flow content

The fictional fields, records, files, assertions, status values, commands, metadata, or events carried by the interaction.

Transformation

The fictional change performed by a process, such as validation, classification, enrichment, approval, routing, storage, notification, or aggregation.

Validation

A fictional check that confirms the received data, request, file, identity assertion, event, or state meets defined format, meaning, source, timing, and business rules.

Authorization

A fictional decision about whether a specific actor or service may perform a specific action on a specific asset under defined conditions.

Data minimization

Limiting a fictional flow to the minimum fields and context needed for its approved purpose.

Protocol transition

A fictional change in communication method or service interface that may introduce new ownership, validation, monitoring, or failure assumptions.

Administrative boundary

A fictional boundary between different owners, teams, suppliers, organizations, accounts, projects, environments, or operational responsibilities.

Sensitivity boundary

A fictional change in data classification, privacy expectation, retention requirement, permitted use, or exposure.

Identity boundary

A fictional change in how an actor or service proves identity, receives authority, or carries trust into another component.

Recovery boundary

A fictional transition into backup, restoration, failover, emergency access, degraded operation, alternate processing, or post-recovery validation.

Flow evidence

Fictional records such as events, tickets, diagrams, interface definitions, approvals, source-health signals, validation results, queue records, and owner statements that support or limit a flow claim.

Flow state

The fictional status of an interaction, such as requested, accepted, validated, denied, queued, processing, completed, failed, retried, restored, or reconciled.

Data lineage

A fictional record of where information originated, which processes transformed it, where it was stored, who approved its use, and which outputs were derived from it.

Flow completeness

The degree to which a fictional model includes normal, failure, retry, support, administrative, supplier, degraded, recovery, archival, and deletion paths.

Instructional Section 1

Build the Diagram from Six Evidence-Aware Elements

A professional fictional data-flow diagram is more than a picture. Each visual element must support a clear statement about purpose, ownership, value, authority, interaction, control, evidence, uncertainty, and lifecycle.

Actors and external entities

Purpose in the model

Show fictional people, services, devices, suppliers, reviewers, administrators, support roles, and automation that originate or receive interactions.

What to record

Role, relationship, identity type, owner, authority, expected behavior, lifecycle, and connected assets.

Defender questions

Who or what initiates the flow? Who receives it? Which identity represents the actor? What authority and evidence are required?

Safety or quality warning

Do not use real names, accounts, email addresses, device identifiers, supplier records, or internal identity details.

Processes and services

Purpose in the model

Show fictional components that validate, authorize, transform, route, approve, enrich, classify, store, notify, reconcile, or recover information.

What to record

Purpose, owner, inputs, outputs, decision rules, dependencies, failure behavior, evidence, and lifecycle.

Defender questions

What transformation occurs? Which business rule is applied? What happens when validation fails or a dependency is unavailable?

Safety or quality warning

A process box is not proof that the process operates as documented or that controls are effective.

Data stores

Purpose in the model

Show fictional locations where records, workflow state, identity attributes, evidence, configuration, messages, backups, and archives are retained.

What to record

Data purpose, owner, classification, retention, deletion, access, integrity, recovery, copies, and evidence.

Defender questions

What is stored? Why? For how long? Who may use it? Which copies or derived records exist? How is correct recovery validated?

Safety or quality warning

Do not assume one database symbol represents every table, cache, backup, export, queue, archive, or derived data set.

Flow arrows

Purpose in the model

Show the fictional direction and purpose of requests, data, identity assertions, events, decisions, files, status updates, and administrative actions.

What to record

Source, destination, purpose, content, sensitivity, identity, authority, validation, timing, state, evidence, and failure behavior.

Defender questions

What moves? In which direction? Under which identity? Why is it needed? Which states and errors are possible?

Safety or quality warning

An unlabeled arrow hides the most important context needed for threat modeling.

Trust boundaries

Purpose in the model

Mark fictional points where trust assumptions change across identity, authority, ownership, sensitivity, location, technology, environment, supplier, administration, or recovery state.

What to record

Boundary type, owner, crossing flows, assumptions, controls, evidence, failure, recovery, unknowns, and review triggers.

Defender questions

What changed? Which trust is being accepted or transformed? Which control and evidence are required before the destination relies on the input?

Safety or quality warning

A network line is not automatically a trust boundary, and an important trust boundary may exist inside one network or application.

Evidence and health signals

Purpose in the model

Show how fictional teams know that flows are accepted, rejected, delayed, transformed, retried, failed, restored, or missing.

What to record

Source, event meaning, timestamp quality, actor, action, target, result, correlation, health, retention, access, and owner.

Defender questions

Can defenders answer who, what, when, where, why, result, and source-health questions? What evidence gaps remain?

Safety or quality warning

Logging presence does not prove completeness, integrity, correct interpretation, or active review.

Instructional Section 2

Recognize Eight Types of Meaningful Trust Change

The strongest fictional models do not mark a boundary merely because two boxes are separated. They explain exactly what trust assumption changes and what the destination must verify before relying on the interaction.

Identity trust boundary

Trust change

What changes

A fictional user, service, device, or supplier identity is authenticated, federated, translated, delegated, elevated, recovered, or represented in another component.

Fictional examples

Public user to portal session; service identity to internal API; federation assertion to local role; emergency identity to recovery console.

Defender questions

Which identity source is trusted? Which attributes and conditions are used? How is authority limited? What happens when identity context is stale or missing?

Control expectations

Strong identity proof, assertion validation, attribute minimization, conditional access, session controls, least privilege, lifecycle, monitoring, and recovery governance.

Evidence expectations

Authentication result, assertion source, attributes used, policy decision, session state, role mapping, lifecycle event, and failure reason.

Authorization boundary

Trust change

What changes

A fictional request moves from general access into an action that affects another user, sensitive record, configuration, workflow state, evidence source, or privileged function.

Fictional examples

Student viewing own case versus counselor reviewing assigned cases; support analyst viewing status versus changing notification settings.

Defender questions

Which actor may perform which action on which object under which condition, purpose, approval, duration, and separation requirement?

Control expectations

Object-level authorization, role and attribute checks, reason capture, approval, separation of duties, time limits, review, and denial evidence.

Evidence expectations

Actor, role, object, action, policy decision, condition, approval, reason, result, and review record.

Administrative ownership boundary

Trust change

What changes

A fictional flow crosses between different teams, suppliers, organizations, cloud accounts, environments, operational owners, or governance responsibilities.

Fictional examples

Portal team to processing supplier; application owner to identity platform; internal service to externally operated notification provider.

Defender questions

Who owns each side? Which responsibility transfers? Which data, controls, evidence, failure, recovery, and change obligations are shared?

Control expectations

Clear ownership, interface agreement, data minimization, service expectations, evidence rights, change notification, incident coordination, recovery, and exit planning.

Evidence expectations

Owner register, service agreement, approved fields, interface version, change record, health status, incident contact, and offboarding decision.

Sensitivity and privacy boundary

Trust change

What changes

Fictional information moves into a context with different classification, audience, purpose, retention, consent, exposure, or privacy expectation.

Fictional examples

User-uploaded record to support notes; case details to notification text; full record to minimized supplier request; operational event to analytics report.

Defender questions

Which fields are necessary? Does the destination have a compatible purpose? What data is derived? Which retention, deletion, masking, and access rules apply?

Control expectations

Classification, minimization, purpose limitation, field validation, audience control, access restrictions, retention, deletion, masking, and privacy review.

Evidence expectations

Field inventory, classification, approved purpose, consent or notice decision, access record, retention schedule, and deletion evidence.

Environment boundary

Trust change

What changes

A fictional flow moves across development, test, training, staging, production, disaster recovery, archive, or another environment with different data and control expectations.

Fictional examples

Synthetic training data to test environment; approved configuration to production; production backup to recovery environment.

Defender questions

Is the data appropriate for the environment? Are identities and permissions separate? Which configuration, evidence, and change controls apply?

Control expectations

Environment separation, synthetic data, separate identities, change approval, configuration baselines, deployment evidence, access review, and recovery validation.

Evidence expectations

Environment inventory, data source, identity scope, deployment record, change approval, configuration version, and access events.

Technology or protocol boundary

Trust change

What changes

A fictional request or record changes format, interface, protocol, parser, queue, storage model, or processing technology.

Fictional examples

Web form to API request; API result to queue event; uploaded file to extracted metadata; event stream to dashboard metric.

Defender questions

What transformation occurs? Which assumptions are lost or added? How are type, schema, size, encoding, ordering, duplication, and error handled?

Control expectations

Schema validation, safe parsing, size and type limits, canonical formats, duplicate handling, ordering, error isolation, versioning, and monitoring.

Evidence expectations

Schema version, parser result, validation outcome, conversion record, retry state, error reason, and downstream correlation.

Network or location boundary

Trust change

What changes

A fictional interaction moves between public, internal, management, restricted, supplier, remote, wireless, cloud, or recovery zones.

Fictional examples

Public portal to protected application service; management workstation to administrative console; supplier service to integration gateway.

Defender questions

Which source and destination zones are involved? Which identity and service are expected? What should be allowed, denied, observed, isolated, or rate-limited?

Control expectations

Segmentation, explicit access paths, identity-aware policy, filtering, secure remote access, monitoring, rate controls, source health, and fail-safe behavior.

Evidence expectations

Zone map, policy decision, connection event, service identity, destination, result, health signal, and change record.

Recovery and degraded-operation boundary

Trust change

What changes

A fictional service enters failover, restore, emergency access, manual workaround, delayed processing, reconciliation, or post-recovery validation.

Fictional examples

Primary storage to backup restoration; normal identity to emergency recovery role; queue failure to manual case review.

Defender questions

Which trust assumptions change during disruption? Who may act? Which data and configuration are trusted? How is business state reconciled and communicated?

Control expectations

Documented trigger, approval, time-bound authority, trusted baselines, integrity checks, alternate workflow, reconciliation, communication, and post-event review.

Evidence expectations

Trigger, approving actor, recovery identity, source artifact, action, validation result, business-state check, communication, and closure record.

Instructional Section 3

Model the Full Flow Lifecycle

A flow is not complete when a request is sent. Professional defenders consider origination, entry, validation, authorization, transformation, storage or delivery, observation, failure, retry, recovery, reconciliation, retirement, and deletion.

1. Origination

Core question

Which fictional actor, service, device, supplier, process, or store creates the request or information?

What to record

Source identity, purpose, trigger, authority, original fields, classification, timestamp, owner, and evidence.

Failure themes

Unknown source, stale identity, incorrect trigger, unnecessary fields, unsupported purpose, or missing evidence.

2. Entry

Core question

Through which approved fictional interface does the interaction enter the next component or trust context?

What to record

Entry point, interface owner, accepted operation, source context, destination, exposure, version, and rate or size expectations.

Failure themes

Unowned interface, deprecated path, unsupported version, unexpected source, uncontrolled retry, or temporary channel left active.

3. Validation

Core question

Which fictional format, meaning, identity, source, timing, state, and business-rule checks occur before use?

What to record

Schema result, source validation, data quality, identity context, duplicate or ordering checks, rejection reason, and evidence.

Failure themes

Malformed input, missing context, stale state, duplicate event, unsupported field, incorrect type, or silent acceptance.

4. Authorization

Core question

May this fictional actor perform this action on this object under the current conditions?

What to record

Actor, role, attributes, object, action, conditions, approval, policy result, reason, and denial handling.

Failure themes

Excessive authority, missing object check, stale role, unsupported delegation, absent approval, or unclear exception.

5. Transformation

Core question

How does the fictional process classify, enrich, route, aggregate, approve, extract, redact, or otherwise change the information?

What to record

Transformation rule, version, input, output, fields added or removed, owner, evidence, and error behavior.

Failure themes

Incorrect mapping, hidden derived data, lost context, unsafe default, silent truncation, inconsistent version, or unreviewed automation.

6. Storage or delivery

Core question

Where is the fictional result stored or delivered, for which purpose, audience, retention period, and downstream use?

What to record

Destination, data purpose, classification, owner, access, retention, deletion, integrity, notification, and recovery.

Failure themes

Wrong destination, excessive audience, unnecessary retention, duplicate copy, unprotected metadata, or missing confirmation.

7. Observation

Core question

Which fictional evidence shows the interaction was accepted, denied, delayed, transformed, completed, failed, retried, or restored?

What to record

Actor, action, target, result, state, correlation, source health, timestamp quality, retention, and reviewer.

Failure themes

Missing event, ambiguous meaning, unhealthy source, inconsistent time, unlinked retry, excessive sensitive logging, or no owner.

8. Failure and retry

Core question

What happens when the fictional interaction cannot complete safely?

What to record

Failure reason, bounded retry, queue or isolation state, user impact, alert, escalation, fallback, and evidence.

Failure themes

Infinite retry, duplicate action, lost request, hidden backlog, unsafe fallback, unclear user status, or unbounded queue growth.

9. Recovery and reconciliation

Core question

How is correct fictional technical and business state restored after disruption?

What to record

Recovery trigger, trusted source, authority, restore order, validation, reconciliation, communication, owner, and closure.

Failure themes

Technically restored service with stale identity, incorrect workflow state, duplicate records, missing notification, or unverified data integrity.

10. Retirement and deletion

Core question

How is the fictional flow, interface, copy, identity, rule, or store removed when no longer needed?

What to record

Retirement owner, dependency review, archive or deletion decision, evidence retention, identity removal, interface disablement, and confirmation.

Failure themes

Temporary interface remains active, stale copy persists, service identity is orphaned, documentation remains current-looking, or dependencies are missed.

Instructional Section 4

Ask Eight Questions at Every Important Boundary Crossing

What trust changed?

Identify changes in identity, authority, ownership, sensitivity, location, technology, administration, environment, supplier responsibility, or recovery state.

Supporting fictional evidence

Architecture view, role matrix, data classification, service agreement, environment inventory, identity record, or recovery plan.

Which flow crosses the boundary?

Name the fictional source, destination, purpose, content, actor, operation, state, timing, and direction.

Supporting fictional evidence

Labeled diagram arrow, interface definition, event sample, workflow record, or approved requirement.

What is trusted before use?

State which identity, data, field, source, device, assertion, schema, configuration, timing, or business state the destination relies on.

Supporting fictional evidence

Validation rule, identity policy, configuration baseline, schema, owner decision, or test result.

Which controls decide acceptance?

Describe fictional validation, authorization, minimization, filtering, segmentation, session, rate, approval, monitoring, and safe-failure controls.

Supporting fictional evidence

Control requirement, policy decision, design review, event output, change record, or safe test evidence.

What evidence supports review?

Define which fictional records answer actor, action, target, reason, result, state, health, timing, source, and correlation questions.

Supporting fictional evidence

Event schema, source-health dashboard, ticket, approval, queue state, recovery validation, or review record.

What happens when trust cannot be established?

Describe denial, isolation, quarantine, bounded retry, manual review, fallback, escalation, user communication, and preservation of evidence.

Supporting fictional evidence

Failure design, error record, incident procedure, support workflow, queue policy, or recovery exercise.

Who owns each side?

Identify fictional source owner, destination owner, interface owner, data owner, identity owner, supplier owner, operations owner, and risk owner.

Supporting fictional evidence

Ownership register, service catalog, role assignment, supplier record, or governance decision.

When must the boundary be reviewed?

Set triggers for changes in actor, data, purpose, identity, permission, interface version, supplier, environment, protocol, exposure, failure, recovery, or ownership.

Supporting fictional evidence

Change record, access review, architecture revision, supplier update, incident lesson, scheduled review, or exercise finding.

Instructional Section 5

Distinguish Current, Future, Failure, and Recovery Flows

A fictional model should never mix proposed design with current design without clear labels. It should also separate normal processing from failure, degraded operation, support intervention, emergency administration, recovery, reconciliation, and retirement.

Flow state	Meaning	Required labels	Review concern
Current-state	Fictional flow documented as operating now.	Evidence date, owner, confidence, source, destination, purpose, content, controls, and known gaps.	Documentation may be stale or incomplete.
Future-state	Fictional proposed flow that is not yet approved or implemented.	Proposal owner, assumptions, required decisions, dependencies, planned controls, and approval status.	Do not present planned design as current fact.
Failure-state	Fictional rejection, timeout, invalid input, unavailable dependency, denied action, or processing error.	Failure reason, state, evidence, owner, user impact, escalation, and safe fallback.	Failure can expose hidden authority and retry behavior.
Retry-state	Fictional repeated attempt after failure or delay.	Retry limit, timing, duplication handling, ordering, correlation, queue state, and stop condition.	Unbounded retry can create duplicates or hidden backlog.
Support-state	Fictional human-assisted correction or exception workflow.	Verified actor, purpose, authority, approval, reason, evidence, and user confirmation.	Support paths may have broad privileges and weak traceability.
Emergency-state	Fictional elevated access or alternate process during disruption.	Trigger, approval, time limit, scope, evidence, monitoring, review, and revocation.	Emergency access must not become a permanent normal path.
Recovery-state	Fictional restoration, failover, queue restart, identity recovery, or configuration restoration.	Trusted source, authority, order, validation, reconciliation, communication, and closure.	Technical availability may return before correct business state.
Retired-state	Fictional interface, identity, data copy, process, or flow removed from use.	Owner, dependency review, disablement, identity removal, deletion or archive, evidence, and confirmation.	Temporary and deprecated paths often remain visible or active without ownership.

Diagram Quality

Move from a Sketch to a Decision-Ready Threat Model

Level 1: Unlabeled sketch

Boxes are connected with arrows, but flows, actors, assets, boundaries, purpose, ownership, and evidence are missing.

Remaining risk

Reviewers may assume the diagram is complete even though it cannot support control or threat decisions.

Next improvement

Name actors, processes, stores, flow purpose, content, direction, and owners.

Level 2: Labeled system flow

The fictional diagram identifies actors, services, stores, and named flows.

Remaining risk

Trust changes, validation, authorization, privacy, failure, and recovery may remain implicit.

Next improvement

Mark meaningful boundaries and record what trust changes at each crossing.

Level 3: Boundary-aware model

Fictional identity, ownership, sensitivity, environment, supplier, network, and recovery boundaries are visible.

Remaining risk

Controls may still be listed without evidence, ownership, or failure behavior.

Next improvement

Link each boundary crossing to validation, authorization, monitoring, minimization, failure, and evidence.

Level 4: Decision-ready model

Each important fictional flow and boundary has purpose, content, actors, assets, owners, controls, evidence, assumptions, unknowns, confidence, failure, recovery, and review triggers.

Remaining risk

The model can still become stale or be mistaken for proof of actual implementation.

Next improvement

Version the model, validate claims against supplied fictional evidence, record disagreements, and maintain change triggers.

Fictional Architecture View

Northbridge Student-Support Data-Flow Model

The model below is completely invented. It illustrates how normal, supplier, evidence, notification, administrative, and recovery flows can cross different trust boundaries. It does not describe any real school, organization, application, supplier, network, identity system, or internal architecture.

Students and guardians

Submit fictional records, view status, update preferences, and request support.

Counselors

Review assigned fictional cases and record approved decisions.

Support analysts

Perform verified support actions through a controlled console.

Recovery operators

Use approved recovery identities during declared restoration activity.

Fictional Northbridge Service Zone

Portal interface

User requests, files, status, preferences

Identity service

Human and service identity decisions

Application service

Validation, authorization, workflow

Case store

Fictional records and workflow state

Processing queue

Supplier requests and result events

Notification service

Approved fictional status messages

Monitoring pipeline

Events, health, and evidence

Archive and recovery

Retention, restore, and reconciliation

Processing supplier

Receives minimized fictional requests and returns processing results.

Notification provider

Delivers approved fictional messages and status receipts.

Analytics proposal

Future-state process awaiting purpose, field, owner, and retention decisions.

Backup environment

Receives approved recovery artifacts and supports validation.

Boundary A: Public to service

Identity, session, authorization, input, file, rate, privacy, and evidence assumptions change.

Boundary B: Service to supplier

Administrative ownership, service identity, data purpose, minimization, availability, evidence, and recovery assumptions change.

Boundary C: Workflow to notification

Audience, privacy, content, timing, user expectation, delivery, and retry assumptions change.

Boundary D: Normal to recovery

Authority, trusted baseline, dependency order, business state, evidence, communication, and closure assumptions change.

Fake Dashboard

Fake Northbridge Flow and Boundary Dashboard

Fictional data-flow completeness, ownership, evidence, and recovery status for training only.

Flows with complete labels

21 / 29

Eight flows still lack complete purpose, content, actor, state, owner, evidence, or failure information.

Boundary crossings needing review

Supplier, notification, analytics, recovery, support, and temporary migration paths need additional owner or evidence decisions.

Failure paths without reconciliation

Delayed supplier result, notification failure, and archival retry paths do not yet show complete business-state reconciliation.

Fake SOC Alert

Supplier Result Flow Lacks Complete Boundary Evidence

Source: Fake Northbridge Threat-Model Review Console • Time: 11:18 AM

High Severity

A fictional processing-result flow crosses from an externally operated supplier into the Northbridge workflow service. The current model does not confirm result schema ownership, source-health meaning, duplicate and ordering behavior, delay thresholds, reconciliation, or evidence retention.

Defensive recommendation: Do not test any real integration or assume compromise. Validate the fictional owners, purpose, identity, schema, state, evidence, health, failure, retry, reconciliation, and review triggers using only supplied records.

Fake Log Panel

Fake Data-Flow and Trust-Boundary Review Timeline

training-log-viewer.log

09:00 MODEL scope='student-support-portal' version='A3.3-draft'
09:08 FLOW user-upload source='public-interface' destination='validation-service'
09:15 BOUNDARY type='identity+sensitivity' crossing='public-to-service'
09:22 FLOW supplier-request fields='case-ref,category,priority,note'
09:29 BOUNDARY type='administrative+privacy' crossing='service-to-supplier'
09:36 IDENTITY supplier-service owner='incomplete' review='expired'
09:44 RESULT queue-delay='22m' health='green'
09:51 EVIDENCE state='delayed' source-health='reported-healthy'
09:58 SUPPORT duplicate-submissions='observed' cause='not-proven'
10:06 FLOW notification-status state='delayed'
10:14 RECOVERY app='restored' queue='unvalidated' archive='unvalidated'
10:22 BOUNDARY type='recovery' trust='baseline+identity+state'
10:31 FUTURE analytics-flow status='proposed' fields='unapproved'
10:39 ENTRY migration-import owner='unknown' purpose='unclear'
10:47 GAP flow-labels='8' boundary-review='6' reconciliation='3'
10:55 ACTION supplier-owner='validate-schema-and-state'
11:03 ACTION recovery-owner='define-order-and-reconciliation'
11:10 CONFIDENCE diagram='medium' current-state='partial'
11:18 ALERT crossing='supplier-result' evidence='incomplete'
11:25 DECISION ranking='deferred' owner-review='required'

Training note: this is fake data for defensive analysis practice only.

Fictional Evidence Matrix

What the Evidence Supports—and What It Does Not Prove

DF-01

Fictional architecture diagram

Observation

The student-support portal sends document-processing requests to an external supplier and receives status results through a separate integration path.

Supports

A supplier administrative boundary exists, and the outbound and inbound flows may have different data, validation, evidence, and failure requirements.

Does not prove

The diagram does not prove which fields are actually transmitted, which identity is used, or whether every path is current.

Threat-model use

Create two labeled flows, identify owners on both sides, and request fictional field, identity, health, and lifecycle evidence.

DF-02

Fictional data-field record

Observation

The supplier request includes case reference, document category, processing priority, and a free-text support note.

Supports

The flow crosses a privacy and administrative boundary and may include a field whose necessity requires owner review.

Does not prove

The record does not prove the field is populated in every request, retained by the supplier, or unapproved.

Threat-model use

Document field purpose, classification, minimization question, validation, retention, and responsible owner.

DF-03

Fictional identity review

Observation

The supplier integration trusts one service identity, but the local owner field is incomplete and the review date has expired.

Supports

The boundary depends on a non-human identity whose ownership and lifecycle evidence need validation.

Does not prove

The evidence does not prove compromise, misuse, excessive permission, or failed authentication.

Threat-model use

Open identity-owner, authority, rotation, activity, monitoring, failure, and retirement questions.

DF-04

Fictional queue-health dashboard

Observation

Processing-result events were delayed for twenty-two minutes while source-health reporting continued to show Green.

Supports

Flow-state and health evidence may not reflect the same condition, and delayed events can affect workflow integrity and user communication.

Does not prove

The dashboard does not prove data loss, incorrect status, or a security incident.

Threat-model use

Review queue state, source-health meaning, delay evidence, reconciliation, user impact, and alert thresholds.

DF-05

Fictional support ticket review

Observation

Users submitted duplicate documents after receiving delayed status notifications during a processing disruption.

Supports

Notification, workflow state, user behavior, duplicate handling, and recovery communication are connected flows.

Does not prove

The tickets do not prove which technical component caused the delay or whether every duplicate resulted from notification timing.

Threat-model use

Add notification, duplicate-detection, support, and reconciliation flows to the model with uncertainty noted.

DF-06

Fictional recovery exercise

Observation

Application service was restored before the notification queue and archival scheduler were validated, producing stale status messages and repeated archival tasks.

Supports

The recovery boundary includes dependency order, service identities, queue state, business-state validation, and communication.

Does not prove

One exercise does not prove how often this condition will occur or the effectiveness of current corrective actions.

Threat-model use

Model recovery sequencing, trusted state, reconciliation, approval, validation, evidence, and closure.

DF-07

Fictional change request

Observation

A new analytics process will receive event data from the portal, support console, supplier integration, and notification service.

Supports

The proposed design creates new data-lineage, privacy, ownership, interpretation, retention, and aggregation questions.

Does not prove

The request does not prove the final fields, purpose, audience, controls, or retention have been approved.

Threat-model use

Mark the proposed flow as future-state, list assumptions, and require owner decisions before treating it as implemented.

DF-08

Fictional interface inventory

Observation

A temporary migration-import channel remains documented as enabled but is missing current purpose, owner, activity, accepted fields, and retirement evidence.

Supports

The model contains a potentially stale entry point and an unresolved environment or administrative boundary.

Does not prove

The inventory does not prove the interface is reachable, used, unsafe, or unnecessary.

Threat-model use

Validate fictional purpose, state, owner, flow content, identity, controls, evidence, dependencies, and retirement without real testing.

Analyze the Evidence

Which Boundary Finding Deserves the First Design Review?

The supplier-result flow crosses an administrative and technology boundary into the Northbridge workflow service.

The queue dashboard reported Green while result events were delayed for twenty-two minutes.

The current model does not confirm result schema ownership, duplicate handling, ordering behavior, delay thresholds, reconciliation, or evidence retention.

The support tickets show duplicate submissions after delayed notifications, but they do not prove one technical cause.

The supplier identity owner field is incomplete and its review date has passed.

The recovery exercise showed stale status messages and repeated archival tasks after application restoration.

The analytics flow is proposed future-state and does not yet have approved fields, purpose, audience, or retention.

The model is still a draft with medium confidence.

Which conclusion is best supported by the fictional Northbridge evidence?

Common Mistakes

Errors That Weaken Data-Flow and Trust-Boundary Models

Drawing only the happy path

Why it fails

Normal successful flows hide denial, validation failure, retry, timeout, support, administrative, supplier, degraded, recovery, archival, and deletion states.

Strong correction

Model normal, failure, retry, support, emergency, recovery, reconciliation, and retirement paths.

Using unlabeled arrows

Why it fails

A line without source, destination, purpose, content, identity, authority, state, and owner cannot support threat or control decisions.

Strong correction

Label every important fictional flow with enough context to explain what moves and why.

Treating every network line as a trust boundary

Why it fails

Trust can change inside one network, one application, one cloud account, or one team; a network crossing may also preserve the same trust context.

Strong correction

Mark boundaries only where identity, authority, ownership, sensitivity, environment, technology, supplier, administration, or recovery assumptions change.

Missing non-data flows

Why it fails

Identity assertions, policy decisions, approvals, administrative actions, configuration changes, health signals, alerts, evidence, and recovery commands affect security even when they are not business records.

Strong correction

Model information, identity, authority, control, evidence, and recovery flows.

Assuming the diagram is proof

Why it fails

A diagram reflects a model, version, owner perspective, and evidence limit; it may omit temporary, stale, manual, supplier, retry, and recovery paths.

Strong correction

Link diagram claims to supplied fictional evidence, confidence, assumptions, unknowns, and review dates.

Ignoring data minimization

Why it fails

A flow may carry fields, metadata, free text, derived information, or context that the destination does not need.

Strong correction

Record field-level purpose, sensitivity, destination use, retention, and owner approval.

Combining validation and authorization

Why it fails

A request can be well formed but unauthorized, or authorized in principle but invalid for the current object, state, timing, or business rule.

Strong correction

Document format and meaning validation separately from actor and object authorization.

Ignoring state and timing

Why it fails

Delayed, duplicated, reordered, retried, stale, partial, or conflicting events can harm workflow integrity even when each message is valid.

Strong correction

Model flow state, ordering, duplication, freshness, timeout, retry, reconciliation, and user communication.

Forgetting source health

Why it fails

Missing events can look like normal inactivity when the source, collector, queue, parser, or dashboard is unhealthy.

Strong correction

Include health, completeness, timestamp quality, parsing state, and evidence ownership.

Publishing real internal diagrams

Why it fails

Removing credentials or addresses does not remove the sensitivity of real relationships, suppliers, roles, boundaries, workflows, evidence sources, or recovery paths.

Strong correction

Invent every organization, actor, system, flow, boundary, record, date, control, decision, and outcome.

Safe Fictional Practice Lab

Build the Northbridge Data-Flow and Trust-Boundary Package

Use only the supplied fictional information on this page. Do not access, test, scan, configure, monitor, investigate, recover, or change any real system. Do not use real identities, diagrams, interfaces, addresses, configurations, logs, tickets, supplier records, data fields, recovery details, or private information.

Confirm scope and modeling decision

State which fictional Northbridge design decision the data-flow model will support and which actors, processes, stores, suppliers, environments, interfaces, and time period are included.

Required output

Purpose, scope, exclusions, stakeholders, model version, and safety boundary.

Quality check

The reviewer can identify which flows and environments are intentionally outside the model.

Place actors, processes, and stores

Use the A3.2 relationship register to place fictional end users, support actors, administrators, service identities, suppliers, portal services, queues, stores, monitoring, archive, and recovery components.

Required output

A component inventory with owner, purpose, asset connection, and evidence source.

Quality check

Every component has a purpose and owner or is marked as an unresolved gap.

Draw and label normal flows

Map fictional user submission, identity, processing, status, notification, evidence, storage, archival, and reporting flows.

Required output

Labeled arrows showing source, destination, purpose, content, direction, actor, state, and owner.

Quality check

No important arrow is described only as Data or API.

Mark meaningful trust boundaries

Identify fictional identity, authorization, administrative, supplier, sensitivity, environment, technology, network, and recovery boundaries.

Required output

Boundary map with boundary type, owner, changed assumption, crossing flows, and evidence needs.

Quality check

Each boundary is justified by a trust change rather than by visual layout alone.

Add failure and retry paths

Model fictional rejection, queue delay, supplier failure, duplicate event, notification failure, support correction, bounded retry, and escalation.

Required output

Failure-state and retry diagram with evidence, user impact, owner, and safe fallback.

Quality check

Retries are bounded and do not silently create duplicate or conflicting business state.

Add recovery and reconciliation

Model fictional failover, restore order, recovery identity, trusted baseline, queue recovery, business-state validation, communication, and closure.

Required output

Recovery flow with approval, source, destination, authority, validation, reconciliation, and evidence.

Quality check

The model validates business and user state, not only technical availability.

Build the boundary review table

For each important crossing, record changed trust, controls, evidence, failure behavior, owners, assumptions, unknowns, confidence, and review triggers.

Required output

A decision-ready trust-boundary register.

Quality check

Every listed control has an owner and expected evidence rather than being a generic label.

Review completeness and communicate

Check normal, administrative, support, supplier, evidence, degraded, recovery, archival, deletion, and future-state paths, then write a leadership summary.

Required output

Quality review, gap register, decision log, leadership summary, technical appendix, and reflection.

Quality check

The final package distinguishes current-state, future-state, assumption, unknown, and unresolved decision.

Scenario Decision Lab

A Supplier Flow Carries an Unclear Free-Text Field

The fictional processing request crosses into an externally operated supplier and includes a free-text support note. The current evidence does not prove whether the field is populated in every request, retained by the supplier, or approved for this purpose.

Scenario Decision Lab

A Reviewer Requests a Real Recovery Diagram

A reviewer says the portfolio would be stronger if the student copied a real organization's recovery flow, removed addresses, and changed the organization name.

Advanced Challenge

Design a Degraded-Mode and Recovery Flow without Losing Business State

The fictional application service returns to operation before the supplier-result queue, notification service, and archival scheduler are fully validated. Users can view the portal, but some case statuses are stale, some notifications are delayed, and duplicate archival tasks are possible. Design a safe fictional degraded-mode and recovery flow.

Declare the state

Define when the fictional service enters degraded mode, who approves it, which features remain available, and how users are informed.

Limit authority

Define which human and service identities may perform recovery, reconciliation, queue, notification, and archival actions.

Protect workflow integrity

Prevent duplicate, stale, reordered, or conflicting case updates while dependencies recover.

Validate trusted sources

Identify which backup, queue, event, configuration, and identity records are trusted and how their integrity is checked.

Reconcile business state

Compare technical records with correct fictional case, notification, duplicate-submission, and archival outcomes.

Close and review

Record evidence, remaining uncertainty, user communication, residual risk, owner approval, lessons, and review triggers.

Challenge output

Produce a fictional degraded-mode diagram, recovery-boundary table, reconciliation checklist, evidence plan, responsibility map, user-communication decision, and leadership explanation of why technical availability is not the same as correct business recovery.

Defender Habits

Data Flows and Trust Boundaries Checklist

Check Your Understanding

A3.3 Mini Quiz: Data Flows and Trust Boundaries

Choose your answers first. Explanations appear only after submission.

1. What is the strongest definition of a trust boundary?

2. Which label makes a fictional flow most useful for threat modeling?

3. A queue-health dashboard shows Green while processing-result events are delayed. What is the best conclusion?

4. Why should validation and authorization be modeled separately?

5. Which path is commonly missed in a weak data-flow diagram?

6. What does a fictional architecture diagram prove?

7. Which portfolio approach is safest?

Portfolio Prompt

Create a fully fictional Data-Flow and Trust-Boundary Package for the Northbridge Student-Support Portal. Include purpose, scope, exclusions, safety boundary, current-state and future-state labels, actors, processes, stores, interfaces, at least fourteen labeled flows, at least six justified trust boundaries, source and destination owners, flow purpose, content, identity, authority, validation, authorization, data minimization, state, timing, ordering, duplication, evidence, source health, failure, retry, degraded operation, recovery, reconciliation, archival, deletion, assumptions, unknowns, confidence, review triggers, gap register, decision log, leadership summary, technical appendix, reflection, and a statement that every organization, actor, identity, process, service, store, interface, flow, boundary, event, date, control, decision, and outcome is invented.

Build from the fictional A3.2 asset–actor–entry point register so every flow is connected to value, role, interface, purpose, and ownership.

Label arrows with meaningful descriptions rather than generic words such as Data, Traffic, or API.

Mark trust boundaries only where identity, authority, ownership, sensitivity, environment, technology, supplier, administration, network, or recovery assumptions change.

Include failure, retry, support, degraded, recovery, reconciliation, archival, deletion, and retirement paths—not only the successful path.

Keep the entire artifact completely fictional, defensive, non-operational, privacy-safe, and suitable for a public learning portfolio.

Confidence / Readiness Reflection

Are You Ready to Develop Safe Abuse Cases and Misuse Questions?

Before moving to A3.4, rate your readiness from 1 to 5 for flow labeling, boundary identification, validation, authorization, minimization, evidence, source health, failure, retry, recovery, reconciliation, lifecycle, ownership, uncertainty, and complete fictionalization.

I can draw a fictional flow that identifies source, destination, purpose, content, actor, state, owner, and evidence.

I can explain why a trust boundary exists instead of marking one only because boxes are separated.

I can distinguish identity, authority, privacy, supplier, environment, technology, network, and recovery trust changes.

I can separate validation from authorization and show what happens when either fails.

I can include delay, duplication, ordering, retry, failure, support, emergency, degraded, recovery, reconciliation, and retirement.

I can explain what a diagram supports and what it does not prove.

I can preserve assumptions, unknowns, confidence, evidence limits, ownership gaps, and review triggers.

I can create a complete fictional model without copying, modifying, or exposing real internal information.

Record one fictional flow that needed a clearer purpose, one boundary whose trust change was easy to miss, one failure path that changed authority or state, one evidence limitation, and one question you will carry into A3.4 abuse-case and misuse thinking.

Key Takeaways

What You Should Remember

1.A data-flow diagram should identify actors, processes, stores, flows, boundaries, evidence, ownership, and lifecycle—not only components.

2.A trust boundary exists where an important trust assumption changes, including identity, authority, ownership, sensitivity, environment, technology, supplier, administration, network, or recovery state.

3.Every important flow needs source, destination, purpose, content, actor, identity, authority, state, validation, evidence, owner, failure, and review context.

4.Validation and authorization solve different questions and should be modeled separately.

5.Normal, failure, retry, support, emergency, degraded, recovery, reconciliation, archival, deletion, and retirement paths can produce different trust and authority conditions.

6.A diagram, log, dashboard, alert, or owner statement supports a model but does not prove complete current behavior or control effectiveness.

7.Source health, event completeness, timestamp quality, correlation, duplication, ordering, delay, and reconciliation are part of trustworthy flow evidence.

8.Current-state and future-state flows must be labeled separately so proposals are not mistaken for implemented fact.

9.Supplier and recovery boundaries require clear ownership, minimized data, identity, evidence, failure, change, and exit decisions.

10.Every CyberShield diagram and artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real systems or people.

Navigation

Continue Module A3

Next, use the fictional assets, actors, entry points, data flows, and trust boundaries to develop safe, outcome-focused abuse cases and misuse questions without operational harmful detail.

Previous Lesson Module A3 Next Lesson