OpenCyber Academy
Bachelor's · Chapter 16 · English
Course code: OCA-111Chapter 16: OCA-111-C016

Chapter 16 — Security architecture

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Zones"]
  N2["16.2 Flows"]
  N3["16.3 Fail closed"]
  N4["16.4 Conduits"]
  N5["16.5 Third parties"]
  N6["16.6 Diagrams"]
  N7["16.7 Detecting rule changes during an engagement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Zones"]
  N2["16.2 Flows"]
  N3["16.3 Fail closed"]
  N4["16.4 Conduits"]
  N5["16.5 Third parties"]
  N6["16.6 Diagrams"]
  N7["16.7 Detecting rule changes during an engagement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 Zones]
    |
    v
[16.2 Flows]
    |
    v
[16.3 Fail closed]
    |
    v
[16.4 Conduits]
    |
    v
[16.5 Third parties]
    |
    v
[16.6 Diagrams]
    |
    v
[16.7 Detecting rule changes during an engagement]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) draw TRB zones; (2) enforce flow matrices; (3) fail closed.

16.1 Zones

Internet, DMZ, corporate, payments-adjacent (restricted), assessment.

A zone groups systems that share a level of trust and the same rules for what may reach them. TRB's internet zone is untrusted. The DMZ holds the public banking front end, which must talk to both the internet and the core. The corporate zone holds staff laptops and email. The payments-adjacent zone is restricted because it borders the SWIFT gateway and the ledger, and the assessment zone holds the testing platform. Testers read a finding through the zones it crosses. A path from the corporate zone straight into the payments-adjacent zone is serious even when the system at the far end is only moderately sensitive.

16.2 Flows

Approved matrix is authoritative; lab_flows flags web→ledger-db.

"""Lab 22: flag synthetic TRB data flows missing from the approved flow register."""
approved = {("branch-pc","core-api"), ("web","core-api"), ("core-api","ledger-db"), ("jump","ledger-db")}
seen = [("branch-pc","core-api"), ("web","core-api"), ("core-api","ledger-db"), ("web","ledger-db"), ("jump","ledger-db")]
for s, d in seen:
    print(f"{s:10} -> {d:10} {'approved' if (s,d) in approved else 'UNAPPROVED'}")

Run with python3 lab_flows.py. Verified output:

branch-pc  -> core-api   approved
web        -> core-api   approved
core-api   -> ledger-db  approved
web        -> ledger-db  UNAPPROVED
jump       -> ledger-db  approved

The register is the bank's statement of intent, and observed traffic is evidence of what actually happens. The lab compares the two and reports flows that were seen but never approved. A direct path from the web tier to the ledger database bypasses the core API, which is where authorization and input checks live, so anything that compromises the web server could reach the ledger without those checks. The finding records when the flow was observed, its source and destination, and the fact that no register entry or change ticket covers it.

16.3 Fail closed

Proxies and TrackScope deny when policy missing.

A control that fails closed blocks traffic or actions when it cannot decide, for example because its policy file is missing, its database is unreachable or a rule is malformed. A control that fails open lets everything through in those cases, which is convenient during an outage and disastrous if an attacker can trigger the failure. Sam tests the behaviour safely in staging. He renames TrackScope's policy file and confirms that the platform refuses to start a test, rather than running without scope checks. The proxy test works the same way: with its rule set unavailable, outbound requests must be refused.

16.4 Conduits

Owned firewall rules.

A conduit is the approved path between two zones, made up of the firewall rules, ports and protocols that let one zone talk to another. Every conduit needs an owner, the person who can explain why the path exists, approve changes and decide whether it is still needed. Rules without owners pile up: a port opened for a migration years ago remains because nobody knows whether removing it will break something. When Sam finds traffic using a conduit, the first question is not whether the rule allows it but who owns the rule, because only that person can say whether the traffic is intended.

16.5 Third parties

Processors need their own authorization.

TRB uses outside companies for SMS one-time codes, card processing and cloud hosting. Their systems sit in TRB's architecture diagrams, but TRB does not own them and cannot authorise anyone to test them. Testing a vendor's service usually requires the vendor's written permission under its own terms, and some cloud providers publish rules about what customers may test in their own tenancy. Sam can test how TRB's systems use a third-party service, for example whether the bank validates the vendor's responses, while leaving the vendor's infrastructure alone unless that vendor has signed off.

16.6 Diagrams

Dated and owned.

An architecture diagram is a claim about how systems are connected at a particular time, and an undated one invites testers and auditors to trust a picture that may be years old. Every TRB diagram carries a date, an owner and the version of the flow register it reflects. Before an engagement, Sam checks that the diagram's date is later than the last major change to the systems in scope. If it is not, the first task is to confirm the current layout with the owner. Testing against an outdated diagram can mean missing new paths or, worse, probing addresses that now belong to something out of scope.

16.7 Detecting rule changes during an engagement

Matrix excerpts are hashed and stored beside the ROE. If network changes mid-engagement, Sam diffs the live rules against the hash and pauses if they diverge without a change ticket.

The hash fixes the environment the authorization was written for. If rules change during the window, the test may now reach places the scope assumed were unreachable, or results may reflect a temporary configuration rather than the normal one. Pausing gives the conduit owner time to confirm that the change was intended. If it was, the scope is re-checked against the new rules. If it was not, an unexpected change is itself something the bank needs to know about.

16.8 Contacting conduit owners

Each conduit lists an on-call. During tests Sam messages the conduit on-call, not a general IT inbox, when rules misbehave.

A general inbox is read by whoever is free, possibly hours later, and that person may not know the conduit or have the authority to change it. During a testing window both delays matter. If a firewall rule unexpectedly blocks the test, or unexpectedly allows something it should not, the person who owns that conduit can decide quickly whether to pause, correct the rule or continue. The on-call contact is listed in the flow register next to the conduit, so testers do not have to work out who to call while something is going wrong.

16.9 Marking flows that need third-party authorization

Flow matrices include a column "third-party auth needed?". Yes rows cannot be tested under TRB ROE alone.

The column makes a legal boundary visible at the place testers plan their work. A flow from TRB's core API to the SMS vendor's endpoint is marked yes. Sam may observe what TRB sends and receives, but may not probe the vendor's endpoint for weaknesses. The column is filled in by whoever registers the flow, not by the testers, so the decision is made by people who know the contracts. When a yes row matters to an engagement, the plan includes requesting the vendor's permission or noting the gap in the report.

16.10 A temporary rule with no expiry

When lab_flows shows web→ledger-db, network claims the rule is temporary. Sam asks for the change ticket and kill-date. Neither exists. Temporary without expiry becomes F3's twin process finding.

The technical finding is the open path. The process finding is that a rule could be added as temporary without any mechanism to remove it. Fixing only the first would close this rule and leave the next temporary one just as likely to persist. The process finding recommends that the firewall change workflow require an expiry date for temporary rules and alert the owner a week before it.

16.11 Pointing a curious tester to the vendor's programme

Third-party column "yes" blocked a curious scan of the SMS vendor. Sam sent the vendor's bug bounty link instead. Boundaries can still be helpful.

The colleague's curiosity was reasonable, since the vendor's endpoint looked dated and probably had problems. Scanning it from TRB's network under TRB's rules would have been unauthorised testing of another company. The vendor's bug bounty sets out what researchers may test, how and with what legal protection. Following it, from personal equipment and on personal time where the programme allows, kept the interest legitimate and kept TRB out of it.

16.12 Making expiry dates visible

Kill-date calendar invites include the CISO alias as optional attendee for visibility.

The invite is created when a temporary rule is approved and falls on its expiry date. The owner is the required attendee. The CISO's office is optional, which means it is not expected to act but can see the full list of temporary rules simply by opening the calendar. On the day, the owner removes the rule or extends it with a new approval and a new date. An invite nobody acts on remains on the shared calendar as a past event with no change ticket, which makes the miss easy to find.

16.13 Linking technical and process findings

Twin process findings link to F3 with a related-id field. Boards see technical and process debt together.

Without the link, the two findings travel separately. The technical one is fixed quickly and disappears from reports, while the process one waits in a governance backlog with no visible connection to any real exposure. The related-id field keeps them together, so a board report shows that a serious open path existed and why it could exist. Reviewers do not close the technical finding as resolved at its root while its process twin is still open.

16.14 Architecture office hours

Architecture office hours use a projector and a red pen. Unowned conduits get circled until an owner appears in the register. Sam refuses to schedule tests through unowned conduits even if the firewall rule exists. Ownership is part of authorization.

A circled conduit stays on the projected diagram from week to week, which puts gentle public pressure on the team whose firewall rule it is. Refusing to test through unowned conduits is not obstruction. Without an owner there is nobody who can accept the risk of the test, pause it or explain unexpected results, so the precondition for authorised testing is missing.

Worked example (synthetic TRB)

lab_flows prints web -> ledger-db UNAPPROVED; Sam opens F3.

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

Synthesis

Architecture is zones, owned flows and fail-closed defaults.

Continue studying — chapter 16 of 40

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →

Worked answers

EX046. web -> ledger-db UNAPPROVED

EX047. Deny testing until policy loads.

EX048. No; the processor must authorize its own systems.