Writing Detection Rules
File requirements
Each detection rule should have its own YAML file. The file should validate against our Schema. Detection rules will not sync if there are errors parsing or validating the YAML.
The file name should end with
.yaml
or.yml
extension. Files with other extensions will be ignored.The file should have
# schema: https://scanner.dev/schema/scanner-detection-rule.v1.json
as its first line. This is how we determine whether to a YAML file is a detection rule. YAML files without this comment will be ignored.
Schema
The schema for Scanner detection rules is at https://scanner.dev/schema/scanner-detection-rule.v1.json.
The schema contains information on the properties, including descriptions, requirements, and valid values. This can be used as a reference to write your detection rules and to validate your YAML documents.
Detection Rule
A detection rule YAML consists of:
name
- detection rule namedescription
- description of detection ruleenabled
- whether the detection rule is enabledseverity
- severity of the detection rule. Scanner uses OCSF Severity ID standards for severity tags. Refer to the schema for more details.query_text
- the query for the detection ruletime_range_s
- the lookback period (in seconds). Refer to the schema for more details.run_frequency_s
- how frequently to run the detection rule (in seconds). Refer to the schema for more details.event_sink_keys
- keys for event sinks to send detection events to. See Detection Rule Event Sinks, below.tests
- a list of test cases and expected results to apply to this detection rule. See Detection Rule Tests, below.
Example
Below is an example YAML for a detection rule. It looks for updates to AWS SecurityHub findings, which may indicate evasion of security measures.
It is configured to run every 60 seconds and look for possible threat activity in the last 5 minutes of logs. It will trigger alerts with High
severity level and send them to the alert event sinks that are associated with the key high_severity_alerts
.
Index Specifiers
To include an index specifier in your query text, you must use the full index specifier format, which is @index={ UUID | "alias" }
. While @index=alias
works on Scanner web and API, this format cannot be used for detection rules because aliases can change.
To get the full index specifier format, tab-to-complete an index specifier in the Scanner search box and copy-paste it into your detection rule file.
Below is a valid index specifier:
Below are examples of invalid index specifiers. These will result in QueryParseErrors
.
Using index
rather than @index
will search for a column called index
rather than filter a Scanner index.
Detection Rule Event Sinks
You can specify keys that identify which event sinks a detection rule should log events to. You can assign one or more actual event sinks to each key in the settings for the sync source; see Getting Started.
Event sink keys can just be specified as an array in YAML. Each event sink key must begin with an ASCII letter, and contain only ASCII alphanumeric characters, -
, or _
.
Example
Below is an example of a detection rule's event sink keys. This should be in the same file as your detection rule.
Detection Rule Tests
You can specify tests in your YAML file to run against the detection rule.
A detection rule test consists of:
name
- test namenow_timestamp
- timestamp to start the test (optional)dataset_inline
- a list of JSON log events for the testexpected_detection_result
- whether the given dataset triggers a detection event
Detection rules will not sync if there are failing tests.
Rules will be validated and tests run on sync.
Dataset
Test datasets are a list of JSON log events. There are a few ways to write test datasets:
You can export results from Scanner as JSON lines and use the results as a test dataset. To export results, run a query in Scanner and click the arrow next to Run and select JSON Lines under Export Results.
You can copy-paste
raw_event
s from Scanner search results. The copy-pasted result is not guaranteed to be valid JSON because values may not be properly escaped.You can write your own JSON log events. A valid JSON log event must contain a
timestamp
in RFC 3339 format. It can contain any number of key/value pairs. An example log event:
Example
Below is an example of a detection rule test. This should be in the same file as your detection rule.
Offline Validation
While working on your detection rules, it can be valuable to test them as-is without needing to push to Github and sync with Scanner. We provide tools to do so:
A JSON schema that describes detection rules can be found at https://scanner.dev/schema/scanner-detection-rule.v1.json, which can be used to validate the YAML files directly.
Last updated