Skip to main content

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"
VariableMandatoryTypeRules
speedyesfloatSpeed value must be at least 1.0
scriptsyesarray of ScriptsStory must have at least one Script
Script must be defined under Scripts
descriptionnostring

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"
VariableMandatoryTypeRules
start-timeyestime
end-timeyestimeEnd-time must be greater than start-time
speedyesfloatSpeed must have a positive value
eventsyeshashmap of Event:timeScript must have at least one Event
Event must be defined under Events
descriptionnostring

Accepted formats for time specification

UnitDescriptionUnit list option(one of)Example
yYear["y" , "year" , "Y" , "YEAR" , "Year"]1y
monMonth["mon" , "MON" , "Month" , "month" , "MONTH"]1mon
wWeek["w" , "W" , "Week" ,"WEEK" , "week"]1w
dDay["d" , "D" , "Day" , "DAY" , "day"]1d
hHour["h" , "H" , "Hour" , "HOUR" , "hour"]1h
mMinute["m" , "M" , "Minute" , "MINUTE" , "minute" , "min" , "MIN"]1m
sSecond["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"
VariableMandatoryTypeRules
sourcenostring or
object with fields: name, version
Time must have a float value between 0 and 1
conditionsnoarray of ConditionsCondition must be defined under Conditions
injectsnoarray of InjectsEvent must have at least one Inject
Inject must be defined under Injects
descriptionnostring

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
VariableMandatoryTypeRules
sourcenostring or
object with fields: name, version
from-entitynoEntityInject must have from-entity declared if to-entities is declared
to-entitiesnoarray of EntitiesInject must have to-entities declared if from-entity is declared
tlosnoarray of TLOsTLO must be defined under TLOs
descriptionnostring
environmentnoarray 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
VariableMandatoryTypeRules
commandnostringMust be defined if interval is used
intervalnointegerMust be defined if command is used
sourcenostring or
object with fields: name, version
Condition must have command and interval or source defined, not both
descriptionnostring
environmentnoarray 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
VariableMandatoryTypeRules
typeyesenum with options service, configuration, artifact
sourcenostring or
object with fields: name, version
destinationnostring
environmentnoarray of hashmaps of string:string
dependenciesnoarray of FeaturesFeature must be defined under Features
vulnerabilitiesnoarray of VulnerabilitiesVulnerability must be defined under Vulnerabilities
descriptionnostring

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"
VariableMandatoryTypeRules
nameyesstring
descriptionyesstring
technicalyesboolean
classyesstringVulnerability 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
VariableMandatoryTypeRules
typeyesenum with options VM or switch
sourceyes for VMs, no for switchesstring or
object with fields: name, version
resourcesyes for VMs, no for switchesobject with fields: cpu (integer), ram (integer)
rolesnohashmap of string:string or object with fields username and entities
vulnerabilitiesnoarray of VulnerabilitiesVulnerability must be defined under Vulnerabilities
featuresnohashmap of Feature:RoleFeature must be defined under Features
conditionsnohashmap of Condition:RoleCondition must be defined under Conditions
descriptionnostring

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 are a list of switches which are dependent upon other nodes.

switch-1:
count: 1
ubuntu-10:
links:
- switch-1
VariableMandatoryTypeRules
countyesintegerFor machines, that are running conditions, the count is limited to 1.
linksnoarray of NodesMust be of type switch
dependenciesnoarray of NodesMust be of type VM
descriptionnostring

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"
VariableMandatoryTypeRules
namenostring
typeyesenum with options manual or conditional
artifactnobooleanConditional metric cannot have an artifact
max-scoreyesintegerMetric max-score cannot be 0
conditionnoConditionManual metric cannot have a condition
Conditional metric must have a condition
The same condition cannot be used under multiple metrics
descriptionnostring

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

VariableMandatoryTypeRules
namenostring
descriptionnostring
evaluationyesEvaluationEvaluation 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
VariableMandatoryTypeRules
namenostring
descriptionnostring
tlosyesarray of TLOsTLOs 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
VariableMandatoryTypeRules
descriptionnostring
metricsyesarray of MetricsMetric must be defined under Metrics
min-scoreyesintegerMin-score can only have one value
namenostring

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



VariableMandatoryTypeRules
namenostring
descriptionnostring
rolenoenum with options white, green, red, blue
missionnostring
categoriesnoarray of strings
vulnerabiliesnoarray of VulnerabilitiesVulnerability must be defined under Vulnerabilities
tlosnoarray of TLOsTLO must be defined under TLOs
entitiesnoarray of Entities
factsnohashmap of string:string