Choosing What to Emulate

## What the selection step is Before an emulation exercise runs, somebody decides **which adversary behaviours will be executed**. That decision fixes the ceiling on what the exercise can prove: a behaviour that is never executed produces no evidence at all, whichever way it would have gone. Selection is therefore the highest-leverage part of the design, and it is the part interviewers probe first. ## Two ways the list gets built **From a popularity list.** Public rankings of "most observed techniques" are compiled from other organisations' incident and telemetry data. That data is real, but its shape is not neutral: it over-represents whoever reports, whatever the reporting vendor has sensors for, and commodity activity that hits many victims at once. Endpoint execution and scripting techniques dominate because endpoint agents are where the reporting comes from, not because they are where your particular adversary spends their effort. **From a threat profile.** A profile answers who would want something you hold, what they are after, and what tradecraft they have been reported using. The selection job is to turn that prose into an executable set: read the profile, extract the behaviours, express each as a technique identifier so the plan has stable labels, and carry a citation from every entry back to the line of the profile that justified it. That citation is what makes the plan defensible later. ## The three filters 1. **Adversary relevance** - does the profile actually attribute this behaviour to a crew with a reason to be interested in you? A technique nobody relevant uses buys realism you do not need. 2. **Estate applicability** - do you run the platform the technique targets? A technique against a service you do not operate is unexecutable, and running a lookalike proves nothing about your estate. Drop it, and record why. 3. **Observability** - is there any surface that could see it? This filter is applied at design time on purpose, because the answer sometimes changes the plan before anything runs. ## A worked example Suppose the profile describes a crew that targets financial-services tenants and does not touch endpoints at all. Their route is consent phishing: the target is sent a link to an attacker-registered multi-tenant application requesting delegated mail-read scope; the user grants it; the crew then reads mail through the granted token over weeks. No credential is stolen, no binary lands on a laptop, and a password reset does not remove the grant, because a password is not what the grant depends on. The technique set that falls out is identity- and SaaS-shaped - phishing for the consent, theft or abuse of an application access token, use of a valid cloud account, remote collection from mailboxes - and the observation surfaces are the identity provider's consent and permission-grant audit trail and the SaaS tenant's own audit log. Almost none of that appears on a commodity popularity list, and an exercise built from that list would have exercised script execution on workstations while the actual path stayed untested. The report would read green. ## Defending an unpopular pick "Everyone tests the other one" is the objection you will get, and the answer is evidence rather than preference. Show the line of the profile that attributes the behaviour, show that the estate runs the platform, and show what claim each option buys: the popular technique may already have test evidence from a prior cycle, in which case re-running it buys a regression check, while the unpopular one buys the first evidence anybody has about the path most likely to be used against you. ## Where popularity lists are legitimately useful They are a reasonable **baseline hygiene** set and they make results comparable between organisations and across time. The honest way to use them is to label them as what they are: baseline coverage, distinct from adversary-relevant coverage, and reported separately so nobody reads one as the other. ## The limit of the claim Even a perfectly derived set supports only a narrow statement: these behaviours, implemented these ways, on these dates, produced this evidence. It says nothing about behaviours you did not execute, and a profile is an assessment that can be wrong or out of date. The selection artefact should say which behaviours were considered and dropped, and why, so the next cycle starts from the record rather than from scratch.