Tune and Retest Loop

## The loop A purple-team session runs a short cycle with both teams in the room: the operator **executes** one technique against a real estate, the detection engineer **observes** what the telemetry actually recorded, the engineer **tunes** the query or rule, and the operator **re-executes** the same technique so the edited logic meets live behaviour. The cycle repeats until the rule fires on a fresh execution, or until the team concludes the behaviour is not detectable with the telemetry present, which is itself a legitimate result. ## What each pass answers The first execution answers a question that is not about detection at all: *is the behaviour recorded?* If the operator mints a second access key for an existing cloud identity and then attaches an inline policy to it (ATT&CK `T1098.001`, additional cloud credentials), the control plane either writes audit records naming the caller, the target identity and the API action, or it does not. If no record exists, no rule can be written, and what you have found is a **telemetry gap**, not a detection gap. Those route to different owners and different fixes. Every later pass answers a different question: *does the candidate logic match a real occurrence of the behaviour, delivered through the real pipeline, on the real schedule?* ## Why an edit is not evidence An edit changes matching, not history. Two things follow. First, the records from the previous execution are already written; re-running a saved search over them tells you the query would have selected those rows. That is worth doing - it is the fast inner check - but it validates a query, not a detection. A detection is a rule plus a schedule plus a suppression policy plus a destination. Second, the failure modes that bite in production live outside the query. A rule can be perfectly correct as a search and still never alert because a field it names is populated on only some events, because its scheduled lookback is shorter than delivery lag so late-arriving records fall outside every run, because a broad suppression swallows it, or because it routes to a queue nobody works. Only a live re-execution walks that whole path end to end. ## What the first green does and does not prove A green retest proves one thing precisely: *this behaviour, performed this way, by this person, with this tooling, produced an alert.* That is a real result and it is not nothing. It is also not coverage. The same technique performed from a console rather than a command-line client, with the two API calls in the opposite order, or with a delay between them, is a different execution and an untested one. The exit criterion for the loop is not the first green; it is a green on a variant the engineer did not watch being built. ## What to record when it goes green Keep a session log that lets someone else reconstruct the claim months later: the exact execution time, the identity and account used, the technique and variant, the rule version that fired, the observed alert time, and the delta between them. Note explicitly that it is one variant by one operator. That single sentence is what stops a session result being read as a coverage claim. ## Why this is asked in interviews Candidates who have only read about purple teaming describe it as a report exchange: red hands over findings, blue writes rules later. The whole value of running it in one sitting is the tightness of the feedback - the operator is still there, the estate is still in the state that produced the record, and a broken assumption is discovered in minutes rather than in the next quarter's exercise. Someone who cannot say why the re-execution matters has not sat in one.