Chapter 3 — Cybersecurity: systems, data and dependencies

Chapter 3 — Cybersecurity: systems, data and dependencies

Lesson map

Lesson 03 published. Map, example, EX011.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 A model answers a question; it is not the servic"]
  N2["3.2 Name the parts and their owners"]
  N3["3.3 Follow the information, including copies"]
  N4["3.4 Draw a flow and mark the boundaries"]
  N5["3.5 Dependencies change with the outcome"]
  N6["3.6 Guided lab: a decision from a stale snapshot"]
  N7["3.7 A reviewable model record"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX011"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 A model answers a question; it is not the servic"]
  N2["3.2 Name the parts and their owners"]
  N3["3.3 Follow the information, including copies"]
  N4["3.4 Draw a flow and mark the boundaries"]
  N5["3.5 Dependencies change with the outcome"]
  N6["3.6 Guided lab: a decision from a stale snapshot"]
  N7["3.7 A reviewable model record"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]

[Learning outcomes]
    |
    v
[3.1 A model answers a question; it is not the servic]
    |
    v
[3.2 Name the parts and their owners]
    |
    v
[3.3 Follow the information, including copies]
    |
    v
[3.4 Draw a flow and mark the boundaries]
    |
    v
[3.5 Dependencies change with the outcome]
    |
    v
[3.6 Guided lab: a decision from a stale snapshot]
    |
    v
[3.7 A reviewable model record]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

After this chapter, you should be able to:

1. Set a useful boundary for a small service model and name its people, processes, stores, and outside services.
2. Trace one kind of information from creation to use, copying, and disposal without assuming that every copy is current.
3. Distinguish a data flow from a dependency and mark where a change of authority or trust deserves a question.
4. State which parts of a diagram are supplied facts, exercise assumptions, or unanswered questions.
5. Produce a small model and evidence-gap list from synthetic records only.

3.1 A model answers a question; it is not the service

The first chapter named Harbor Library's room-booking service. The second limited our practice to invented records. We can now ask a more precise question: Could a front-desk worker make a correct room decision while the live booking view is unavailable? A useful model contains the parts needed to answer that question. It need not depict every device the library owns.

A service boundary says what the model covers. For this lesson it includes a resident's booking request, the booking view, a reservation store, a staff view, and the staff's fallback printout. The event-announcement list is a separate data set; it belongs in a broader library inventory but is outside the booking-decision path we will trace. That exclusion is deliberate, not a claim that the contact list has no security needs.

NIST's CSF 2.0 places inventories of hardware, software and services, representations of authorized network flows, supplier services, asset prioritization, and designated data types in its Asset Management category (ID.AM). The framework describes outcomes; it does not prescribe this course's diagram or prove that Harbor Library has any particular implementation. An organization would confirm the model with owners and approved records. Our beginner exercise uses stated assumptions so that the reasoning can be checked without live discovery.

The OWASP Threat Modeling Cheat Sheet recommends showing external entities, processes, data stores, flows, and trust boundaries when modeling a system. We borrow these simple labels to understand the service. Threat ranking and application testing belong later in the learning path. For now, the job is to understand what information moves, who depends on it, and where our knowledge ends.

3.2 Name the parts and their owners

An external entity is a person or system outside the modeled process that interacts with it. A process accepts information and performs a task. A data store retains information. A data flow is movement between them. These labels describe roles in a model, not verified product architecture. One real application could combine several roles; one role could be spread across several services.

The “owner” column is a route for verification, not an assertion that one named person holds every responsibility. If the staff view actually reads from a different store, the model must change. If the paper printout is produced every hour rather than once each morning, its freshness risk also changes. A diagram should be revised when evidence disagrees with it.

3.3 Follow the information, including copies

Start with the data needed for the decision. In our synthetic exercise, a reservation has an invented ID, room, start time, creation time, and status. A confirmed booking is represented in the reservation store. A staff view may display that state. A printout contains a snapshot made at a particular time; it does not automatically receive later changes. This is a temporal property of the paper copy, not a software vulnerability.

Trace each representation explicitly:

The event-contact list has a different purpose from the reservation list. Do not assume that a person who may view a room booking may also export event contacts. Likewise, a backup is a potential recovery resource, not automatically a current booking view. For a real inventory, an owner should identify data types, locations, purpose, access, retention and disposal rules according to the organization's policies. In this exercise, we record only the fields needed for the teaching question and invent no personal identifiers.

The distinction between source of truth and copy helps prevent an easy mistake. A current authoritative record is the one the service owner designates for a particular decision, subject to its actual integrity and availability. A printed copy may still be useful during an outage, but its timestamp limits what it can establish. “The printout exists” does not imply “the printout reflects all reservations.” “A backup job completed” does not imply “staff can safely use the backup as a live schedule.” Each claim needs separate evidence.

3.4 Draw a flow and mark the boundaries

The following is a text alternative to a diagram. It is intentionally small. Arrows indicate proposed movement of information, and brackets name roles. They do not claim that a real Harbor Library application has this architecture.

[Resident] --booking request--> [Booking view] --proposed write--> [Reservation store]
     ^                              |                               |
     |                         booking result                   proposed read
     +------------------------------+                               |
                                                                    v
[Staff member] --sign-in and query--> [Staff view] <---------------+
                                         |
                                    09:00 snapshot
                                         v
                                [Printed schedule]

The first arrow crosses a boundary between a resident and a service that decides whether a request is valid. The staff sign-in and query cross a different boundary because a worker may have authority to see or change information that a resident cannot. The printed schedule leaves a digital process and becomes a physical copy; its handling and freshness need human procedures. A trust boundary marks a change in assumptions or authority that should be examined. It is not, by itself, evidence that authentication, authorization, encryption, or logging is present or absent.

For each arrow, ask three beginner questions: What moves? Who is allowed to cause or read that movement? What evidence would show that the intended rule is followed? For the resident request, the answers might be “room and time,” “a resident may request an available room,” and “an owner-approved test with synthetic bookings plus a reviewed application specification.” Those are possible checks, not facts established by our paper exercise. Do not use this diagram as permission to send test requests to a public site.

If a third-party messaging service sends confirmations, add it as an outside service only after confirming that it is actually used. Then ask what data it receives, what the supplier is responsible for, and whether the service can still make a booking decision if messaging is delayed. This is an example of a conditional dependency: the answer may differ between “a reservation can be saved” and “a resident receives confirmation.” Keeping those outcomes separate avoids treating every supplier outage as a complete booking outage.

3.5 Dependencies change with the outcome

A dependency is needed for a particular outcome under particular conditions. In the proposed live path, the booking view may depend on a reservation store. During the tabletop outage, staff may instead depend on the latest approved fallback source and a rule for pending requests. A component can be important without being the only way to keep working. Do not call the reservation store a “single point of failure” unless the owner has confirmed there is no suitable alternative and has defined what failure means.

To review a dependency, write a conditional sentence: “If X is unavailable, Y cannot be completed within Z time using the approved fallback.” The fictional case does not provide a recovery target Z, so leave it as a question for the service owner. Separate effects on residents, staff, and event subscribers. An outage of the front-desk view does not prove that a resident's page is down; Chapter 1's record specifically limited the observed outage to the front desk.

The service model also needs an update rule. A change to the booking workflow, printing schedule, or approved source can invalidate this page. A small inventory entry should therefore record the model's date, author or responsible owner, scope, evidence, open questions, and the trigger for revision. A tidy diagram with no review date can mislead a reader more than a rough diagram with clear uncertainty labels.

3.6 Guided lab: a decision from a stale snapshot

Use the synthetic rows introduced in Chapter 2:

booking_id,room,start_time,created_time,status
SYN-001,Room 2,14:00,08:20,confirmed
SYN-002,Room 2,15:00,10:05,confirmed

For this lab only, assume a 09:00 printout is a fixed snapshot, includes SYN-001, and cannot include SYN-002 because that booking was created at 10:05. The front-desk view is unavailable from 11:30 to 11:50. At 11:42 someone asks whether Room 2 is free at 15:00. No network or real data is used.

1. Copy the six modeled parts from Section 3.2 onto paper or into a Markdown table. Circle the printed schedule as a copy.
2. Trace SYN-002 from its 10:05 creation to the reservation store in the hypothetical model. Draw a question mark at any unverified step, including whether the staff view would normally show it.
3. Compare the query time, printout time, and booking time. The printout cannot answer the 15:00 availability question under the stated snapshot assumption. Do not turn that conclusion into a claim about a real service.
4. Use the Chapter 2 fallback rule: mark the request pending, record the reason, and seek an approved current source or the owner. Do not promise the room from the old paper alone.
5. Write a three-line report: observed exercise fact, decision, and limitation. A model answer is: “The 09:00 synthetic printout omitted a booking created at 10:05. In the tabletop, the worker marked the 15:00 request pending rather than confirming it. The exercise did not inspect a real reservation store or establish how the real library handles outages.”

The expected artifact is a small model plus this report. The outcome is not “we discovered a breach.” The outcome is a defensible decision given limited information. If the owner later supplies a verified hourly paper schedule or an approved offline replica, repeat the analysis with that evidence; do not preserve the original conclusion merely because it appeared in a diagram.

3.7 A reviewable model record

Use this Markdown template for a service model. It is intentionally short enough that another learner can challenge it:

Decision being supported:
Service and people affected:
In scope / out of scope:
Entities, processes, and stores:
Data types and their purposes:
Flows and boundaries:
Dependencies and fallback assumptions:
Supplied facts:
Exercise assumptions:
Open questions and owner to ask:
Last reviewed / update trigger:

For Harbor Library, “booking created at 10:05” is a supplied synthetic fact; “the printed schedule is a fixed 09:00 snapshot” is an exercise assumption; “what source staff may use during a real outage” is an open question. These categories should remain visible in the final artifact. A learner who writes “the system has no recovery” because this chapter did not mention one has confused missing evidence with evidence of absence.

Common errors include drawing a detailed architecture from a short narrative, treating every line as a verified network connection, omitting physical copies, confusing a dependency with a failure, and leaving a model unchanged after new information arrives. The remedy is modest: keep the model tied to one decision, label uncertainty, ask its owner, and revise the record when a fact changes. Chapter 4 will use this bounded model to discuss plausible threats and ordinary failure modes without asserting that any one of them occurred.

Chapter 3 summary

Model the people, processes, stores, and information needed for a defined service decision. Treat data copies and their timestamps explicitly. A flow shows proposed movement; a trust boundary prompts a question about authority; a dependency matters only in relation to a stated outcome. Mark supplied facts, assumptions, and unanswered questions so that the model remains useful when evidence changes.

Chapter 3 exercises

Use the model and invented records above; do not test a live service. Worked results appear in the final appendix.

EX011 — Boundary and components

• Objective: Define a service model that answers a specific question without inventing implementation details.
• Input: The decision question in Section 3.1 and the six modeled parts in Section 3.2.
• Safe condition: Use the fictional case only; do not inspect a real library service.
• Steps: (1) Write the decision question. (2) Name four parts needed to answer it and classify each as entity, process, store, or copy. (3) Name one related data set that is outside this decision path and explain why. (4) Mark one unverified architectural assumption.
• Expected evidence: A scope statement and a four-row component table with one open question.
• Rubric: Full credit requires a bounded booking-decision question, appropriate roles, a reasoned exclusion of event contacts, and a visible uncertainty label. A highly detailed but unsupported network diagram does not meet the objective.

EX012 — Trace the snapshot

• Objective: Distinguish the time of a data copy from the time of a later change.
• Input: The two CSV rows in Section 3.6, a fixed 09:00 printout, and the 11:42 room question.
• Safe condition: Work only with these invented times and IDs.
• Steps: (1) Put the four relevant times in order. (2) List which booking IDs the printout can include under the snapshot assumption. (3) State what the printout cannot establish at 11:42. (4) Record the worker's defensible next action.
• Expected evidence: A short timeline and a decision note with its assumption.
• Rubric: Full credit requires SYN-001 in the printout, SYN-002 absent, an explicit snapshot assumption, and a pending or owner-confirmed decision rather than an unsupported promise.

EX013 — Flow versus dependency

• Objective: Tell information movement apart from a condition required for an outcome.
• Input: The text diagram in Section 3.4 and the two outcomes “save a reservation” and “send a confirmation.”
• Safe condition: Treat the optional messaging supplier as hypothetical; do not contact a vendor or send messages.
• Steps: (1) Name two flows shown in the diagram. (2) Write one conditional dependency for each outcome. (3) Explain whether a messaging delay necessarily proves that the reservation was not saved. (4) Name the fact an owner must confirm.
• Expected evidence: Two labeled flows, two conditional statements, and one verification question.
• Rubric: Full credit requires distinguishing a proposed data path from a required service condition and withholding a claim about the unconfirmed supplier or implementation.

EX014 — Boundary questions

• Objective: Use a trust boundary as a prompt for verification rather than as proof of a control.
• Input: The resident-to-booking-view and staff-to-staff-view arrows in Section 3.4.
• Safe condition: This is a paper review; do not test accounts or send requests to a live service.
• Steps: For each arrow, write (1) what information or action crosses it, (2) who ought to be permitted to initiate it in the fictional scenario, (3) one control question for the owner, and (4) one kind of authorized evidence that could answer that question.
• Expected evidence: A two-row table separating expected permission from observed proof.
• Rubric: Full credit requires distinct resident and staff authority, specific owner questions, and a statement that the diagram alone does not verify any implementation.

EX015 — Revise when a fact changes

• Objective: Update a model without clinging to an earlier conclusion.
• Input: A new fictional owner report says the front desk receives an approved offline schedule refreshed at 11:40 and containing SYN-002. Its accuracy has not yet been tested.
• Safe condition: Do not seek or copy real bookings; reason from this additional invented report.
• Steps: (1) Identify which earlier conclusion is weakened. (2) Add the reported offline schedule as a separate representation. (3) Specify a safe synthetic check of its timestamp and content. (4) State the decision if the check succeeds and if it fails, and note one remaining limitation.
• Expected evidence: A revised model note with report, test, branch decisions, and limitation.
• Rubric: Full credit requires treating the new information as a report, not as independently observed fact; changing the stale-09:00-only conclusion conditionally; and keeping the worker's decision within the approved fallback rule.

Continue studying — chapter 03 of 20

← Chapter 02 · Course chapter index · Chapter 04 →

Continue to the next authored lesson.