Chapter 6 — System model for authorized testing
Lesson map
Lesson 06 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Model elements"]
N2["6.2 Entry points"]
N3["6.3 Assumptions"]
N4["6.4 Data flows"]
N5["6.5 Out of model"]
N6["6.6 Living model"]
N7["6.7 Trust zone colours"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Model elements"]
N2["6.2 Entry points"]
N3["6.3 Assumptions"]
N4["6.4 Data flows"]
N5["6.5 Out of model"]
N6["6.6 Living model"]
N7["6.7 Trust zone colours"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[Learning outcomes]
|
v
[6.1 Model elements]
|
v
[6.2 Entry points]
|
v
[6.3 Assumptions]
|
v
[6.4 Data flows]
|
v
[6.5 Out of model]
|
v
[6.6 Living model]
|
v
[6.7 Trust zone colours]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) build a simple system model for the journey planner; (2) mark entry points and data stores; (3) map OWASP WSTG themes to the model; (4) list assumptions.
6.1 Model elements
A system model names actors (rider, staff), entry points (web, API), trust zones, data stores (trip DB, logs) and external dependencies (map tiles). For NMT the model reads rider → HTTPS → API → trip DB; staff → VPN → admin UI; map tiles as external; fare cloud crossed out. Sam's one-page model is the scope picture before tools run: the fare cloud and the map-tile vendor boxes are crossed out, and owners are named on web, API and VPN only. Tools stay closed until that page is current.
6.2 Entry points
Each entry point gets a short list of WSTG themes: auth, session, access control, input handling. At NMT the entry points are the public website, the journey planner API and the staff VPN. Fare validators are not entry points for ENG-512; listing them as interesting is a model error corrected before kickoff. Each of the three gets its own WSTG theme list, so VPN checks never borrow web input-handling tests. For the staff VPN the themes stop at authentication and session handling, because input handling belongs to the website and journey planner API. Keeping the lists separate also makes the coverage statement precise: the report can say which themes were exercised on which entry point and which were left out.
6.3 Assumptions
"Staging mirrors production auth" is an assumption to validate, not a fact. Assumptions such as staging equals production config are written in the assumption log with an owner, because unwritten assumptions become scope fights mid-window. Each assumption log line names who believed it and the date it was last checked. A staging-mirrors-prod line without a check date is marked invalid until the owner compares the two configurations and dates the entry. Findings that depend on an invalid assumption are held back from the report until the comparison is done.
6.4 Data flows
Note where personal data, such as saved journeys, flows, so that tests minimise exposure. NMT's data flows show trip queries and staff admin actions, and the arrows stop at the trip DB and the staff admin UI. They do not show fare settlement. Sam refuses to draw fare flows into the ordinary model because drawing invites probing; a fare settlement arrow in the ordinary model is a documentation defect he fixes before ENG-512. The saved-journey arrow is the one he marks for minimisation, so checks on it use synthetic accounts only.
6.5 Out of model
Fare validators are omitted because they are out of scope. Out of model means the fare network, radio and card processors. Those boxes stay black on the colour map and carry the caption "specialised ROE only", and ENG-512 findings never claim coverage there. Leaving them visible but black matters: the reader sees that the systems exist and were excluded on purpose, rather than assuming they were forgotten or silently covered by the ordinary tests. Any request to test inside a black box goes back to the ROE owner as a separate engagement.
6.6 Living model
Update the model when the API gains a new payment callback, even if payment is third-party. The model is also updated when a CDN or gateway changes. Sam dates each revision and keeps the date beside the ROE hash; a model older than the last architecture change is invalid for the next window, so if architecture changed after the model date, he updates the picture before the window. The revision history shows reviewers which version of the model each window was planned against.
6.7 Trust zone colours
Sam colours Internet red, staging amber, staff green and fare black (do not enter). Black is reserved for fare so it cannot be confused with any zone where testing is allowed. Colour makes scope visible in reviews when managers skim too fast to read exclusions. The colour map is printed for the kickoff huddle, so managers who only skim text still see the exclusion. A printed map in black and white loses the point, so the kickoff copy also labels each zone in words.
6.8 Assumption log
A running list of assumptions sits under the model, and each one is marked confirmed, rejected or open before the report is issued. Entries name who believed, for example, that staging mirrored production and when that was checked. Failed assumptions become either ROE text or findings; Sam will not leave a broken staging-mirrors-prod belief as an unspoken footnote. Open entries at report time are listed in the limitations section, so readers know which conclusions rest on unconfirmed beliefs and who must close them.
6.9 Field discipline
Building the system model with the product owner takes an hour and prevents days of confusion. Sam projects a blank diagram, asks the owner to place boxes, and only then adds his own arrows. Owners correct mistaken assumptions about which database holds saved journeys and whether the admin UI shares authentication with the rider API, and those corrections change which WSTG themes matter most. The assumption log records each correction with the date it was confirmed. Field discipline for modelling is a dated diagram, coloured zones, the assumption log, and fare in black; Sam will not open ENG-512 tools until those four are current, and any gap delays tool start.
Worked example (synthetic NMT)
Sam's one-page model shows rider → HTTPS → API → trip DB; staff → VPN → admin UI; map tiles as external; fare cloud crossed out.
Synthetic case — Northline Municipal Transit (NMT). The transit agency, Sam Park and all figures are invented for teaching.
Errors and limits
Live transit systems and fare equipment are never tested without a separate, specialised authorization. This book uses synthetic data only and grants no authority to test real systems.
Exercises
- EX021 — Actors. Name two actors in the model. Rubric: 3 = rider and staff; 2 = one; 1 = vague; 0 = none.
- EX022 — WSTG theme. Pick one entry point and one WSTG theme to apply. Rubric: 3 = concrete pair e.g. API+access control; 2 = partial; 1 = vague; 0 = none.
- EX023 — Assumption check. How would Sam validate the staging-mirrors-prod-auth assumption? Rubric: 3 = compare configs/owners confirm; not assume; 2 = partial; 1 = assume true; 0 = none.
- EX024 — Why omit fare. Why omit fare validators from this model? Rubric: 3 = out of scope; 2 = partial; 1 = unimportant; 0 = none.
Synthesis
A clear system model focuses WSTG effort and records assumptions explicitly.
Continue studying — chapter 06 of 18
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →