Chapter 10 — Ethics and authorized practice
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 ROE essentials"]
N2["10.2 Offline check"]
N3["10.3 Pressure"]
N4["10.4 Responsible disclosure"]
N5["10.5 Conflicts"]
N6["10.6 Dual-use teaching"]
N7["10.7 No exploit code in the findings system"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 ROE essentials"]
N2["10.2 Offline check"]
N3["10.3 Pressure"]
N4["10.4 Responsible disclosure"]
N5["10.5 Conflicts"]
N6["10.6 Dual-use teaching"]
N7["10.7 No exploit code in the findings system"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 ROE essentials]
|
v
[10.2 Offline check]
|
v
[10.3 Pressure]
|
v
[10.4 Responsible disclosure]
|
v
[10.5 Conflicts]
|
v
[10.6 Dual-use teaching]
|
v
[10.7 No exploit code in the findings system]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) list ROE essentials; (2) check targets offline; (3) handle pressure to exceed scope.
10.1 ROE essentials
Scope, exclusions, methods, window, emergency contacts, data handling, report audience — NIST SP 800-115 and PTES both put authorization first.
The rules of engagement turn a general permission into instructions a tester can check before each action. At TRB they list the networks and hostnames in scope, name the SWIFT gateway and the production ledger as excluded, permit authenticated web testing but forbid denial-of-service and social engineering, and fix testing to weeknights between 20:00 and 02:00. They also name who answers the phone if something breaks, how captured data is stored, and who receives the report. A rule that is not written down does not exist when it is needed at 23:40.
10.2 Offline check
lab_scope classifies proposed targets before any packet.
"""Lab 10: check a synthetic TRB target list against written scope and exclusions (no traffic sent)."""
import ipaddress
scope = [ipaddress.ip_network("198.51.100.0/26")]
excluded = {ipaddress.ip_address("198.51.100.20")} # SWIFT gateway, owner excluded
for t in ["198.51.100.5", "198.51.100.20", "198.51.100.70", "203.0.113.9"]:
ip = ipaddress.ip_address(t)
v = "EXCLUDED" if ip in excluded else "in scope" if any(ip in n for n in scope) else "OUT OF SCOPE"
print(f"{t:15} {v}")
Run with python3 lab_scope.py. Verified output:
198.51.100.5 in scope
198.51.100.20 EXCLUDED
198.51.100.70 OUT OF SCOPE
203.0.113.9 OUT OF SCOPE
Running the classifier before any traffic turns scope from something a tester remembers into something a tester can show. The list of proposed targets, the version of the scope file and the output are saved together in the engagement folder. If a later dispute asks why one host was tested, the answer is the saved output, not a recollection. The check is deliberately strict: an address outside every listed range is refused, even when it looks like part of the same service, until the scope file is amended and signed.
10.3 Pressure
"Just add the SWIFT box" is refused until written exclusion changes — which they will not for ordinary tests.
Pressure rarely arrives as an order to break rules. It comes as a reasonable-sounding shortcut from someone senior, late in a window, when the extra host would make the report look more complete. Sam's answer follows a script: thank them, explain that the gateway is excluded in the signed rules, and offer to raise a scope change with its owner for a future window. The exclusion exists because the gateway's owner has not accepted the operational risk, and no one on a test call can accept it for them. Refusing politely and in writing protects both the tester and the person who asked.
10.4 Responsible disclosure
Vendor bugs found in third-party software follow vendor paths only with CISO approval.
A flaw in a commercial product that TRB uses belongs partly to TRB and partly to every other customer of that product. Sam records it in FindingsDesk as a TRB finding with a compensating control, then passes the technical detail to the CISO, who decides whether to contact the vendor and under which disclosure timeline. Contacting the vendor directly, or posting about it, could expose TRB as an unpatched customer before a fix exists. The report to the vendor carries enough detail to reproduce the bug safely and nothing about TRB's wider environment.
10.5 Conflicts
Sam does not test systems owned by family businesses on TRB time or tools.
A conflict of interest does not need bad intent to damage an engagement. Someone who tests a relative's company with the bank's scanner uses TRB resources outside TRB's authority, and any finding they produce is open to the charge that it was shaded for a personal reason. The same reasoning applies inside the bank: a tester whose friend owns the application under review should declare it before scoping. Declaring a conflict early costs one email and possibly a reassignment. Declaring it after the report has gone out can cost the credibility of every finding in it.
10.6 Dual-use teaching
Exploit details for real payment products are out of curriculum scope.
The skills in this book can be misused, so the book draws a line at what it teaches in detail. It explains weakness classes, how authorized testers confirm them safely and how to report them, using synthetic systems. It does not give working exploit chains for real card terminals, payment switches or banking platforms, because such material helps an attacker more than a learner. A student who wants to go further does so in a sanctioned lab under supervision. The test of any teaching example is whether a defender learns more from it than an attacker gains.
10.7 No exploit code in the findings system
Dual-use policy examples include refusing to paste exploit PoCs into FindingsDesk even when a vendor asks "for repro". Reproduction at TRB uses configuration evidence and authorized accounts, not weaponised snippets.
FindingsDesk is read by developers, auditors and managers, and its exports reach vendors. A working proof-of-concept stored there would spread to every one of those readers. Sam's findings show the conditions instead: the misconfigured setting, the request an authorized test account sent and the response that proved the weakness. A developer can confirm the issue in a test environment from that description. When a vendor insists on more, the CISO decides what to share and over which secure channel.
10.8 Gift and conflict log
Sam logs any vendor gifts or outside bank accounts that could bias scope decisions. Transparency is cheaper than recusal fights mid-engagement.
The log is a short dated table: what was received or held, from whom, and which engagements it might touch. Small things count because they show a pattern. A conference ticket from a scanner vendor matters if Sam later recommends that vendor's product in a report. The security lead reviews the log before assigning testers, which settles recusals at planning time, when swapping a tester is easy. An entry is not an accusation; an unlogged gift found later is treated as one.
10.9 Tabletop on the rules of engagement
Annual tabletop walks a missing emergency-contact scenario. Sam's team practices postponing rather than improvising.
A tabletop costs an hour and no packets. The facilitator reads out a situation: a test is about to start and the named emergency contact does not answer. Each participant says what they would do and which rule tells them so. The useful outcome is the gaps it exposes. One year the team found that the rules named a contact who had changed roles three months earlier. Updating that name before the next window was the most valuable result of the session.
10.10 Postponing when the contact is unreachable
Tabletop: emergency contact unreachable. Sam's team postpones the window in writing within five minutes. Improvised verbal approval from a random manager is scored as a fail condition in the tabletop. Postponement is success.
The instinct to keep going comes from the cost of rescheduling, but continuing without a reachable contact means that if a service degrades, nobody with authority can tell the testers to stop. A manager who happens to be online may mean well, yet they are not named in the rules and cannot accept the risk. The written postponement records the time, the attempts to reach the contact and the next proposed window, so the delay is documented rather than blamed.
10.11 Recusing from a relative's vendor
Sam's conflict log once listed a sibling working at a fintech vendor. He recused from a test involving that vendor's library. Recusal is quieter than scandal.
The library was a small part of the engagement, which made it tempting to stay on and just skip that component. The security lead chose clean separation instead. Another tester took every finding that touched the library, and Sam's name was left off those records. Had the test found a serious flaw, the vendor could not argue that a relative had either exaggerated or softened it. The log entry, written months earlier, made the decision a two-minute task rather than an argument.
10.12 Postponement templates
Postponement templates include SOC and CISO aliases pre-filled. Sam sends postponements in under three minutes during drills.
A template removes decisions from a stressful moment. It already lists the engagement id, the recipients who must know (the SOC, so it does not hunt for testers who are no longer testing, and the CISO's office), and fields for the reason, the attempts made and a proposed new window. The tester fills in facts, not wording. Pre-filled aliases matter because individual names go out of date, while role addresses are maintained by the teams that own them.
10.13 Timing the postponement drill
Three-minute postponement drill is timed with a visible clock. Over three minutes fails the drill.
The limit is not arbitrary. TRB's SOC escalates unexplained scanning after five minutes, so a postponement sent within three reaches the analysts before they start an incident for activity that has already stopped. A visible clock also shows where time goes. In early drills most of it went on finding the template, which led to a pinned link in the engagement channel. Drills are scored on whether the message arrived, whether it went to the right roles and whether it was accurate, not on speed alone.
Worked example (synthetic TRB)
lab_scope marks 198.51.100.20 EXCLUDED and 198.51.100.70 OUT OF SCOPE; Sam removes both from the plan.
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
- EX028 — Excluded line. What does the lab print for 198.51.100.20? Rubric: 3 = EXCLUDED; 2 = out of scope; 1 = in scope; 0 = none.
- EX029 — Pressure answer. How does Sam answer "add SWIFT just this once"? Rubric: 3 = refuse until written ROE change; SWIFT stays excluded; 2 = refuse; 1 = agree; 0 = none.
- EX030 — ROE list. Name five ROE essentials. Rubric: 3 = five of scope, exclusions, methods, window, contacts, data, audience; 2 = three; 1 = one; 0 = none.
Synthesis
Ethics is operationalised as checklists, refusals and offline scope math.
Continue studying — chapter 10 of 40
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →