A Scenario refers to a sandboxed virtual environment, where a user is provided with a set of tasks to complete and/or provisioned with a set of resources, that accompany competency-driven technical/non-technical training. In simple words, a scenario is a lab environment in which, a user is taken through, or assessed, on a given domain/topic/skillset:
Before we take a quick look at the internal constitutions of a given scenario, take note of the following information before you start up or access a scenario:
Subscription status – you can only boot up scenarios you have access to, to check scenarios that are accessible to you, look for the subscribed badge underneath the scenario/playlist:
Scenario Page – once you identify a given scenario, on clicking the view more option to view details about the scenario, you will often be met with a page such as this:
On this page, take note of the following:
- Start options - the start button that is used to start up the scenario.
-
Scenario Parameters – a bar just underneath the start option that will list the following important details:
- Game Mode – as mentioned this is the classification of a given scenario.
- Game Type – as discussed, this is the classification of a given scenario.
- Difficulty – this is the set level of difficulty for the scenario.
- Duration – this is the timed duration you will have to access that instance of the scenario, once you boot it up.
- Scenario Story – just underneath the scenario parameters, is a brief description of what the scenario is about, the objectives, any prerequisite knowledge required/competence, recommended resources to consult for further information, and the scenario author(s).
Other useful info – next to the start button, you will note the following set of buttons:
These are (from left to right):
- Share – the share button if you wish to share the scenario
- Favourite – equivalent of the “like” button, this option adds the scenario to your favourite list.
- Playlists – this is a shortcut option to add that scenario to a playlist.
When you start up a scenario, you will often note the scenario will have a unique loading time:
The loading time is dependent on the following factors:
- Size of the virtual environment – a scenario with 1 virtual machine will load up quicker than a scenario with 10. This is because, each time you boot up a scenario, the range will need to create an instance that contains the resources provisioned in the virtual environment (virtual machines, network nodes, etc.). Thus, factors like the computing resources a node requires e.g., disk space, will impact how long the lab environment will take to spin up.
- Resources Running the Range – as you may be aware by now, our CYBER RANGE solution has various deployment options. Customers on our Range as a Service (SaaS) and hosted subscription model, will experience significantly better loading times than On-Prem deployments. Note that, on-prem deployments, resource computation is done on the customers' hardware, thus, the resource capability available for the hardware running the range will be a determining factor.
Typically, loading times, on average, are between 1 and 10 minutes, with smaller environments loading up faster and larger environments taking up longer. Other factors come into play such as, whether the scenario is prefetched or if the scenario is often played. If a scenario is often played, it may be placed in the range’s cache, thus it will load up faster. Details about prefetching will be discussed in the Admin User Guide.
Note: Should the scenario fail to load with any error message, please reach out to our support team for assistance.
Scenario layout
Once a scenario is fully loaded, take note of the following layout (all scenarios have this layout):
Tabs(1) – on the left, is a side menu that contains the following:
Overview
Questions (only visible if the scenario has an assessment (tasks))
Servers (only visible if the scenario has an accompanying virtual environment: virtual machines)
Score
Injection (only visible if the scenario has Injections enabled, and you have the Injections Composer role)
Help
Pages(2) – each of the tabs has a centralized menu of pages (sometimes singular) that will pop up, for example, the Overview tab, has three noteworthy pages with the last page often present during specific conditions:
Mission – this is the most important page in a scenario. This page contains critical information on the steps, actions, and detailed information the users are required to go thrown. This page can even include media sources such as visual-aided guides: screenshots, videos, etc., commands to run, network architectural diagrams, and various guided details/steps to follow.
Rules – this page contains a set of rules users should adhere to.
Assets – this is an optional page and will only be visible if the scenario has a set of accompanying documents meant to provide additional context on what the scenario is covering. Often these files are meant to support content provided in the Mission page.
Each of the remaining tabs contains only a centralized page related to the selected tab.
Instance Status(3) – on the top right is a useful bar that gives the user information such as:
Time left – the amount of time the user has left to complete that scenario. Open range scenarios will have timers that show the amount of time spent.
Scores – the scores the user has attained depending on the tasks (questions) they have completed.
VPN status – the current status of the VPN connection to the range. VPN setup is not often a requirement, the reason for this will be explored later in this chapter.
Cloud Stack status – cloud stack refers to the virtual environment, in this case, the state of the virtual machines (accessible in the servers tab). Green often means the environment is up and running.
Scenario resources
Scenario resources refer to the Servers tab. This is where virtual machines are made available to the user for their interaction:
Depending on the scenario itself, the number of resources provisioned will vary per scenario.
Accessing Virtual Machines
Access to virtual machines is achieved through a set of Services that are made available against a specific virtual machine. These services can be of the following types:
RDP – this is a remote desktop service, and as the name implies, will provide remote desktop services to the user, via the browser.
WEB – this is a web proxy service, and can be used to access running websites or tools with web UIs on the virtual machines. Access is provided via the browser. Sometimes, we use a web proxy to provide RDP access.
SSH – this is a web shell service and is used to expose access to SSH (Secure Shell) connections via the browser. Users get shell access to the virtual machine this service is provisioned on.
Web/Physical Console – this is console-level access that is provided to the user via the browser.
Refer to the table below for details on the service and icon match-up:
| Service | Icon |
| RDP | |
| WEB | |
| SSh | |
| Console |