Authorisation is the first element of the lab
Every exercise should specify which systems, accounts and actions are permitted. Participants must know whether the scenario covers scanning, exploiting vulnerabilities, log analysis, configuration changes or incident response. The absence of a prohibition does not mean consent to test other addresses or services.
The scope is best described in short rules: permitted targets, time window, methods, prohibited actions and how to report an unexpected situation. In red team or penetration testing exercises, the legal basis and the person who approves the work also matter. A training lab must never become a pretext for probing infrastructure outside the scenario.
The topology should have a clear network boundary
A typical scenario includes the participant's workstation, the target system and supporting components such as a log server, a domain controller or a demo application. All resources should sit on a network separated from production. Firewall rules restrict communication to the directions the exercise needs.
Outbound traffic to the internet also requires a decision. Blocking it completely is safe, but it may prevent package updates or access to documentation. Another option is an allowlist of repositories and services. Participants should not be able to direct scans or test traffic at arbitrary public addresses.
Realism comes from dependencies and traces, not production data
A good vulnerable application has a coherent business context, accounts with different roles and logs that let you link an action to its effect. It does not need real customer names, addresses or documents. Synthetic data can be designed to support the scenario without creating a privacy risk.
In a defensive exercise, credible events matter: a sign-in, an authorisation failure, an unusual request, a file change and a network connection. Timestamps on the machines must be synchronised, otherwise participants will not be able to build an accurate incident timeline. Malware analysis needs additional restrictions, including blocking uncontrolled traffic and a safe way of handing over samples.
The scope of permissions depends on the role in the scenario
A person analysing logs does not need root access to every system. A participant carrying out hardening, on the other hand, may need sudo on their own machine. Accounts should match roles, and credentials should work only within the lab and for a fixed period.
Separate VMs protect workstations from affecting one another, but on their own they do not guarantee isolation of the whole topology. You need to check routes, firewall rules, shared storage and access to the management panel. Participants should not be able to modify the base image or other groups' resources.
The instructor needs a procedure for stopping the exercise
Before the start, agree who can pause the scenario and how traffic is cut off, an account disabled or a whole group of machines stopped. The procedure should work regardless of the state of the system under exercise. If stopping requires signing in to a compromised application, it is not reliable enough.
Reasons for stopping may include traffic leaving the agreed scope, unintended disclosure of data, failure of a shared component or a tool behaving differently than it did in testing. The instructor should contain the effects first and only then collect material for analysis.
Reset is part of the security scenario
An exercise can change accounts, firewall rules, system files and application data. Restoration must cover all of these layers. Snapshots make it easier to return to the baseline, but you need to check that they work with stateful services and with the order in which the machines start.
After a reset, an automatic check should confirm the availability of the targets, the state of the vulnerabilities, the accounts, the system time and the network rules. The fact that a VM has started does not mean the lab has returned to the right phase of the scenario.
The outcome of an exercise is a reasoned analysis
In offensive training, the result should include the attack path, evidence of impact and a recommendation for reducing the risk. In a defensive scenario, what counts is the timeline, the data sources, the hypotheses and the decisions taken during the response. A list of the tools used is not yet an analysis.
Once the exercise ends, temporary accounts and credentials are revoked, and samples and logs are retained according to a rule agreed in advance. Example environment topologies show how the technical scope changes with the topic. In a cybersecurity lab this relationship is especially important, because the boundaries of the environment are part of the exercise itself.