Chapter 23 — Methods I
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Cards"]
N2["23.2 WSTG"]
N3["23.3 Rates"]
N4["23.4 Forbidden"]
N5["23.5 Quiet vs noisy"]
N6["23.6 Freeze"]
N7["23.7 Separating quiet and noisy days"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Cards"]
N2["23.2 WSTG"]
N3["23.3 Rates"]
N4["23.4 Forbidden"]
N5["23.5 Quiet vs noisy"]
N6["23.6 Freeze"]
N7["23.7 Separating quiet and noisy days"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Cards]
|
v
[23.2 WSTG]
|
v
[23.3 Rates]
|
v
[23.4 Forbidden]
|
v
[23.5 Quiet vs noisy]
|
v
[23.6 Freeze]
|
v
[23.7 Separating quiet and noisy days]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) build method cards; (2) bind methods to ROE; (3) set rate limits.
23.1 Cards
Purpose, ROE clause, tool/settings, stops, evidence.
A method card is the unit of authorized testing work. It states why the method is being run, which clause of the rules of engagement permits it, which tool and settings will be used, what conditions stop the method and what evidence it must produce. Cards stop improvisation. A tester who wants to try something not on a card must propose a new card and get it into the frozen set, or wait for a rules amendment. TrackScope schedules cards, not free-form activity.
23.2 WSTG
Select auth, session, access control themes for online banking staging.
OWASP's Web Security Testing Guide catalogues many test ideas. TRB does not run all of them every engagement. For online banking staging the priority themes are authentication, session management and access control, because failures there move customer data or money. Other themes appear when threat reporting or recent changes justify them. Selecting themes in the plan makes the engagement's depth honest. A report that claims broad web coverage after running only three themes would mislead.
23.3 Rates
Caps protect availability.
Even authorized tests can knock a service over if they send too much traffic. Method cards include rate caps: requests per second, concurrent sessions, total identities tried. The caps are set with the service owner and the SOC, who know what normal looks like. Exceeding a cap is a stop condition, not a suggestion. Sam would rather finish a method slowly across two evenings than explain an outage caused by a test that was supposed to be careful.
23.4 Forbidden
Spraying and DoS remain forbidden.
Password spraying across many accounts and denial-of-service testing are excluded from ordinary TRB windows because their impact is hard to contain and their authorization bar is higher. A tester who discovers that spraying would be interesting still does not do it. They write a note that the method was considered and excluded, which can become a recommendation for a separate, carefully scoped exercise if the risk warrants it. Forbidden means forbidden, not forbidden unless curious.
23.5 Quiet vs noisy
Prefer quiet methods when detection is also under test.
Some methods produce little log noise; others flood the SOC with alerts. When the engagement is also measuring detection, noisy methods drown the signal the SOC needs to show. Quiet methods first let the SOC demonstrate what they catch under realistic conditions. Noisy inventory scrapes belong on separate days, with a noise budget the SOC has signed. Mixing them once produced an alert blizzard that taught nothing about either detection or the inventory.
23.6 Freeze
Method set freezes after kickoff unless ROE amends.
After kickoff the scheduled cards are fixed. Adding a method mid-window would bypass the review that checked scope, rate limits and stop conditions. If a new method becomes necessary, the rules of engagement are amended in writing and the freeze lifts for that amendment only. The freeze frustrates improvisers and protects everyone else. Clients cannot claim they were surprised by a method that was not on the kickoff list, and testers cannot claim they thought an improvised method was allowed.
23.7 Separating quiet and noisy days
Quiet methods are preferred during purple windows so SOC signal is interpretable. Sam schedules noisy inventory scrapes on separate days. Mixing them produced a useless alert blizzard once; the calendar now prevents it.
The calendar block is shared with the SOC. A purple-team day shows quiet cards only. An inventory day shows noisy cards and a higher noise budget. Automatic checks refuse to schedule a noisy card onto a purple day. The blizzard taught the team that calendar design is part of method design.
23.8 Every card needs an owner
Each method card has an owner engineer. Unowned cards cannot be scheduled. Sam claims ownership before proposing a card in kickoff.
Ownership means someone keeps the card's ROE clause, tool versions and stop conditions current. Unowned cards rot: they cite retired clauses or settings that no longer match the platform. Refusing to schedule them makes ownership a practical requirement rather than a polite field. Claiming ownership before kickoff also means the proposer is volunteering to maintain the card, which reduces drive-by suggestions.
23.9 SOC noise budgets
SOC signs a noise budget per window. Exceeding it is a stop condition Sam respects immediately.
The budget is a number of alerts per hour, usually, plus a list of alert types that count. The SOC signs it because they know their staffing and their other work that night. When TrackScope or the SOC says the budget is exhausted, Sam stops noisy cards even if the window has hours left. Immediate respect for the stop builds trust. A tester who negotiates past a SOC stop once will find the next budget conversation much harder.
23.10 Splitting a card to fit the budget
SOC noise budget is 30 alerts per hour. Sam's method card would generate about 80. He splits the card across two days. The SOC lead buys him coffee; the window stays green.
Splitting preserved the testing goal and the SOC's ability to respond. The card's evidence requirements were met across both days, with clear labels so nobody thought the method had been abandoned. Coffee is optional. A green window, meaning no emergency caused by testing, is the real reward and the reason budgets exist.
23.11 Treating SOC signatures like CISO signatures
Noise budget sheet is signed like a mini-ROE. Sam treats SOC signatures with the same respect as CISO signatures.
The SOC does not own the overall authorization, but they own the detection environment the test will disturb. Their signature on the noise budget is authorization for that disturbance. Ignoring it would be ignoring a boundary as real as an excluded host. Sam's habit of equal respect also encourages the SOC to sign promptly, because they know the signature will be honoured rather than bargained away.
23.12 Automatic pause on overrun
Noise budget overruns trigger an automatic method-card pause flag in TrackScope.
Automation removes the awkward conversation in which a tester argues that just a few more requests will finish the card. The platform counts alerts attributed to the engagement, and when the budget is reached it pauses noisy cards and notifies Sam and the SOC. Finishing then requires a SOC countersignature for an extension, not a unilateral decision. The flag has stopped several polite overruns that would have become impolite outages.
23.13 Testers cannot clear their own pause
Pause flags clear only with SOC countersign. Sam cannot clear his own noise overrun.
Self-clearing would make the automatic pause theatre. The SOC countersign is a second person asserting that the environment can take more load. Sometimes they refuse and ask for a quieter continuation tomorrow. That refusal is a successful control. Recording who cleared a pause, and when, also helps later reviews understand why a noisy card continued after an overrun.
When the SOC analyst clears a flag, TrackScope stores their name, the alert count at the moment of clearing and the new budget on the card itself. The next card audit can then compare that extension with the alerts PulseMap attributed to the engagement afterwards.
23.14 Rotating card audits
Method card librarianship is a rotating duty. Each month a different engineer audits five cards for ROE clause drift. Sam's audit found a card citing a retired ROE section; it was suspended in an hour.
A retired ROE clause on a live card is a quiet authorization bug. The monthly audit catches a few each year, usually after a rules rewrite. Suspending the card immediately prevents anyone from scheduling work under a clause that no longer exists. The rotating duty spreads familiarity with the library across the team. Publishing which five cards were audited each month makes the rotation visible and harder to skip.
Worked example (synthetic TRB)
Sam's IDOR card: 1 req/s, two test users, stop on 5xx burst.
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
- EX067 — Card fields. List five method-card fields. Rubric: 3 = five from chapter; 2 = three; 1 = one; 0 = none.
- EX068 — Forbidden pair. Name two forbidden methods. Rubric: 3 = spraying and DoS; 2 = one; 1 = WSTG auth; 0 = none.
- EX069 — Freeze. Why freeze methods after kickoff? Rubric: 3 = prevent silent scope/method creep; 2 = partial; 1 = no reason; 0 = none.
Synthesis
Methods are cards bound to ROE with rates and freezes.
Continue studying — chapter 23 of 40
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →