SDL Reference Guide
Stories
The story represents the fictive conditions and events of the scenario, that will take place during the exercise. A story can be divided into various scripts that include a series of events, that constitute a narrative. A script tells a part of the story through a timeline, taking the perspective of one (or more) entity, i.e., it represents the story from the entity’s perspective. Story has an internal speed
, which is used to control the overall speed at which the exercise is taking place. An optional description
can be added.
stories:
story-1:
speed: 1
scripts:
- script-1
- script-2
description: "story description"
Variable | Mandatory | Type | Rules |
---|---|---|---|
speed | yes | float | Speed value must be at least 1.0 |
scripts | yes | array of Scripts | Story must have at least one Script Script must be defined under Scripts |
description | no | string |
Scripts
Scripts are the main elements of a story, think of them as movie scripts. Scripts define their start-time
and end-time
which parsed from string into u64 seconds and accept a mix of types specified below (or a 0 value for start-time
). The speed
field specifies how fast the script runs. They also contain the events
map, that are happening in the scope of that script with the event start time specified as the value of the event in accepted format. So for the example below event-1
starts right when the deployment starts, event-2
starts 5 minutes after the start etc. An optional description
can be added.
scripts:
script-1:
start-time: 0
end-time: 3 hour 30 min
speed: 1
events:
event-1: 0
event-2: 5 min
event-3: 15 min
description: "script description"
Variable | Mandatory | Type | Rules |
---|---|---|---|
start-time | yes | time | |
end-time | yes | time | End-time must be greater than start-time |
speed | yes | float | Speed must have a positive value |
events | yes | hashmap of Event :time | Script must have at least one Event Event must be defined under Events |
description | no | string |
Accepted formats for time specification
Unit | Description | Unit list option(one of) | Example |
---|---|---|---|
y | Year | ["y" , "year" , "Y" , "YEAR" , "Year"] | 1y |
mon | Month | ["mon" , "MON" , "Month" , "month" , "MONTH"] | 1mon |
w | Week | ["w" , "W" , "Week" ,"WEEK" , "week"] | 1w |
d | Day | ["d" , "D" , "Day" , "DAY" , "day"] | 1d |
h | Hour | ["h" , "H" , "Hour" , "HOUR" , "hour"] | 1h |
m | Minute | ["m" , "M" , "Minute" , "MINUTE" , "minute" , "min" , "MIN"] | 1m |
s | Second | ["s" , "S" , "Second" , "SECOND" , "second" , "sec" , "SEC"] | 1s |
Millisecond (ms
), microsecond (µs
) and nanosecond (ns
) are also accepted as a valid input, but the values are rounded up to the nearest second.
Events
Events are rules, that are used to trigger injects
and show additional information to the participant. Events can either be triggered by condition or time. If an event contains a condition and that condition becomes true, the event will be triggered during the event time window. The time when the event can be triggered is specified in scripts. Also if event contains multiple conditions, all those conditions have to be true for the event to trigger. If the event does not contain conditions, it will be triggered when the event window opens.
Source
specifies the package of an Event markdown file in Deputy, which will then be converted into HTML and shown to the participant once the event has been triggered. For a longer explanation, please see Source under Node. An optional description
can be added.
events:
event-1:
source: "event-package"
conditions:
- condition-1
- condition-2
- condition-3
injects:
- inject-1
- inject-2
description: "event description"
Variable | Mandatory | Type | Rules |
---|---|---|---|
source | no | string or object with fields: name , version | Time must have a float value between 0 and 1 |
conditions | no | array of Conditions | Condition must be defined under Conditions |
injects | no | array of Injects | Event must have at least one Inject Inject must be defined under Injects |
description | no | string |
Injects
Injects describe the events that happen within the scripts of the exercise scenario. They can be technical or non-technical injects, such as, launching an attack from a particular entity to another entity or delivering a news report to an entity. Source
specifies the location of the executable command. Injects also have TLOs
attached to them. An optional description
can be added. Environment
field is a list of environment variables, which support executable Deputy packages. From-entity
and to-entities
fields don't currently carry functionality in the SDL parser but can be used for example in tabletop exercises.
injects:
inject-1:
source: executable/inject-1/path.sh
from-entity: entity-1
to-entities:
- entity-2
- entity-3
tlos:
- tlo-1
- tlo-2
description: "inject description"
environment:
- ENV_VAR_1=ENV_VALUE_1
- ENV_VAR_2=ENV_VALUE_2
inject-2:
source: executable/inject-1/path.sh
Variable | Mandatory | Type | Rules |
---|---|---|---|
source | no | string or object with fields: name , version | |
from-entity | no | Entity | Inject must have from-entity declared if to-entities is declared |
to-entities | no | array of Entities | Inject must have to-entities declared if from-entity is declared |
tlos | no | array of TLOs | TLO must be defined under TLOs |
description | no | string | |
environment | no | array of hashmaps of string :string |
Conditions
Conditions is a list of commands or libraries that are tied to Virtual Machines and periodically check the state of something. They are always installed after all Features have been installed. They return a value between 0..1
to the Ranger and are used for both scoring purposes in Metrics or as triggers for Events.
Each condition in the list must have a unique alphanumeric name.
There must be either a command and interval, or a source. If all fields under the condition are filled, then the source is overwritten and only command and interval are used.
Environment
field lists environment variables, which support executable Deputy packages and an optional description
can be added.
Command condition
The command
shows the path to the executable file and it returns a float value between 0 and 1.
Interval
indicates the interval between command executions in seconds.
condition-1:
command: executable/path.sh
interval: 30
Source condition
The source field defines the name
and version
of the image file or package in the Digital Library. In this example, the source
image only has a name:
condition-2:
source: digital-library-package
For a longer explanation, please see Source under Node.
Example conditions list
A fully defined Conditions list could look something like this:
conditions:
condition-1:
command: executable/path.sh
interval: 30
condition-2:
source: digital-library-package
description: "New condition"
condition-3:
command: executable/path.sh
interval: 30
environment:
- ENV_VAR_1=ENV_VALUE_1
- ENV_VAR_2=ENV_VALUE_2
Variable | Mandatory | Type | Rules |
---|---|---|---|
command | no | string | Must be defined if interval is used |
interval | no | integer | Must be defined if command is used |
source | no | string or object with fields: name , version | Condition must have command and interval or source defined, not both |
description | no | string | |
environment | no | array of hashmaps of string :string |
Features
Feature may be a service, a configuration, a vulnerability, an artifact, or any other modification applied after the base OS and base configuration and policy application.
Features can be of 3 types
: service, configuration, artifact.
Source
is either a string containing the Deputy package name or an object with package name
and package version
fields.
Features can be dependent on other features, which is specified with optional dependencies
field, where feature names are listed.
Features can be vulnerable and reference a vulnerability, which is specified with optional vulnerabilities
field, where vulnerability names are listed.
Destination
field doesn't currently carry functionality in the parser.
Environment
field is a list of environment variables, which support executable Deputy packages.
Optional description
field can be specified.
features:
nginx:
type: service
source: dl_library
destination: "destination"
environment:
- ENV_VAR_1=ENV_VALUE_1
- ENV_VAR_2=ENV_VALUE_2
description: "description"
web_cfg:
type: configuration
source: my-cool-nginx-conf
dependencies:
- nginx
vulnerabilities:
- vulnerability-1
web_pictures:
type: artifact
source: dl_library
dependencies:
- web_cfg
Variable | Mandatory | Type | Rules |
---|---|---|---|
type | yes | enum with options service , configuration , artifact | |
source | no | string or object with fields: name , version | |
destination | no | string | |
environment | no | array of hashmaps of string :string | |
dependencies | no | array of Features | Feature must be defined under Features |
vulnerabilities | no | array of Vulnerabilities | Vulnerability must be defined under Vulnerabilities |
description | no | string |
Vulnerabilities
Different nodes and entities can be vulnerable and reference technical or non-technical vulnerabilities.
Vulnerabilities contain informational name
and description
fields.
Technical
field sets whether the vulnerability is a technical or non-technical vulnerability.
The class
field represents the CWE-based class of the vulnerability.
vulnerabilities:
vulnerability-1:
name: "Vulnerability"
description: "My vulnerability"
technical: true/false
class: "CWE-1189"
vulnerability-2:
name: "Vulnerability"
description: "My vulnerability"
technical: true/false
class: "CWE-1343"
Variable | Mandatory | Type | Rules |
---|---|---|---|
name | yes | string | |
description | yes | string | |
technical | yes | boolean | |
class | yes | string | Vulnerability class must match CWE-based classes |
Nodes
Nodes is a list made of named Virtual Machines or Switches containing their type, resources and so on, each of them making up a Node
.
Switches
The switch is the simplest example of a node, it contains an alphanumeric name
and a type
:
my-cool-switch-1:
type: switch
Virtual Machines
A Virtual Machine is defined by its type
field with the value vm
. It also supports several optional fields for additional configuration.
Source
The source field defines the name
and version
of the image file or package in the Digital Library. In this example, we are explicitly defining the version
of the source
image:
my-cool-vm-1:
type: vm
source:
name: digital-library-package-name
version: 4.0.1
ℹ️ Note: The
version
field must follow the semantic versioning standard.
If the latest version of the source image is desired, the version
and the name
field can be omitted entirely:
my-cool-vm-1:
type: vm
source: digital-library-package-name
Resources
The Virtual Machine's parameters are defined in the resources
field, if omitted, the default values set by the hypervisor are applied. In this example, we are defining the ram
and cpu
parameters:
my-cool-vm-1:
type: vm
source: digital-library-package-name
resources:
ram: 2 GiB
cpu: 2
⚠️ Warning:
ram
is expressed in Mebibytes (MiB) or Gibibytes (GiB),cpu
is expressed in number of cores.
Additional configuration
VMs have additional configuration fields:
os
field specifies the operation system running on the virtual machine.
Features
and conditions
denote the optional modifications applied to the node. Vulnerabilities
doesn't have direct effect on the VM, but rather can be used to provide supplementary context. Roles
field specifies all the accounts under this node with optional entities field and features
and conditions
must have specified the account name, which will be executing these scripts. Nodes, that have conditions attached to them, must have a count of 1 (under Infrastructure
). Injects
field specifies the injects, that will be happening on the node.
Example Nodes list
nodes:
switch-1:
type: switch
description: "switch 1"
switch-2:
type: switch
ubuntu-10:
type: vm
source: digital-library-package-name
resources:
cpu: 2
ram: 2 GiB
roles:
admin: "username"
moderator:
username: "name"
entities:
- "blue-team.bob"
vulnerabilities:
- vulnerability-1
- vulnerability-2
features:
web_pictures: "admin"
nginx: "moderator"
conditions:
condition-3: "admin"
injects:
demo_inject: "admin"
windows-10-vuln-1:
type: vm
source: digital-library-package-name
resources:
cpu: 2
ram: 2 GiB
windows-10:
type: vm
source:
name: digital-library-package-name
version: 1.0.0
resources:
cpu: 2
ram: 2 GiB
Roles
can be written in either shorthand or longhand:
```yml
roles:
admin: "username"
user:
username: "user"
entities:
- blue-team.bob
Variable | Mandatory | Type | Rules |
---|---|---|---|
type | yes | enum with options VM or switch | |
source | yes for VMs, no for switches | string or object with fields: name , version | |
resources | yes for VMs, no for switches | object with fields: cpu (integer ), ram (integer ) | |
roles | no | hashmap of string :string or object with fields username and entities | |
vulnerabilities | no | array of Vulnerabilities | Vulnerability must be defined under Vulnerabilities |
features | no | hashmap of Feature :Role | Feature must be defined under Features |
conditions | no | hashmap of Condition :Role | Condition must be defined under Conditions |
description | no | string |
Infrastructure
Infrastructure represents the physical and virtual infrastructure associated with different entities and the vulnerabilities present in them.
Infrastructure can be defined either shorthand:
infrastructure:
switch-1: 1
windows-10: 3
or longway:
windows-10-vuln-1:
count: 1
switch-2:
count: 2
links:
- switch-1
ubuntu-10:
links:
- switch-1
dependencies:
- windows-10
- windows-10-vuln-1
Count
A count value shows how many virtual machines and switches you would like to use. For machines, that are running conditions, the count is limited to 1.
windows-10:
count: 3
Dependencies
Dependencies are a list of virtual machines which are dependent upon other nodes. A virtual machine may be connected to none, one or more nodes. In practice this controls which nodes are deployed first.
windows-10-vuln-1:
count: 1
ubuntu-10:
dependencies:
- windows-10-vuln-1
Links
Links are a list of switches which are dependent upon other nodes.
switch-1:
count: 1
ubuntu-10:
links:
- switch-1
Variable | Mandatory | Type | Rules |
---|---|---|---|
count | yes | integer | For machines, that are running conditions, the count is limited to 1. |
links | no | array of Nodes | Must be of type switch |
dependencies | no | array of Nodes | Must be of type VM |
description | no | string |
Metrics
Metrics are used to evaluate TLOs and conditions.
Type
specifies if the evaluation metric is manual or conditional. If it is manual, then artifact
field is also specified, which can be true or false and denotes whether an artifact exists.
Max-score
sets the metric's maximum value. Condition
field is used when the metric's type is conditional.
metrics:
metric-1:
name: "Metric-1"
type: manual/conditional
artifact: true/false
max-score: 50
condition: condition-2
description: "New metric"
Variable | Mandatory | Type | Rules |
---|---|---|---|
name | no | string | |
type | yes | enum with options manual or conditional | |
artifact | no | boolean | Conditional metric cannot have an artifact |
max-score | yes | integer | Metric max-score cannot be 0 |
condition | no | Condition | Manual metric cannot have a condition Conditional metric must have a condition The same condition cannot be used under multiple metrics |
description | no | string |
Training and Learning Objectives (TLOs)
Training and Learning Objectives (TLOs) represent a specific individual's training objectives (e.g. developed and exercised capabilities and skillsets) to be reached throughout the exercise.
TLOs specify their name
and textual description
.
Evaluation
field marks the evaluation value for the TLO.
tlos:
my-first-objective:
name: "Training/Learning objective name"
description: "some description"
evaluation: evaluation-1
Variable | Mandatory | Type | Rules |
---|---|---|---|
name | no | string | |
description | no | string | |
evaluation | yes | Evaluation | Evaluation must be defined under Evaluations |
Goals
Goals block describes the goals with TLOs.
It defines optional name
and description
fields, and a list of tlos
.
goals:
goal-1:
name: "Secure Active Directory"
description: "Ensure the security and stability of Active Directory"
tlos:
- tlo-1
Variable | Mandatory | Type | Rules |
---|---|---|---|
name | no | string | |
description | no | string | |
tlos | yes | array of TLOs | TLOs must be defined under TLOs |
Evaluation
Evaluation block describes the evaluation metrics of a TLO.
Evaluation defines name
, description
, metrics
and min-score
.
Metrics
is a list of metrics, that is used to evaluate the TLO.
Min-score
represents the minimum score value that must be attained in order for the training and learning objective to be counted as passed. It can be described either in shorthand:
// shorthand for percentage
min-score: 50
or in longer version, that can be described either in absolute or percentage values:
// long-version
min-score:
absolute: 50
// OR
percentage: 70
Example of evaluations:
evaluations:
evaluation-1:
description: "This measures time to retrieve CTF"
metrics:
- metric-1
min-score: 50
Variable | Mandatory | Type | Rules |
---|---|---|---|
description | no | string | |
metrics | yes | array of Metrics | Metric must be defined under Metrics |
min-score | yes | integer | Min-score can only have one value |
name | no | string |
Entities
Entities are part of an exercise scenario, which represent individuals, organizations, countries, any stakeholder or anything, that has a role in the scenario. Entities represent the trainees, the exercise control (EXCON) teams, and other stakeholders present in the scenario. Trainee entities have training and learning objective associated with them. All entities have a mission connected to their role.
Entities specify their name
and textual description
.
An entity has an optional role
, which represents their role in the exercise: WHITE/GREEN/RED/BLUE.
Every entity contains a textual description of their mission
.
Entities can be of various pre-defined types can be of various types, e.g., Person, Organization, Role, Nodes, Systems etc., which is set by the categories
field. Each entity can have multiple categories.
They can optionally be tied to multiple vulnerabilities
and tlos
.
Optionally, entities can also contain sub-entities
. If some values are not specified in the sub-entities, they will be inherited from the parent-entity.
Entities could have an optional events
field, which can be used to show events to the participant in Ranger UI. If the field is not specified, the participant will still be able to experience the events, but they just won't be shown explicitly.
entities:
my-organization:
name: "My Organization"
description: "This is my organization"
role: GREEN
mission: "defend"
categories:
- Foundation
- Organization
vulnerabilities:
- vulnerability-2
tlos:
- tlo-1
- tlo-2
- tlo-3
events:
- conditional_event
entities:
my-organization-hr:
name: "My Organization HR"
description: "This is my organization HR"
categories:
- HR Department
entities:
helen-in-the-hr:
name: "helen"
description: "nice lady"
vulnerabilities:
vulnerability-1
vulnerability-2
vulnerability-3
fish:
name: "Shark"
description: "This is my organization"
mission: "swim around"
categories:
- Animal
Variable | Mandatory | Type | Rules |
---|---|---|---|
name | no | string | |
description | no | string | |
role | no | enum with options white , green , red , blue | |
mission | no | string | |
categories | no | array of strings | |
vulnerabilies | no | array of Vulnerabilities | Vulnerability must be defined under Vulnerabilities |
tlos | no | array of TLOs | TLO must be defined under TLOs |
entities | no | array of Entities | |
facts | no | hashmap of string :string |