YAML administration techniques_v1_2

In this YAML file you can administrate your detection and visibility scores per ATT&CK technique. Among others, based on this information DeTT&CT can generate layer files for the ATT&CK Navigator to show an overview of your detection and visibility coverage.

Sample file: techniques-administration-endpoints.yaml

Current version: version 1.2

Version 1.1 can be found here.

File content

Name	Type	Required	Description
version	string	yes	Version of this technique administration file. The current version is 1.2.
file_type	string	yes	Used to indicate what type of YAML file it is. Possible values: data-source-administration, technique-administration and group-administration. For techniques administration the value should be: techniques-administration.
name	string	yes	Describes for what type of assets you are describing the techniques for. E.g. endpoints.
domain	string	yes (defaults to enterprise-attack)	Specify the ATT&CK domain using the value enterprise-attack, ics-attack or mobile-attack
platform	string or list of strings	yes	Indicates the type of platform you are describing the techniques for. Possible values (in the list) are the MITRE ATT&CK platform values or 'all' to select all platforms: PRE, Windows, Linux, macOS, Office 365, Azure AD, Google Workspace, IaaS, SaaS, Network, Containers.
techniques	list with technique objects	yes	Administration of detection and visibility for each technique. See the description of the technique object.
notes	string	no	An optional field to include notes on this technique administration file.

Technique object

Name	Type	Required	Description
technique_id	string	yes	The technique ID according to MITRE ATT&CK. E.g. T1055.012.
technique_name	string	no	The technique name according to MITRE ATT&CK. E.g. Process Injection: Process Hollowing.
detection	detection object	yes	Detection object(s) containing information on the detection and its score. See the description of the detection object. When having multiple detections, this becomes a list of detection objects.
visibility	visibility object	yes	Visibility object(s) containing the visibility score. See the description of the visibility object. When having multiple visibility objects, this becomes a list.

Detection object

You can have multiple detection objects within a technique object for different type of systems (e.g. Windows endpoints, Windows servers, Linux servers, crown jewel x, etc.). The key-value pair applicable_to indicates the type of system(s) the score applies to. Please note that within the same technique, a system can only be part of one applicable_to key-value pair.

We recommend using the same applicable_to values between your data source and technique administration file. More info on this topic can be found here.

Name	Type	Required	Description
applicable_to	list of strings	yes	Specify to which type of system this detection applies to. This is a free format text field, so any string value is valid. Use the value ['all'] to let it apply to every type of system.
location	list of strings	yes	The location where your detection is residing. E.g. your SIEM product or a specific ID or name of a use case/detection. You can use a 'location prefix' to group detections, for example: 'SIEM: Rule A' and 'EDR: Rule B'. This location prefix will also be used when you use the -cd / --count-detections argument on the command line.
comment	string	yes	An option to comment on the detection for this technique. If you want to have a multiline comment in the Excel output. We recommend making use of |. For more info have a look at: yaml-multiline.info.
score_logbook	list of score objects	yes	List of score objects describing the detection score, date and possible comment. The primary purpose is to keep track of changes in the score. See the score object for its description. See T1569.002 in the example file: techniques-administration-endpoints.yaml.

Visibility object

You can have multiple visibility objects within a technique object for different type of systems (e.g. Windows endpoints, Windows servers, Linux servers, crown jewel x, etc.). The key-value pair applicable_to indicates the type of system(s) the score applies to. Please note that within the same technique, a system can only be part of one applicable_to key-value pair.

We recommend using the same applicable_to values between your data source and technique administration file. More info on this topic can be found here.

Name	Type	Required	Description
applicable_to	list of strings	yes	Specify to which type of system the visibility and its score apply to. This is a free format text field, so any string value is valid. Use the value ['all'] to let it apply to every type of system. When ['all'] is used, no other values are allowed.
comment	string	yes	An option to comment on the visibility for this technique. If you want to have a multiline comment in the Excel output. We recommend making use of |. For more info have a look at: yaml-multiline.info.
score_logbook	list of score objects	yes	List of score objects describing the visibility score, date and possible comment. The primary purpose is to keep track of changes in the score. See the score object for its description. See T1568 in the example file: techniques-administration-endpoints.yaml.

Score object

You can have multiple score objects within the score logbook for a detection or visibility object. The primary purpose is to keep track of changes in the score. See T1569.002 in the example file: techniques-administration-endpoints.yaml.

Name	Type	Required	Description
date	date yyyy-mm-dd	yes	Detection: the date when the detection was implemented or improved. Visibility: the date when you registered, implemented or improved the visibility. This date is used to draw a graph indicating the progress of your detection capabilities. Also, you can visualise this change within an ATT&CK Navigator layer file using an EQL query. More info on the latter can be found here.
score	int	yes	Score between -1 and 5 for detection and 1 and 4 for visibility.
comment	string	yes	An option to comment on the score. If you want to have a multiline comment in the Excel output. We recommend making use of |. For more info have a look at: yaml-multiline.info.
auto_generated	boolean	no	Indicates if the score was auto-generated based on the number of data sources within the data source administration file (using the option -y, --yaml from the datasource mode in dettect.py) . This property is optional and only used for visibility. When manually scoring your visibility you can omit this property or set it to False. The purpose of having this property is to allow an easy update of your visibility scores based on changes in your data sources. Or modification within MITRE's semi-annual update of ATT&CK (possible new techniques, data sources or changes in the data source listed for a particular technique). For more info see: Auto-update visibility scores and the use of the score_logbook