-
Notifications
You must be signed in to change notification settings - Fork 405
3. Content Structure and Versioning
Bhavin Patel edited this page Sep 18, 2024
·
4 revisions
- 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
Elements of a detection yml:
Elements of a detection yml:
Here is a quick overview of the elements of a detection with an explanation:
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 | 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 |
references | list | List of references to the MITRE ATT&CK, details of attack vector, blog posts, vulnerabilities, etc. | http/https links to blogs |
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 |
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 | number between 1-100 |
cve | list | List of CVEs that are related to the detection | CVE-2024-1111 |
impact | int | A number between 0-100 that represents the impact of the detection | number between 1-100 |
message | str | The risk message that will be displayed in the Splunk Enterprise Security | [Example] (https://github.com/splunk/security_content/blob/e2f910a427399813bd7e959f48423728e3c292bb/detections/application/crushftp_server_side_template_injection.yml#L29) |
mitre_attack_id | list | List of MITRE ATT&CK IDs that are related to the detection | Valid TTP ID from Mitre Matrix |
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 |
role | list | Role of the observable | Victim, Attacker, Other |
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 | How to calculate |
security_domain | str | The security domain that the detection is related to | 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 |
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.
- 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