You are commissioning a cyber exercise. The proposed network looks convincing, the system names match your sector and the attack story sounds plausible. But one question remains unanswered: what will participants actually be able to investigate, change and verify?
That question should shape the environment before the build begins. A large collection of virtual machines can still leave defenders with little meaningful work. A smaller environment can support a useful exercise if its services, traffic, evidence and consequences fit the objectives.
The central insight from ObsidianCorps' expert interview is that credibility depends on how the parts work together. Story, architecture, networks, services, custom software, supporting tools, guidance and scoring are connected design decisions. This article proposes a way to turn that insight into a commissioning brief. The worksheets and examples below are recommendations, not records of a completed engagement.
Start with something participants must demonstrate
“Make the environment realistic” is difficult to price, build or accept. Replace it with an observable task. For example: participants should investigate suspicious access, choose a containment action and verify that an essential service remains available to an authorised user.
This is an illustrative objective, not a description of a previous ObsidianCorps exercise. It immediately suggests practical requirements. There must be access activity to investigate, enough evidence to distinguish competing explanations, an action participants can perform and a service whose behaviour can be checked afterwards.
It also exposes what the exercise cannot establish. If service availability is represented only by a facilitator's message, the exercise can explore the containment decision. It cannot demonstrate that the team's technical change preserved availability in an implemented system.
Write down that distinction before deciding which products or hosts to include. It protects both the commissioner and the delivery team from accepting a technically different exercise under the same description.
Follow one task through the whole environment
Use a dependency chain to check that the participant's task is possible:
Operational service → system dependencies → normal activity → attack evidence → defensive action → observable result.
Consider a hypothetical service used to submit and review operational requests. A participant investigating unusual access might need account history, application events and network information. The relevant activity must occur on systems that the story says exist. The team's containment change must affect the appropriate access path, and an independent service check must show what happened afterwards.
An inconsistency anywhere in this chain changes the exercise. If the application logs identify an account that does not exist, the team may spend its time investigating a construction error. If the attack is described in a message but leaves no evidence in the range, a technical investigation may be impossible. If a score rewards blocking all access, it may encourage a response that contradicts the operational objective.
This is why architecture and story development need to be reviewed together. The Foundation of Cyber Ranges report from CMU's Software Engineering Institute is a primary reference on range design considerations. The practical scoping method here develops the interview's emphasis on connected components; it does not claim to reproduce that report's methodology.
Decide what each layer must contribute
Architecture and networks
Ask which dependencies the participants need to discover and which they should receive in the briefing. Include the boundaries that matter to the task: for example, a separation between user access and service administration. Avoid adding segments merely because a large diagram looks more credible.
The design should explain which defensive changes are permitted and how their effects can be observed. A path drawn on a diagram is not enough if the implemented routing or access rules behave differently.
Services and custom software
For every service, describe the function that supports the exercise. Participants may need to authenticate, view a record, recognise a changed state or retrieve an event. They do not necessarily need every feature of the original application.
Where a selected function needs custom implementation, make that scope explicit. Custom software development can address a bounded exercise requirement, but the resulting software should not be described as production-equivalent without evidence. Our separate article on OT simulation fidelity examines this decision when original software licences are unavailable.
Traffic and evidence
Normal activity gives suspicious activity a context. The design question is what participants need to compare, not how much noise can be generated. Relevant background activity might help them distinguish expected access from an unusual action; unrelated noise may only consume time.
Check that names, addresses, accounts and event order agree across the evidence sources participants will use. If the scenario depends on a sequence, the available evidence must support reasoning about that sequence. Document intentionally missing information so a limitation is not later mistaken for a participant oversight.
Tools, guidance and scoring
Supporting tools should help people perform the intended task. Introduce unfamiliar exercise-specific interfaces during preparation unless learning those interfaces is itself an objective.
Guidance and scoring also influence behaviour. A prompt can reveal a clue that an evaluation later treats as an independent discovery. A scoring rule can reward the fastest action even when a more careful action better preserves the required service. Define these interactions as part of the environment brief.
Choose fidelity where it changes a decision
Fidelity is the degree to which selected behaviour corresponds to the environment being represented. It is not one percentage that describes everything in the range.
For each requirement, choose one of three treatments: implement the behaviour, simplify it while preserving the task, or represent it through exercise material. These are proposed design categories, not product features.
| Requirement |
Possible treatment |
What the evaluator must know |
| A defender changes an access rule |
Implement a working control and an observable effect |
Whether the effect was checked independently |
| A participant asks an external organisation for information |
A facilitator represents the external role |
The quality of the request can be assessed; external response performance cannot |
| A business impact is too costly to simulate technically |
Describe the impact through agreed exercise material |
The described consequence is an exercise assumption |
Choose the treatment based on the objective, participant maturity and constraints. A simplification is useful when it preserves the reasoning or action being evaluated. It becomes a problem when it removes the very capability the exercise is supposed to test.
Put the acceptance criteria in the commissioning brief
A useful brief makes the expected participant experience reviewable. The following worksheet is a recommendation for owners commissioning a range and providers dividing work between specialists.
| Field |
Question to answer before building |
| Objective |
What should participants demonstrate? |
| Participant task |
What must they be able to inspect, decide or change? |
| Required behaviour |
Which service or dependency makes that task possible? |
| Evidence |
Which observations support a fair assessment? |
| Simplification |
What is omitted or represented through a facilitator? |
| Acceptance check |
How will the exercise team show the task works? |
| Responsibility |
Who owns the component and its dependencies? |
Keep unresolved assumptions visible. If an application is unavailable, record the decision needed and the effect on the scenario. If the client cannot supply operational context, identify which design choices remain provisional. This gives a specialist a concrete problem to resolve rather than an open-ended promise of realism.
Rehearse the experience, including the aftermath
A recommended acceptance rehearsal follows the task from the initial information to the final observation. Test the environment in the state participants will encounter, including their permissions and available tools.
Check what happens after a defensive change. Can the team verify the intended effect? Does the service continue to perform its agreed function? Do subsequent story events still make sense? Then check that the environment can be returned to a known state for the exercise.
Record construction faults separately from performance observations. An unavailable log, misleading briefing or broken dependency can prevent a participant from demonstrating a capability they possess. An evaluator needs that context to interpret the result fairly.
The founder's reported experience spans CybExer, CDEX, Range42 and custom ranges. That is personal platform experience, not a statement of official partnership or certification. The relevant commissioning question remains the same across platforms: can the chosen environment support the required tasks coherently?
If you need help turning operational objectives into architecture, services or supporting tools, explore our cyber range consultancy and exercise design. Tell us which task your exercise needs to reproduce and where the environment is still uncertain. Contact us.
