Chapter 2 — Computing systems
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Layers"]
N2["2.2 Assessment platform"]
N3["2.3 Trust boundaries"]
N4["2.4 Fragility"]
N5["2.5 Inventory drift"]
N6["2.6 Practice rule"]
N7["2.7 Applied note"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Layers"]
N2["2.2 Assessment platform"]
N3["2.3 Trust boundaries"]
N4["2.4 Fragility"]
N5["2.5 Inventory drift"]
N6["2.6 Practice rule"]
N7["2.7 Applied note"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX004"]
[Learning outcomes]
|
v
[2.1 Layers]
|
v
[2.2 Assessment platform]
|
v
[2.3 Trust boundaries]
|
v
[2.4 Fragility]
|
v
[2.5 Inventory drift]
|
v
[2.6 Practice rule]
|
v
[2.7 Applied note]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes
You will (1) map TRB's computing layers; (2) place the assessment platform; (3) explain why ledger hosts differ from web hosts.
2.1 Layers
Branches use thin clients; staff use managed PCs; apps run on VMs; the ledger sits on hardened hosts with change control measured in weeks. Testers who treat every host like a lab VM cause outages. A scan rate that is harmless against a test VM can starve a ledger host whose change window is weeks away. Sam therefore records each host's layer in the scope file, and TrackScope applies stricter limits to the ledger tier than to web hosts. Thin clients add little attack surface but much dependency.
2.2 Assessment platform
TrackScope (scope checker), FindingsDesk (tickets) and PulseMap (ATT&CK coverage) are TRB's synthetic platform Sam helps build. They run on isolated infrastructure and must fail closed on scope. Failing closed means that when TrackScope cannot load its scope file it denies every request rather than allowing all. Sam treats that as the platform's most important property: a dashboard outage is an inconvenience, but a scope checker that defaults to allow could send test traffic to SWIFT-adjacent hosts. FindingsDesk and PulseMap inherit the same rule.
2.3 Trust boundaries
Internet to web tier, web to core API, jump hosts to ledger-adjacent admin — each crossing is a place findings appear. At each crossing Sam asks what the next layer trusts about the previous one. The web tier trusts that internet requests are anonymous; the core API trusts that web-tier calls are already authenticated; ledger-adjacent admin trusts that the jump host verified the operator. A finding usually sits where one of those assumptions is false, so Sam's method cards are organised by boundary rather than by tool, and each card names the trust assumption it tests.
2.4 Fragility
Ledger and SWIFT-adjacent systems are usually out of ordinary pentest scope or gated by extreme controls. NIST SP 800-115 still applies to planning even when technical intensity is low. For TRB, that means the ROE may allow only document review and configuration reading near the ledger, with no active scanning at all. Planning still covers who approves, which evidence is collected and how a stop is called. Low intensity does not mean low rigour; it means the rigour moves into preparation and review.
2.5 Inventory drift
Cloud projects add tenants faster than diagrams update. Authorized testing against stale diagrams is a process finding. When a new cloud tenant appears in billing data but not in the diagram used to write the ROE, the scope is already out of date. Sam reports that as a process finding in its own right: the bank cannot protect, or authorize testing of, systems it has not recorded. He compares the asset register with billing exports each month and sends differences to the ROE owner before the next window opens.
2.6 Practice rule
Sam never assumes a hostname's layer from its name alone; he checks the asset register. A host called web-test-03 may in fact sit in the ledger tier after a migration, and a host called ledger-legacy may have been retired. Only the register, with its named owner and layer, decides how TrackScope treats a host. When the register and the name disagree, Sam asks the owner and records the answer before testing. Name-based guesses are logged as near-misses when caught. The owner's answer is copied into the scope file's comments.
2.7 Applied note
PulseMap's fail-closed rule is tested in CI by deleting the scope file and asserting every API returns deny. Sam added that test after a staging misconfiguration briefly served empty allow lists. Dashboards that cannot deny are worse than no dashboards. He demos the deny path to every new intern in their first week. The CI test also covers a corrupted file, not just a missing one. Both paths must return deny on every endpoint, including the health check, before the build is allowed to pass.
2.8 Platform zoning
TrackScope, FindingsDesk and PulseMap sit in an assessment zone with controlled conduits to staging only. Sam reviews those conduits each quarter the same way he reviews TRB business flows — because the platform can hurt the bank if miswired. A conduit from the assessment zone to production would let a misconfigured job send traffic to live systems, so its absence is checked, not assumed. Each review records which conduits exist, who approved them and when they were last used. Unused conduits are removed rather than left open for convenience.
2.9 Denominator bug
A PulseMap bug once defaulted n to 1. Sam's regression test sets n=0 and expects an error tile, not 100%. With n defaulting to 1, a single touched host would have shown as 100% coverage, exactly the misleading percentage Chapter 1 warns against. The regression test now runs on every build, and PulseMap refuses to draw a coverage tile without an explicit denominator from the scope file. An error tile is honest; a confident number built on a default is not. The fix shipped with a changelog entry naming the bug.
2.10 Database-outage game day
During a platform game day Sam kills the FindingsDesk database. TrackScope continues to deny out-of-scope requests using its local cache while queueing drafts to disk. PulseMap shows a degraded banner. No test traffic is allowed to "fail open" just because a ticket system is down. The game day note becomes a sales slide for why assessment tooling is safety tooling. The cache itself has a time limit, so a long outage eventually denies everything. After the drill, the team writes down how long the cache may be trusted and who decides when it expires.
Worked example (synthetic TRB)
Sam places PulseMap in the assessment VLAN, not on a branch PC image, so a compromised dashboard cannot mint scope files.
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
- EX004 — Fragile systems. Name two TRB system classes usually out of ordinary test scope. Rubric: 3 = ledger and SWIFT-adjacent (or similar); 2 = one; 1 = website; 0 = none.
- EX005 — Fail closed. What should TrackScope do if the scope file will not load? Rubric: 3 = deny testing / fail closed; 2 = partial; 1 = allow all; 0 = none.
- EX006 — Layer check. How does Sam confirm a host's layer? Rubric: 3 = asset register / owner, not name guessing; 2 = partial; 1 = guess from name; 0 = none.
Synthesis
Layers and fail-closed platform design keep authorized testing from becoming accidental production change.
Continue studying — chapter 02 of 40
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →