OpenCyber AcademyLesson map
Lesson 11 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["11.1 From prose to objects"]
N2["11.2 Context changes the method"]
N3["11.3 Stop lists and windows"]
N4["Lab D — ROE activity checker"]
N5["11.4 White team"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 From prose to objects"]
N2["11.2 Context changes the method"]
N3["11.3 Stop lists and windows"]
N4["Lab D — ROE activity checker"]
N5["11.4 White team"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]
[Learning outcomes]
|
v
[11.1 From prose to objects]
|
v
[11.2 Context changes the method]
|
v
[11.3 Stop lists and windows]
|
v
[Lab D — ROE activity checker]
|
v
[11.4 White team]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) turn a signed agreement into a machine-checkable scope and ROE; (2) reject planned activities that fall outside the window or the stop list; (3) explain why asset context (owner, criticality, fragility) changes method choice; (4) keep a white-team contact reachable.
11.1 From prose to objects
An agreement written in paragraphs becomes useful when it is also a list: in-scope prefixes and names, excluded systems, allowed activities, start and end times, forbidden activities, and an emergency contact. Checkers in Chapter 2 and in this chapter operate on those lists. Ambiguous prose such as "and related systems" is a defect, not a feature.
Prose agreements become loadable lists for lab_scope and lab_roe checkers. If a field cannot be parsed, ENG-712 does not start. Priya maintains both the narrative ROE and the machine lists.
11.2 Context changes the method
A high-criticality, fragile asset may be examined by configuration review only. A low-criticality staging clone may accept more active checks. The asset record from Chapter 1 supplies that context; ignoring it produces either reckless testing or wasted caution.
At TRT the fragile production portal stays on configuration review, while a labelled staging clone may receive inventory scans. The criticality field on the asset record makes that choice, not a tester's preference on the day. Recording the choice in the ROE means a reviewer can later see why the two systems were treated differently.
11.3 Stop lists and windows
A stop list names activities that are never allowed even inside the window — for TRT, fare-system interaction and social engineering of drivers. A window names when allowed activities may run. Both are hard gates.
In the lab output a VPN review at 06:10 returns STOP because the window ends at 05:00. In studio, stop-list drills use a fake fare hostname that must produce HOLD or STOP rather than curious traffic. Both gates are checked before each action, so an allowed method at the wrong time is still refused.
Lab D — ROE activity checker
"""Lab D (ch 11): check synthetic planned activities against the rules-of-engagement window and stop list."""
from datetime import datetime
WINDOW = (datetime(2026, 11, 3, 22, 0), datetime(2026, 11, 4, 5, 0))
FORBIDDEN = {"denial-of-service", "social engineering of drivers", "fare-system interaction"}
plan = [
("2026-11-03 22:30", "external service inventory"),
("2026-11-04 04:45", "portal authentication review"),
("2026-11-04 06:10", "VPN configuration review"),
("2026-11-03 23:00", "fare-system interaction"),
]
for when, act in plan:
t = datetime.strptime(when, "%Y-%m-%d %H:%M")
if act in FORBIDDEN:
status = "STOP: forbidden activity"
elif not (WINDOW[0] <= t <= WINDOW[1]):
status = "STOP: outside window"
else:
status = "allowed"
print(f"{when} {act:32} {status}")
Run with python3 lab_roe.py. Verified output:
2026-11-03 22:30 external service inventory allowed
2026-11-04 04:45 portal authentication review allowed
2026-11-04 06:10 VPN configuration review STOP: outside window
2026-11-03 23:00 fare-system interaction STOP: forbidden activity
11.4 White team
Someone with stop authority must be reachable throughout the window. If that person cannot be reached, the session does not start. TIBER-EU-style exercises formalise this as a white-team control function; smaller engagements still need the same idea.
White-team silence means no start: if the on-call contact does not answer, the tools stay idle and the VPN review waits. TIBER-style control functions are borrowed as an idea even though TRT is not a bank. During ENG-712 only the named liaison pages the white team; side chats do not.
Worked example
Northpoint's draft plan includes a VPN review at 06:10 and a "fare-system interaction" at 23:00. The lab prints STOP for both — one outside the window, one forbidden. Priya cancels those lines before kickoff and keeps the two allowed activities.
Synthetic case. The plan lines and the 22:00–05:00 window are fictional TRT ROE objects.
Errors and limits
A checker cannot invent missing exclusions. If the agreement is silent, ask; do not assume.
Exercises
- EX031 — Two stops. Quote the two STOP lines from the lab and the reason for each.
Show marking criteria
Rubric: 3 = VPN review outside window; fare-system interaction forbidden; 2 = one correct; 1 = both allowed; 0 = none. - EX032 — Fragile context. The timetable API is marked fragile. Which method change belongs in the ROE?
Show marking criteria
Rubric: 3 = throttle/limit or switch to config review; written in ROE; 2 = vague caution; 1 = ignore; 0 = none. - EX033 — Unreachable white team. On the morning of the window the on-call white-team contact does not answer. What happens?
Show marking criteria
Rubric: 3 = do not start; escalate to CISO/named deputy; restart only when contact confirmed; 2 = delay; 1 = start anyway; 0 = none.
Synthesis
Scope and ROE are lists you can check; context chooses the method; no reachable white team means no start.
Continue studying — chapter 11 of 30
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →