Chapter 28 — Field simulation with authorized stakeholders

Chapter 28 — Field simulation with authorized stakeholders

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["28.1 Exercise types"]
  N2["28.2 Authorization and safety"]
  N3["28.3 Design"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["28.1 Exercise types"]
  N2["28.2 Authorization and safety"]
  N3["28.3 Design"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]

[Learning outcomes and connection]
    |
    v
[28.1 Exercise types]
    |
    v
[28.2 Authorization and safety]
    |
    v
[28.3 Design]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes and connection

You will be able to (1) plan a field simulation (functional exercise) with written authorization, safety controls and clear objectives; (2) run it with real stakeholders and real tools in a controlled way; and (3) evaluate performance against objectives and turn findings into owned improvements. Chapter 27 deployed the workflow; a simulation tests whether people, tools and processes work together under realistic pressure.

28.1 Exercise types

NIST SP 800-84 distinguishes tabletop exercises (discussion), functional exercises (performing tasks in a simulated operational environment) and full-scale exercises. A field simulation in this course is a functional exercise: staff use the real case tool, paging, evidence store and pre-built containment actions against test systems, while injects are delivered by an exercise control team. Fernmoor's Quiet Meter exercise was functional: the team used the real case tool and action cards against the billing test environment, with a scenario of a compromised supplier account.

28.2 Authorization and safety

Before anything runs: written authorization from the system owners and the director, stating scope (which systems, test accounts and hours), excluded systems, who may stop the exercise, and how real incidents are handled during it. Safety controls: every inject and message labelled "EXERCISE"; actions only against test systems or test accounts; a "real-world" code phrase that halts play; the service desk and on-call managers briefed; no surprise for residents. The Menlo Report's principles — respect for persons, beneficence, justice, respect for law and public interest — are a useful check that an exercise does not harm or deceive people.

28.3 Design

Objectives tied to capabilities (for example "page S1 on-call within 15 minutes"; "preserve identity evidence before containment"; "deliver an executive update within 60 minutes"); a scenario with a master scenario event list (injects with times, deliverer and expected actions); roles (players, controllers, evaluators, observers); evaluation guides per objective; and a hot wash immediately afterwards plus a written after-action report. Quiet Meter followed this design. Its objectives included paging the S2 on-call within 15 minutes and an executive update within 60, each with a measure. The after-action report then listed which objectives were missed, such as preserving identity evidence before containment, with owners and re-test dates.

28.4 Worked example (synthetic): "Quiet Meter"

Fictional. Scenario: a compromised supplier account accesses the water-billing test environment. Authorization signed by the billing system owner and director; scope: billing-test environment and five test accounts; 09:00–13:00 on a Tuesday.

Improvement plan: reorder the identity runbook with an enforced "export complete" checkbox (owner Response Desk, 2 weeks); add the update template to the case tool (ITSM owner, 1 month); load supplier contacts from contracts into the inventory (Procurement, 6 weeks); re-test objectives 2, 4 and 5 in the next quarter's exercise.

28.5 Common errors and limits

• Exercising without written authorization or a stop mechanism.
• Objectives that cannot be observed.
• Blaming individuals in the after-action report.
• Findings without owners and re-test dates.

Quiet Meter had a signed authorization from the billing system owner and the director, a time window and a named scope. Each objective could be observed from case timestamps, console logs or an evaluator check. The after-action report described causes such as an unclear runbook order on mobile rather than blaming the analyst, and each finding had an owner and a re-test in the next quarter's exercise. Exercise control could stop play at any time.

Exercises — chapter 28

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX082 — Authorization letter. Steps: draft the authorization for "Quiet Meter". Rubric: 3 = scope, exclusions, dates/times, test accounts, stop authority and code phrase, real-incident handling, signatories; 2 = missing stop; 1 = vague; 0 = none.

EX083 — Inject list. Steps: write five injects with time, deliverer, content and expected action. Rubric: 3 = five coherent injects testing the objectives; 2 = three; 1 = unrelated; 0 = none.

EX084 — Finding write-up. Steps: write the after-action entry for objective 2 without blaming individuals. Rubric: 3 = observation, impact, root cause in process/tool, recommendation, owner, re-test; 2 = missing re-test; 1 = blames; 0 = none.

Chapter synthesis

Exercise for real only with written authorization, labelled injects, a stop mechanism and limited scope; design observable objectives; evaluate without blame; and turn each finding into an owned change with a re-test date.

Continue studying — chapter 28 of 30

← Chapter 27 · Course chapter index · Chapter 29 →

Continue to the next authored lesson.