OpenCyber AcademyLesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Dependencies"]
N2["22.2 Flow lab"]
N3["22.3 Ownership"]
N4["22.4 Third parties"]
N5["22.5 Breaks"]
N6["22.6 Secrets"]
N7["22.7 Expiring temporary flows"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Dependencies"]
N2["22.2 Flow lab"]
N3["22.3 Ownership"]
N4["22.4 Third parties"]
N5["22.5 Breaks"]
N6["22.6 Secrets"]
N7["22.7 Expiring temporary flows"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Dependencies]
|
v
[22.2 Flow lab]
|
v
[22.3 Ownership]
|
v
[22.4 Third parties]
|
v
[22.5 Breaks]
|
v
[22.6 Secrets]
|
v
[22.7 Expiring temporary flows]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) map dependencies; (2) flag unapproved flows; (3) assign owners.
22.1 Dependencies
Core API, ledger DB, fraud service, SMS, card processor.
A dependency list for testing is the set of systems the target needs in order to behave normally. Online banking at TRB needs the core API, the ledger database, a fraud-scoring service, an SMS provider for one-time codes and a card processor for payment steps. If any of those is down or out of scope, parts of the application cannot be tested honestly. The list also shows where findings might really belong. A failure that looks like a banking-app bug may be a misconfigured fraud service. Sam confirms each dependency's owner and authorization status before kickoff.
22.2 Flow lab
lab_flows marks web→ledger-db UNAPPROVED.
The lab compares observed traffic with the approved flow register and prints any path that lacks an entry. A direct web-to-ledger path is the classic example: it skips the core API's authorization checks and gives a compromised web host a route into the database. Running the lab is not the finding. The finding is the unapproved path plus the missing change ticket and owner. Testers save the lab output beside the engagement record so that a later dispute about whether the path existed can be answered with a dated artefact.
22.3 Ownership
Each flow has a control owner.
Ownership answers who may approve a change, who receives a finding and who can stop a test that uses the flow. A flow with no owner cannot be safely tested, because nobody can accept the risk or fix what breaks. TRB's register rejects new flows without an owner field, and Sam's pre-engagement check lists any in-scope flows whose owner has left the bank. Replacing a departed owner is a planning task, not a mid-window surprise. Findings filed against unowned flows tend to sit untouched, which is another reason ownership is required up front.
22.4 Third parties
Separate authorization.
Dependencies that belong to other companies need those companies' permission before anyone probes them. TRB's authorization covers TRB systems. The SMS vendor, the card processor and the cloud host each have their own rules. Sam can observe how TRB calls them and whether TRB validates their responses, which tests TRB's code. He cannot run vulnerability scans against their endpoints unless their programmes say so. The distinction is written into the method cards so that a curious tester does not improvise.
22.5 Breaks
Vendor outages are stops, not hammering opportunities.
When a dependency is failing, continuing to send traffic rarely produces useful security evidence and often makes the outage worse. The rules of engagement treat a confirmed vendor outage as a stop condition for methods that need that vendor. Sam records the outage, notifies the engagement lead and moves to methods that do not depend on the broken path. Hammering a down service to see how it fails is a denial-of-service test in disguise and is forbidden unless the ROE explicitly allows it in a dedicated window.
22.6 Secrets
API keys in repos are TRB findings.
An API key committed to a source repository is a credential in every clone, every backup and often every continuous-integration log. Even after the key is removed from the latest commit, history still holds it. Sam's findings for keys in repos recommend rotating the key, removing it from history where feasible, adding a secret scanner to the pipeline and recording an owner for the new secret in the vault. The finding severity depends on what the key unlocks. A read-only analytics key differs from a key that can move money.
22.7 Expiring temporary flows
Kill-dates on temporary flows page both the owner and Sam three days prior. If nobody responds, TrackScope marks the flow expired and denies tests that relied on it until renewed in writing.
Temporary flows without expiry become permanent. The page and the automatic expiry turn temporary into a real time limit. Denying tests that used the expired flow is deliberate. It stops an engagement from quietly relying on a path the bank no longer meant to keep, and it forces a written renewal that restates the business reason.
22.8 Scanning TRB-owned repositories
Repo secret scans run on TRB-owned code listed in ROE. Sam opens findings for keys with no owner in the asset model.
The scan covers only repositories the engagement is authorized to examine. Findings distinguish keys that already have vault owners from keys that appear to be orphans. An orphaned key is urgent because nobody is rotating it. Linking each finding to the asset model also shows when a key belongs to a system outside scope, in which case Sam reports it to the system owner without testing further.
22.9 Renewals need a reason
Pages for kill-dates include the original business reason. Renewals without reasons are denied.
A renewal that says extend three months teaches nothing and invites eternal temporary rules. Requiring the original reason, and a sentence on why it still applies, makes the owner notice when the project that needed the flow has finished. Denied renewals appear in a weekly list that Sam reviews with the architecture owner. Patterns of denial often point to a project that should either finish or accept a permanent, reviewed conduit.
22.10 When the primary owner is on leave
Kill-date pages fire; the owner is on leave. Backup owner renews with a reason. Sam notes the backup-owner field as mandatory going forward — single-owner expiry pages are fragile.
A control that depends on one person being at their desk fails during holidays and illness. The backup owner had already been briefed on the flow's purpose, so the renewal took minutes. Making the backup field mandatory means the next temporary flow cannot be created until two people can speak for it. Fragility removed at registration time does not have to be discovered during a page storm.
22.11 A renewal that made risk visible
Expiry without reason was denied; the owner wrote "PCI segmentation project delay". Now the risk is visible, not eternal.
The sentence did two jobs. It renewed the flow for a bounded time, and it told anyone reading the register why a risky path still existed. Project delays are real; unspoken delays become folklore. When the segmentation project later finished, the same register entry made it obvious that the flow's reason was gone and the kill-date should not be renewed again.
22.12 Backup owners must acknowledge
Backup owners must acknowledge in the ticket UI; silence is not acceptance.
Listing someone as backup without their acknowledgement creates a false sense of coverage. The UI requires a click that records the person, the time and the flow. Until that click happens, the temporary flow cannot be approved. The rule has slowed a few registrations and prevented several quiet gaps where the named backup had never heard of the flow.
Backup names written on a ticket without a click disappear when that person changes teams. The acknowledgement click is what turns a name into a duty.
22.13 Blocking closeout without a backup
Mandatory backup-owner fields block ticket closeout. Sam loves blocking closeout.
Change tickets that open temporary flows cannot close until the backup acknowledgement exists. Blocking closeout is more reliable than sending reminders, because delivery pressure already focuses on closing tickets. The block is visible in the same place project managers already look. Sam's preference for blocks over reminders comes from watching reminder-based processes fail whenever the team is busy.
Delivery pressure dissolves hallway agreements. The block forces the named backup owner to acknowledge the flow before the change ticket can close, which is the control.
22.14 Postmortems for expired flows
Flow expiry postmortems ask whether the original business reason still exists. If the project finished, the flow dies. If the project continues, a new kill-date is mandatory. Eternal temporary rules are renamed findings in the postmortem notes.
The postmortem is short: reason, outcome, next kill-date or deletion. Renaming eternal temporary rules as findings makes the pattern visible to the same people who see other risk. A flow that survives every postmortem without a living reason is a process failure, not a networking necessity. Writing the postmortem the week a flow expires, not months later, keeps the business reason honest.
Worked example (synthetic TRB)
Sam tickets UNAPPROVED web→ledger-db to network and app owners jointly.
Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.
Errors and limits
This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.
Exercises
- EX064 — Lab line. Quote the UNAPPROVED lab line.
Show marking criteria
Rubric: 3 = web -> ledger-db UNAPPROVED; 2 = partial; 1 = wrong; 0 = none. - EX065 — Joint ticket. Why ticket network and app together?
Show marking criteria
Rubric: 3 = flow needs both routing and app behaviour changes; 2 = partial; 1 = only one; 0 = none. - EX066 — Vendor hammer. What if SMS vendor times out?
Show marking criteria
Rubric: 3 = stop related checks; no retry storm; 2 = partial; 1 = flood retries; 0 = none.
Synthesis
Dependencies and flows are owned; unapproved edges become tickets.
Continue studying — chapter 22 of 40
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →