Your SIEM does not ingest the identity provider's consent-grant audit log - do you still emulate that technique?

## Why this is a selection question at all The third filter in technique selection - after adversary relevance and estate applicability - is **observability**: is there any surface that could record this behaviour, and is that surface actually collected? Applying it at design time is what makes it a selection decision rather than a post-mortem. Applied afterwards, the same discovery arrives as an excuse. ## The four stages a detection outcome can fail at Any result of the form "nothing was detected" decomposes into four possible failures, and they have different owners and different fixes: 1. **The evidence was never collected.** The source does not exist, is not enabled, or is not ingested. 2. **The evidence was collected but no rule matched it.** 3. **A rule matched but nobody acted on the alert.** 4. **Somebody acted but the response did not land.** When you know in advance that stage one fails, the run cannot reach stages two through four. The experiment has no power to discriminate: you already know the answer, and the result you get back is the answer you already had. That is the core argument for descoping. ## What the default looks like in practice Drop or re-order the technique, and record the reason as a **design-time visibility finding** with an owner - typically whoever runs log onboarding, not whoever writes rules. It belongs in the report even though nothing executed, and it is often the single most valuable line in the exercise, because a missing source is cheaper to fix and blocks more future work than any individual rule. Recording it correctly matters as much as finding it. "Selected, not executed: no observation surface collected" is a different row from "executed, not detected", and a coverage artefact that merges them will later be read as though the behaviour was tested. Keep the technique in the plan's considered list with a re-test scheduled for the cycle after the source is onboarded, so the fix has a verification attached to it rather than a promise. ## The two overrides **A plausible compensating surface.** The primary surface is not always the only one. If the behaviour is a consent grant to an application followed by collection through the vendor's API, the identity provider's grant records are the natural place to see it - but the SaaS tenant keeps its own audit trail of the reads, a forward proxy may record the API destinations, and a volume signal on mailbox access may exist independently. If you genuinely do not know whether any of those would produce something, executing the technique converts a guess into a fact and tells you whether the blindness is total or partial. That is a real experiment, and it justifies the slot. **Funding the fix.** Organisations respond differently to "we should collect this log" and "on this date we performed this action in production, and no record of it exists anywhere we look." When the exercise's purpose includes making the case for onboarding a source, an executed and undetected test case is the artefact that makes it. This is a deliberate, declared reason - not a rationalisation invented after running the technique anyway. ## What you must not do Do not execute it, get the predicted miss, and report it as a **detection gap**. That misattributes the failure to the rule authors, who cannot write a rule against data that is not collected, and it inflates the apparent detection-engineering backlog with work that is blocked. Do not mark the technique as covered because it was on the plan. And do not quietly drop it without a written reason - a technique that disappears between the plan and the report is the pattern that makes emulation results untrustworthy. ## Re-ordering rather than dropping Descoping is not always all-or-nothing. If onboarding the source is a week away, the better move is to re-order: run the rest of the plan now, onboard, then execute this technique last in the same cycle. You get the evidence and the fix in one engagement, and the report tells a stronger story - gap identified at design time, closed, then verified by execution - than either half alone. ## The uncomfortable version of this question Sometimes the missing source is missing for a reason: cost, licensing, a data-protection objection to collecting a particular audit stream, or a platform that simply does not emit it. Then the finding is not "onboard this log" but "this behaviour is structurally unobservable for us", and the response moves to prevention rather than detection - restricting who may grant consent to applications at all, for example. Saying that plainly in the report is more useful than an execution result, and it is the kind of conclusion selection is supposed to surface before the exercise consumes its budget.