Chapter 23 — Authorized offensive security and red team: threat and failure analysis | Engineering Authorized offensive security and red team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 23 — Authorized offensive security and red team: threat and failure analysis

Lesson map

Lesson 23 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes"]
  N1["23.1 The tool can fail dangerously"]
  N2["23.2 STRIDE on the platform"]
  N3["23.3 Engagement threats stay in scope docs"]
  N4["23.2b Abuse cases vs misuse cases"]
  N5["23.3b Feeding backlog"]
  N6["23.1b Assuming breach of the jumphost"]
  N7["23.4b Ranking platform threats"]
  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 The tool can fail dangerously"]
  N2["23.2 STRIDE on the platform"]
  N3["23.3 Engagement threats stay in scope docs"]
  N4["23.2b Abuse cases vs misuse cases"]
  N5["23.3b Feeding backlog"]
  N6["23.1b Assuming breach of the jumphost"]
  N7["23.4b Ranking platform threats"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]

[Learning outcomes]
    |
    v
[23.1 The tool can fail dangerously]
    |
    v
[23.2 STRIDE on the platform]
    |
    v
[23.3 Engagement threats stay in scope docs]
    |
    v
[23.2b Abuse cases vs misuse cases]
    |
    v
[23.3b Feeding backlog]
    |
    v
[23.1b Assuming breach of the jumphost]
    |
    v
[23.4b Ranking platform threats]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes

You will (1) enumerate failures of the assessment platform itself; (2) use a lightweight STRIDE-on-tools pass; (3) feed results into requirements.

23.1 The tool can fail dangerously

TrackScope failing open, FindingsDesk losing deny events, PulseMap counting coverage without a denominator — these are threats to safety and honesty, not only to confidentiality of the tool.

A fail-open scope check hurts the client more than a slow UI. Lost deny events hide ROE breaches until the report. Coverage without a denominator is a marketing chart. Sam ranks these failures beside confidentiality threats in every design review, with a separate owner for honesty failures and for data-leak failures. A fail-open scope bug is treated as P1 even when no data left the estate, because the next probe could have been the excluded signalling host from the ranking example.

23.2 STRIDE on the platform

Spoofing: fake assessment account. Tampering: edit finding severity after seal. Repudiation: no actor on deny events. Information disclosure: evidence bucket world-readable. Denial of service: scanner floods client. Elevation: operator role can widen scope alone. Each row gets a mitigation requirement.

Each row becomes a mitigation with an owner, not a slide. Spoofed accounts need strong IdP binding; severity edits after seal need immutability or dual control; missing actors need mandatory fields. Scanner floods are ROE and rate-limit problems as much as availability ones. Sam tracks the six rows in the backlog until each has a test.

23.3 Engagement threats stay in scope docs

Threats to the client belong in the engagement's threat-led scenario (if any), not as features of TrackScope. Do not build "automated exploitation" to satisfy a STRIDE row.

Synthetic case — Riverstone Transit. STRIDE row "fail open" became safety requirement S-3 (Chapter 21). Row "solo scope widen" became the dual-approval gate (Chapter 14).

Keeping client-scenario threats out of the product backlog stops TrackScope from growing an exploit engine. Threat-led exercises belong in the engagement pack with their own authorization. Sam closes feature requests that smuggle engagement tactics into platform epics.

23.4 Errors and limits

STRIDE is a prompt, not a proof. Revisit after architecture changes.

A STRIDE pass from last year misses a new SaaS adapter's trust boundary. Revisit is triggered by architecture change, not by calendar alone. Sam books a threat pass when any new egress or identity provider is added, and the threat list's change log cites the pull request that added each adapter so stale rows stay obvious. The SaaS log-adapter row was added the same week as its pull request; without that cite, the next term's review would have assumed the old jumphost-only model still held.

23.2b Abuse cases vs misuse cases

Abuse cases are intentional adversary actions against the platform (forge a policy signature). Misuse cases are honest operators making dangerous mistakes (paste a CIDR that includes a partner). Design controls for both; training alone does not stop misuse when the UI makes widen-scope a single click.

A single-click widen-scope button is a misuse magnet even among honest staff. Forging a policy signature is abuse and needs cryptographic checks. Training without UI friction fails the first busy Friday. Sam requires a second person or a delay on every widen action.

23.3b Feeding backlog

STRIDE rows become issues with links to requirements. Unowned rows are theatre. Review the threat list when adding a new trust boundary (for example, a new SaaS adapter) — not only at programme start.

Unowned STRIDE rows are decoration. Links to requirement ids make mitigations shipable. New trust boundaries reopen the list even mid-programme. Sam's definition of done for a threat row includes a merged test or an accepted risk with an executive name, and the sprint board shows those rows beside features so safety work cannot hide in a side spreadsheet.

23.1b Assuming breach of the jumphost

Include "jumphost compromised" in the platform threat model: short-lived credentials, egress allow-lists, and rapid revocation. If your response is only "trust the jumphost", the analysis is incomplete.

Short-lived credentials and egress allow-lists assume the host will be stolen someday. Rapid revocation is practised, not hoped for. Trust without those controls is hope. Sam's tabletop always includes a stolen jumphost hour. Revocation drills use a spare jumphost image rebuilt from the golden branch afterward, so production engagements are not interrupted and leftovers cannot accumulate.

23.4b Ranking platform threats

Sam ranks the STRIDE findings by consequence to the client: a tampered scope file that lets testing reach an excluded rail signalling host is first; a spoofed dashboard login that leaks coverage charts is lower. The ranking decides which mitigations land before the next engagement.

Consequence to the client beats cleverness of the attack. Signalling hosts outrank dashboard vanity metrics. Ranking drives the order of mitigations before the next window. Sam publishes the top five on the team board during planning.

Exercises

EX067 — Fail open. Describe one test that proves fail-closed. Rubric: 3 = remove policy, expect deny+alert; 2 = idea; 1 = vague; 0 = none.
EX068 — STRIDE row. Write mitigation for repudiation on deny events. Rubric: 3 = authenticated actor + immutable log; 2 = logging only; 1 = vague; 0 = none.
EX069 — Boundary. Why doesn't platform STRIDE justify an exploit module? Rubric: 3 = different goal/safety boundary; 2 = partial; 1 = justifies it; 0 = none.

Synthesis

Analyse how your platform can hurt the client or lie; mitigate those first.

Continue studying — chapter 23 of 50

← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →