Chapter 22 — Authorized offensive security and red team: automation
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Automate the boring, inspectable parts"]
N2["Lab H — report builder"]
N3["22.2 Keep humans on the gates"]
N4["22.4 Version with the engagement"]
N5["22.5 What not to scrape"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Automate the boring, inspectable parts"]
N2["Lab H — report builder"]
N3["22.2 Keep humans on the gates"]
N4["22.4 Version with the engagement"]
N5["22.5 What not to scrape"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Automate the boring, inspectable parts]
|
v
[Lab H — report builder]
|
v
[22.2 Keep humans on the gates]
|
v
[22.4 Version with the engagement]
|
v
[22.5 What not to scrape]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) automate report tables and status counts from structured findings; (2) decide which steps must stay human; (3) apply rate limits and dry-run flags to any automation that could touch systems; (4) version automation scripts with the engagement.
22.1 Automate the boring, inspectable parts
Building a Markdown table from a finding list, counting open versus fixed, sorting by severity — these are ideal for scripts. They reduce copy errors and produce identical artefacts for the reviewer.
Priya's rule of thumb is that a script may rearrange what a person already decided but may not decide anything itself. Sorting four findings by severity is safe because the severities were set during validation; guessing a severity for a record that lacks one is not. When the builder and a hand-made table disagree, the difference is treated as a bug in one of them and traced before the draft goes out.
Lab H — report builder
"""Lab H (ch 22): build a Markdown executive table from synthetic findings."""
from collections import Counter
findings = [
{"id": "F-01", "sev": "high", "status": "open", "tid": "T1078"},
{"id": "F-04", "sev": "low", "status": "accepted", "tid": "T1190"},
{"id": "F-07", "sev": "high", "status": "open", "tid": "T1133"},
{"id": "F-09", "sev": "critical", "status": "fixed", "tid": "T1552"},
]
rank = {"critical": 0, "high": 1, "medium": 2, "low": 3}
print("| ID | Severity | ATT&CK | Status |")
print("|---|---|---|---|")
for f in sorted(findings, key=lambda f: (rank[f["sev"]], f["id"])):
print(f"| {f['id']} | {f['sev']} | {f['tid']} | {f['status']} |")
c = Counter(f["status"] for f in findings)
print(f"open={c['open']} fixed={c['fixed']} accepted={c['accepted']}")
Run with python3 lab_report.py. Verified output:
| ID | Severity | ATT&CK | Status |
|---|---|---|---|
| F-09 | critical | T1552 | fixed |
| F-01 | high | T1078 | open |
| F-07 | high | T1133 | open |
| F-04 | low | T1190 | accepted |
open=2 fixed=1 accepted=1
22.2 Keep humans on the gates
Authorization decisions, white-team calls, severity disputes and go/no-go notes stay human. Automating "approve scope" is how organisations accidentally authorize the wrong prefix.
The line is drawn at decisions that change who or what may be touched. A script can tell the white team that a planned card targets an address outside the signed scope list, but only a named person can say whether the card stops or the scope is amended. Proposals to automate scope approval for ENG-712 are closed with a pointer to this rule rather than debated each time.
22.3 Dry-run and rate limits
Any automation that could send traffic needs a dry-run mode that prints what it would do, and a rate limit agreed in the ROE. Classroom labs never send traffic; production tools must still show the same discipline.
A dry run for an ENG-712 tool lists every target address, the method card it belongs to and the planned send rate, so the white team can compare it with the signed ROE before anything leaves the laptop. When the ROE asks for proof that rates were respected, that printed list is filed with the other engagement evidence and kept for the same retention period.
22.4 Version with the engagement
Store the exact script version (commit hash or file hash) in the engagement record so a reviewer can regenerate the table later. Unversioned "final_final_v3.py" files are not evidence.
Priya records a SHA-256 of the builder beside each generated table, the same way she does in the worked example. Months later an auditor can rerun the hashed script on the archived JSON and check that the table in the report is identical. A file called final_v3.py with no hash cannot be tied to any table, so archive review rejects it however tidy the output looks.
22.5 What not to scrape
Automation that pulls production passwords, session cookies or personal data into a report builder is a data-handling incident waiting to happen. The builder in this chapter reads only the fields a human already filed as findings. If a field is missing, the script should fail loudly rather than invent a default severity.
The safe pattern is a builder that only accepts the fields of a filed finding: identifier, title, severity, status and owner. Continuous-integration tests feed it synthetic fixtures, including deliberately broken records with no severity, to prove that it stops with an error. A builder that reached into consoles for cookies or passwords would turn a reporting convenience into a data-handling incident under the agreement.
Worked example
Priya runs the report builder on four synthetic findings. It prints F-09 critical first, then the two highs, then the low, and summarises open=2 fixed=1 accepted=1. She pastes the table into the draft report and records the script's SHA-256 beside the attachment.
Synthetic case. The four findings and the printed table are invented.
Errors and limits
Automation that silently drops findings with unknown severity is a defect; fail loudly. Do not auto-close tickets from a scanner without human review.
Exercises
- EX064 — Table order. In the lab output, which finding appears first and why? Rubric: 3 = F-09; critical ranks above high/low; 2 = F-09 only; 1 = wrong order logic; 0 = none.
- EX065 — Human gate. Name two decisions that must not be automated in TRT's process. Rubric: 3 = two of authorize scope / severity dispute / go-no-go / white-team stop; 2 = one; 1 = automate everything; 0 = none.
- EX066 — Version evidence. How should Priya prove which script built the table? Rubric: 3 = store commit or SHA-256 of the script with the engagement; 2 = vague version note; 1 = remember it; 0 = none.
Synthesis
Automate tables and counts; keep authorization human; dry-run anything that touches systems; version the scripts.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →