3. Content Structure and Versioning

Content Parts

• stories/: All Analytic Stories shipped in ESCU have their
• detections/: Splunk Enterprise, Splunk UBA, and Splunk Phantom detections that power Analytic Stories
• deployments/: Deployment configurations for scheduling correlation searches in Enterprise Security
• macros/: Macros that are used by the detections
• lookups/: Lookups that are used by the detections
• playbooks/: Playbook configurations that are associated with analytic stories
• dashboards/: Contains xml configuration for the dashboards shipped with the app

Keys of the yaml files

Elements of a detection yml:

Key	Type	Description	Example/Allowed Values
name	str	Name of the detection, this is the name that will be displayed in the Splunk UI	naming convention
id	int	Unique identifier for the detection, UUID	uuid
version	int	Version of the detection, update this every time a change is made to the file	integer
date	str	Date of the detection, update this every time a change is made to the file	date when the yaml file is created/modified
author	str	Author of the detection	your name
type	str	Type of the detection (TTP, Anomaly, Baseline, Hunting, Correlation)	TTP, Anomaly, Baseline, Hunting, Correlation
status	str	Status of the detection (Production, Experimental, Deprecated)	Production, Experimental, Deprecated
data_source	list	Reference to the data source that the detection is based of	name from the data_sources/ folder
description	str	Description of the detection	Example
search	str	Splunk search to be executed, this is the core of the detection. Detections can be either written against the sourcetype or in tstats if the data is normalized. Sourcetype based searches begin with an input macro, core search logic and end with a filter macro. The input macro is used to specify the index and sourcetype and the filter macro is used to filter out the false positives.	Example
how_to_implement	str	Details on how to implement the detection	Example
known_false_positives	str	Details on known false positives triggered in this detection.	Example](https://github.com/splunk/security_content/blob/e2f910a427399813bd7e959f48423728e3c292bb/detections/application/crushftp_server_side_template_injection.yml#L19)
references	list	List of references to the MITRE ATT&CK, details of attack vector, blog posts, vulnerabilities, etc.	http/ https://
tags		Tags are various metadata that can be used to categorize the detection
analytic_story	list	Name of the analytic story that the detection is part of	Example](https://github.com/splunk/security_content/blob/e2f910a427399813bd7e959f48423728e3c292bb/detections/application/crushftp_server_side_template_injection.yml#L25)
asset_type	str	Which assets are monitored by this detection (Endpoint, Network, AWS Tenant, Azure Tenant, etc.)	Endpoint, Network, AWS Tenant, Azure Tenant
confidence	int	Confidence level of the detection
cve	list	List of CVEs that are related to the detection
impact	int	A number between 0-100 that represents the impact of the detection
message	str	The risk message that will be displayed in the Splunk Enterprise Security
mitre_attack_id	list	List of MITRE ATT&CK IDs that are related to the detection
observable	list	List of observables that are related to the detection
name	str	Field name of the observable
type	str	Type of the observable (User, Endpoint, File, Process Name)	User, Endpoint, File, Process Name
role	list	Role of the observable (Victim, Attacker)	Victim, Attacker
product	list	List of products that are related to the detection (Splunk Enterprise Security, Splunk Enterprise)	Splunk Enterprise Security, Splunk Enterprise
required_fields	list	List of required fields that are needed to execute the detection
risk_score	int	A number between 0-100 that represents the risk score of the detection
security_domain	str	The security domain that the detection is related to (Network, Endpoint, Cloud, etc.)	Network, Endpoint, Cloud, etc.
tests
name	str	Name of the test
attack_data	url	URL to the attack data that is used to test the detection
data	str	Data of the attack
source	str	Source of the attack
sourcetype	str	Sourcetype from the attack

Release Versioning

Each Splunk Security Content release follows a 3 number structure: <major>.<minor>.<patch> for example 3.9.1. The following is an explanation of what each number signifies and when the numbers change.

• <major> - This number pertains to the specification/schema version our content is adhering to. Today we are in spec 3.0. This number only changes when we make a schema change or update.
• <minor> - This number pertains to the update we are on. This number increases every time we introduce a new piece of content. Examples of content include, but are not limited to, the following: detections, stories, responses, and so on.
• <patch> - This number pertains to fixes for content. This number increases every time we resolve a bug with a current piece of content but do not introduce any new functionality.

We did not come up with this concept and are just implementing semantic versioning per https://semver.org/. Note that release announcements are only sent out for major and minor changes, but not usually for patches unless they contain critical issues that require communication.

Content Versioning of yaml files

• version - This number is an integer and is bumped every time a yaml file is changed
• date - This date string is updated every time the content is modified