Key takeaways
- A threat profile built from real intelligence anchors every technique choice an adversary simulation makes.
- Flag criteria define what the simulated attacker is trying to reach; without them, the exercise has no measurable end.
- Rules of engagement, signed before the first day, determine what can be tested, who can authorise escalation, and how to stop the exercise safely.
- Deconfliction records the exercise so that a detected event does not trigger incident response against your own test team.
The threat profile drives every decision
An adversary simulation does not begin with a tool list or a scanning phase. It begins with a question: which adversary category would realistically target this organisation, with what motivation, and through what access methods? That answer is the threat profile, and every decision in the planning process follows from it.
Building a useful threat profile requires structured intelligence, not assumption. It draws on public reporting for the client's sector, known campaigns against organisations of comparable size and sector, and any prior targeting the client is aware of. The profile names the most plausible adversary category, describes their typical objectives, and maps their expected techniques to the MITRE ATT&CK framework. A simulation without a named adversary tests capability in the abstract, not resilience against a real threat.
The threat profile also constrains the simulation team. Techniques inconsistent with the profile are excluded, even if technically feasible. A financially motivated attacker does not typically exploit zero-day vulnerabilities, so a simulation representing that profile should not either. This is not a limitation. It is what makes the exercise results interpretable against a real risk question.
| Adversary category | Primary objective | Typical access pattern | ATT&CK focus |
|---|---|---|---|
| Financially motivated | Ransomware, data exfiltration for sale | Phishing, exposed services, supply chain | Initial access, credential access, exfiltration |
| State-sponsored | Long-term access, intelligence collection | Spear phishing, supply chain, credential theft | Persistence, defence evasion, collection |
| Insider threat | Data theft, sabotage | Legitimate access misused over time | Collection, exfiltration, impact |
| Hacktivist | Reputational damage, public data exposure | Web application exploitation, credential spray | Initial access, impact, discovery |
Crown jewels and flag criteria
Once the threat profile names the adversary, the next question is what that adversary would reach for. These are the crown jewels: the systems, data sets or capabilities whose compromise would represent a meaningful loss for the organisation. Identifying them requires a conversation with the client's security and business leadership. The assets that matter most are not always the most visible ones.
Crown jewels might be the production Active Directory, a specific data store holding customer financial records, the OT network boundary, or a code signing certificate. The list is not exhaustive. It is a prioritised set of five to ten assets the simulated adversary is plausibly motivated to reach. Prioritisation matters because flag criteria flow from it, and an engagement with fifteen flags has no clear measure of success.
Flag criteria translate crown jewels into measurable test outcomes. A flag is a specific, verifiable event: reading a named file in a defined location, authenticating to a production system with a credential stolen earlier in the chain, or reaching the network segment that hosts the OT boundary. Without flag criteria there is no way to determine whether the simulation reached its goal, and the report cannot tell the client what a real adversary would have achieved. A red team engagement applies the same principle when the objective is the full attack lifecycle rather than a narrower scenario.
Strategic objective
What a real adversary in this category ultimately wants
Interim flags
Specific access milestones on the path to the objective
Access milestones
Initial foothold, privilege escalation, lateral movement
Scope boundary
The agreed perimeter the simulation must not cross
Scope, exclusions and rules of engagement
The scope document defines the attack surface the simulation is authorised to use. It names the IP ranges, domains, cloud tenants, and physical locations in scope. It also names what is excluded: production systems where downtime would be unacceptable, third-party systems whose owners have not consented, and personnel categories that should not be targeted. Unlike an assumed-breach engagement, which starts with a foothold already placed and skips initial access entirely, an adversary simulation covers the full chain from external reconnaissance to the objective. The scope must address every phase of that chain.
Exclusions are not concessions. A real adversary attacking a financial services firm would not deliberately crash production systems, because the noise would end the engagement before the objective is reached. A simulation that can destroy what it touches tests nothing useful and risks the client's operations. The exclusions list reflects realistic adversary behaviour. A scope document without a considered exclusions list is probably modelling the wrong threat.
Timing is part of scope. The planning document sets the active simulation window: start date, end date, and any blackout periods where the simulation must pause. Some engagements run without the SOC's knowledge. Others notify a small deconfliction cell so that a detected event does not trigger a full incident response against the test team. The article on detection coverage in an adversary simulation covers what the SOC should be measuring while the exercise runs, and how detection outcomes are recorded in the final report.
Mapping the threat profile to the kill chain
The planning step between the threat profile and active execution is technique selection. The simulation operator takes the profile and flag criteria and works out a plausible attack path from initial access to each flag through the Unified Kill Chain: the In, Through and Out stages that describe how an adversary moves from external reconnaissance to their objective.
Technique selection is constrained by the profile. Mapping to MITRE ATT&CK makes this explicit and gives the client a vocabulary to compare simulation coverage against their detection rules. A state-sponsored adversary invests in persistence and defence evasion, so those phases belong in the technique plan. A financially motivated actor moves quickly toward credential access and exfiltration, and the technique list reflects that. NIST SP 800-115 provides a framework for scoping and planning the active phases of technical security testing, and the planning document references the relevant ATT&CK technique identifiers so findings in the report map back to the profile's assumptions.
Earlier in this cluster, the article on software packing and OEP discovery covers one technique in the defence evasion phase of a realistic simulation: the kind a state-sponsored profile would include and a financially motivated one would not. That specificity is what the threat profile makes possible. The simulation team knows which techniques are in scope because the profile names who they are representing, and the final report can say whether the controls designed to stop that adversary category did so.
Preparation
Threat profile
Adversary category, objectives, MITRE mapping
Crown jewels
Prioritised list of five to ten target assets
Design
Flag criteria
Measurable, verifiable objectives for each crown jewel
Kill chain mapping
ATT&CK techniques constrained by the profile
Authorisation
Rules of engagement
Scope, exclusions, timing, escalation paths
Sign-off
Client executive, legal and compliance as required
The planning document and sign-off
The planning document is the contract between the test team and the client. It records the threat profile, crown jewels, flag criteria, scope, exclusions, timeline, and deconfliction arrangement. It is signed by the client representative with authority to authorise the exercise: someone who can speak to the organisation's security posture and accept the legal and operational risk of the test.
A vague planning document creates two problems. First, it leaves the test team with no clear definition of success, so the engagement runs until time runs out rather than until a meaningful objective is reached or definitively failed. Second, it gives the client no basis for evaluating the report. Without a stated profile and stated flags, the findings lack context and the client cannot determine what a real adversary using the same techniques would have achieved. NIST SP 800-115 recommends documenting the legal authority for the test before any active work begins. This document is where that authority sits.
Sign-off is the moment to confirm that the exercise scope does not extend beyond what the organisation has authority to authorise. An adversary simulation that crosses a network boundary into a third-party system, or that targets someone whose employer has not consented, creates legal exposure the planning document should have prevented. A purple team session runs through the same planning steps but with the SOC visible throughout, treating defenders as participants rather than a control to measure. That changes what the planning document needs to say.
Adversary simulation planning in the UAE market
Planning an adversary simulation for a UAE organisation means building the threat profile against the adversary landscape that is relevant here. Financial services firms regulated by the Central Bank of the UAE face a different threat profile than government entities bound by DESC in Dubai or healthcare organisations under ADHICS in Abu Dhabi. Each has a distinct set of assets worth protecting and a different set of adversaries plausibly motivated to reach them.
NESA and the UAE Information Assurance Regulation set the federal baseline for critical information infrastructure. An adversary simulation scoped against that framework treats the crown jewels as the systems and data whose compromise would affect national security, public utilities or economic stability. The planning document must reflect that scope explicitly, and the threat profile must represent the adversary categories realistic for critical infrastructure rather than commercial targets.
Dubai and Abu Dhabi have both seen growth in regulated requirements for threat-led security testing, alongside financial services and government digital transformation programmes. A threat profile built for a Dubai financial services firm will weight financially motivated adversaries and supply chain access paths. A profile built for an Abu Dhabi government entity will weight state-sponsored actors and long-term persistence. Neither can be read off a template. Both require sector intelligence and a direct conversation with the client about who has targeted them and who realistically would.
Frequently asked questions
What is a threat profile in an adversary simulation?
A threat profile is a structured description of the most plausible adversary for a given organisation: their category, typical objectives, access patterns, and known techniques. It is built from public threat intelligence and client-specific context before the exercise begins, and it constrains every technique the simulation team selects. A simulation run without a profile tests capability, not resilience against a real threat.
How does an adversary simulation differ from a penetration test?
A penetration test enumerates vulnerabilities across a defined scope and rates their severity. An adversary simulation follows a realistic attack chain from initial access to a specific objective, representing a named category of adversary. The goal is not a list of weaknesses but a measured outcome: did the simulated attacker reach their flag, and did the organisation's controls detect or stop them?
What are flag criteria in an adversary simulation?
Flag criteria are specific, verifiable events that represent a meaningful attacker objective: reading a named file, authenticating with a stolen credential to a production system, or reaching a defined network segment. They translate abstract crown jewels into measurable test outcomes so both sides can determine when the simulation has succeeded or conclusively failed within the agreed scope.
What must a rules of engagement document contain?
A rules of engagement document records the scope, exclusions, timing, authorised techniques, escalation contacts, and deconfliction arrangement for the exercise. It is signed by the client representative with authority to authorise the test. Without it, there is no agreed framework for deciding what was in scope, or what the client and test team are each responsible for if something unexpected occurs.
What is deconfliction in an adversary simulation?
Deconfliction is the arrangement that prevents the security operations centre from treating a test event as a real incident. A small deconfliction cell, typically the CISO and one or two others, knows the exercise is running and holds a contact number to verify that a detected intrusion is the test team rather than a real attacker. The broader SOC is not informed, so the test measures real detection capability rather than a prepared response.
How does the threat profile map to MITRE ATT&CK techniques?
The threat profile names the adversary category and their likely objectives. MITRE ATT&CK provides the technique identifiers that represent each step: specific initial access methods, privilege escalation paths, and lateral movement patterns the profile implies. The simulation team selects from those techniques, and the final report maps findings back to them so the client can compare coverage against their detection rules.
Who has authority to sign off on an adversary simulation?
Sign-off requires someone who can speak to the organisation's overall security posture and accept the legal and operational risk of the exercise. In practice this is the CISO or an equivalent executive, not the security team alone. For a UAE regulated entity, sign-off from a compliance or legal function may also be needed depending on which frameworks bind the organisation.
What happens if the simulation team detects a real intrusion during the exercise?
The engagement stops. The rules of engagement include a procedure for this scenario: the team reports the finding to the deconfliction cell, suspends active work, and the client decides whether to trigger incident response. A simulation running alongside an actual compromise produces unreliable results and could interfere with the real investigation, so stopping is the only safe option.
How does an adversary simulation differ from a purple team session?
An adversary simulation runs without the defenders' knowledge, testing whether real controls detect a realistic attack chain. A purple team session runs collaboratively, with the test team and SOC working through techniques together and tuning detection rules in real time. A simulation measures current resilience; a purple team session builds detection capability. Many organisations run purple teaming first to establish a baseline, then commission an adversary simulation to test it.
