◇ OpenCyber Academy
Bachelor's · Chapter 6 · English

Chapter 6 — Discrete structures

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

Chapter 6 — Discrete structures

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Access graphs"]
  N2["6.2 Flow relations"]
  N3["6.3 Decision trees"]
  N4["6.4 Equivalence"]
  N5["6.5 Ordering"]
  N6["6.7 Applied note"]
  N7["6.8 Cut sets"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Access graphs"]
  N2["6.2 Flow relations"]
  N3["6.3 Decision trees"]
  N4["6.4 Equivalence"]
  N5["6.5 Ordering"]
  N6["6.7 Applied note"]
  N7["6.8 Cut sets"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 Access graphs]
    |
    v
[6.2 Flow relations]
    |
    v
[6.3 Decision trees]
    |
    v
[6.4 Equivalence]
    |
    v
[6.5 Ordering]
    |
    v
[6.7 Applied note]
    |
    v
[6.8 Cut sets]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) model access as graphs; (2) use relations for flow matrices; (3) apply trees to stop decisions.

6.1 Access graphs

Nodes are principals and systems; edges are can-authenticate or can-reach. A path from Internet to ledger-db that bypasses jump hosts is a finding candidate. At TRB, the graph might show the internet reaching the web tier, the web tier reaching the core API, and the jump host reaching ledger-adjacent admin. An extra edge from the web tier directly to ledger-db creates a path that skips the jump host, and that path is the finding, whether or not any single host has a known vulnerability. Sam draws only edges supported by inventory or authorized scan evidence, so each path can be defended.

6.2 Flow relations

Approved flows are a relation R ⊆ Src × Dst. Observed flows should be subsets of R when the matrix is enforced. For TRB, R might include (web tier, core API) and (jump host, ledger admin) but not (web tier, ledger-db). If observed flows include a pair outside R, either the matrix is not enforced or R is incomplete. Sam's lab compares the two sets and lists the differences, and each difference becomes a question for the network owner rather than an automatic finding, because an approved but undocumented flow is a documentation fix.

6.3 Decision trees

Stop trees: if owner asks stop → halt; else if unexplained outage → halt; else continue under ROE. Writing the tree down before a window removes argument during it. If the loan system owner says stop, Sam halts at once without asking why. If an unexplained outage appears on any in-scope host, he halts and reports, even if the outage may be unrelated. Only when neither condition holds does testing continue, and continuing still requires the method to be allowed by the ROE. Each pass through the stop tree is logged with the time and outcome, so the window log shows why testing continued or halted.

6.4 Equivalence

Hosts in the same hardening class may share method cards — but only if the ROE groups them. If TRB's ROE groups ten web servers into one hardening class, Sam can apply the same method cards to all ten and report results by class. If the ROE lists them separately, perhaps because two host payment pages, he must treat each as distinct. Equivalence is a decision the owner makes in writing, not a shortcut the tester assumes because two hosts look alike from the outside.

6.5 Ordering

Severity ranking uses ordered scores; ties break by finding id for determinism (lab_rank). Without a fixed tie-break, two findings with the same score could swap places between runs, and a board pack would show a different top item each time it was regenerated. Breaking ties by finding ID makes lab_rank produce the same order from the same data, so a change in ranking always means a change in scores. Sam records the scoring scheme in the report so readers know what the order means.

6.6 Limits

Graphs omit social engineering unless the ROE includes it. A graph of network and authentication edges says nothing about a branch employee who could be persuaded to approve a payment by phone. If the ROE excludes social engineering, Sam states that the graph covers technical paths only, so the board does not read 'no path found' as 'no way in'. The limitation sits on the same slide as the graph, in plain words. Social engineering, if later authorized, would add new edges to the same graph.

6.7 Applied note

Reachability graphs annotate edges with "authenticated" or "network-only". A network-only edge to ledger-adjacent hosts raises severity even without credentials, because credential theft elsewhere completes the path. Sam's first graphs missed that annotation and under-ranked a finding. After the correction, every edge to a payments-adjacent node carries its annotation, and lab_rank weights network-only edges to the ledger tier more heavily. The earlier under-ranked finding was re-scored and re-sent with a note explaining the change, so readers of the first version were not left with the lower rank.

6.8 Cut sets

For payments-adjacent nodes, Sam looks for cut sets of edges whose removal would isolate them from the Internet. Those edges become monitoring and control priorities even when not "vulnerable" in a scanner sense. For ledger-db, the cut set turned out to be two edges: the direct web-tier connection and admin access that bypassed the jump host. Removing those two isolates the ledger from internet-facing paths. Monitoring them costs far less than watching every host. Those two edges are also the ones F3 and the jump-host rule address.

6.9 Edge evidence

Each critical graph edge cites the inventory or scan source under ROE. Edges without sources are removed. A source might be an asset register entry, a firewall rule export or an authorized scan result with its date. An edge drawn from memory or assumption cannot be checked, so it cannot support a finding, and leaving it in would make the whole graph look more certain than it is. When a source is missing, Sam asks the owner and adds the edge back only with evidence.

6.10 Finding the cut set

Tracing a path from a compromised branch PC model to ledger-db, Sam finds four edges. Removing the web→ledger edge (F3) and requiring jump for admin cuts the remaining dangerous paths. The graph did not need fifty nodes — it needed the cut set. Showing four edges and the cut set made the fix discussion take minutes instead of an hour, because the owners could see exactly which two changes mattered.

Sam's cut-set slides use at most six edges. He deletes the rest in front of the audience to teach focus. A slide with fifty edges hides the two that matter; a slide with six makes the cut set visible to an executive in seconds. Deleting edges live also shows that the removed ones were context, not evidence. Sam keeps the full graph in the appendix, with sources for every edge, so engineers can still check his reasoning and nothing is hidden from review.

Worked example (synthetic TRB)

Sam draws web → ledger-db as an edge not in R; lab_flows later flags the same pair UNAPPROVED.

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

Graphs and relations make architecture and flow findings precise.

Continue studying — chapter 06 of 40

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →