security-tools/blue-team-tools
1
0
Fork 0
Code Issues Pull Requests Actions 45 Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Florian Roth
2017-02-07 00:24:10 +01:00
committed by GitHub
parent 411cc8b7af
commit a69c7e3cf7
1 changed files with 15 additions and 201 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+15 -201
View File
@@ -5,216 +5,30 @@ Generic Signature Format for SIEM Systems
# What is Sigma?
Sigma is a generic signature format that allows you to describe relevant log events in a straight forward manner.
- Open repository for sigma signatures
- Set of converters that generate searches/queries for different SIEM systems
Sigma is a generic and open signature format that allows you to describe relevant log events in a straight forward manner. The rule format is very flexible, easy to write and applicable to any type of log file. The main purpose of this project is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.
![sigma_description](./images/Sigma-description.png)
This repository contains:
* Sigma rule specification in the [Wiki](https://github.com/Neo23x0/sigma/wiki/Specification)
* Open repository for sigma signatures in the ```./rules```subfolder
* Collection of converters that generate searches/queries for different SIEM systems [Pending]
See the first slide deck that I prepared for a private conference in mid January 2017.
[Sigma - Make Security Monitoring Great Again](https://www.slideshare.net/secret/gvgxeXoKblXRcA)
# Specification
The rules consist of a few required sections and several optional ones.
The specifications can be found in the [Wiki](https://github.com/Neo23x0/sigma/wiki/Specification).
```
title
status [optional]
description [optional]
reference [optional]
detection
{search-identifier} [optional]
{string-list} [optional]
{field: value} [optional]
...
timeframe [optional]
condition
falsepositives [optional]
level [optional]
```
The current specification can be seen as a proposal. Feedback is requested.
## Title
# Next Steps
A brief title for the rule that should contain what the rules is supposed to detect (max. 256 characters)
## Status
Declares the status of the rule:
- stable: the rule is considered as stable and may be used in production systems or dashboards.
- test: an almost stable rule that possibly could require some fine tuning.
- experimental: an experimental rule that could lead to false results or be noisy, but could also identify interesting
events.
## Description
A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)
## Detection
A set of search-identifiers that represent searches on log data
## Search-Identifier
A definition that can consist of two different data structures - lists and maps.
### Lists
The lists contain strings that are applied to the full log message and are logically linked with an 'OR'y.
Example:
```
detection:
keywords:
- EVILSERVICE
- svchost.exe -n evil
```
This example results in the following search expression:
```
EvilService OR "svchost.exe -n evil"
```
### Maps
Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value a string or integer value. Lists of maps are joined with a logical 'OR'. All elements of a map are joined with a logical 'AND'.
Examples:
```
detection:
selection:
- EventLog: Security
EventID:
- 517
- 1102
condition: selection
```
Splunk Search (implicit AND):
```
EventLog=Security ( EventID=517 OR EventID=1102 )
```
### TimeFrame
A relative time frame definition using the typical abbreviations for day, hour, minute, second.
Examples:
```
15s
30m
12h
7d
3M
```
Note: The time frame is often a manual setting that has to be defined within the SIEM system and is not part of the generated query.
## Condition
The condition is the most complex part of the specification and will be subject to change over time and arising requirements. In the first release it will support the following expressions.
- Logical AND/OR
```keywords1 or keywords2```
- X of search-identifier
```1 of keywords```
Same as just 'keywords' if keywords are dafined in a list. X may be:
- 1 (logical or across alternatives)
- all (logical and across alternatives)
- Negation with 'not'
```keywords and not filters```
- Pipe
```expression1 | expression2```
A pipe indicates that the result of search *expression1* is:
- filtered by search *expression2* (equivalent to logical *and*)
- aggregated by aggregation *expression2* and possibly compared with a value
The first expression must be a search expression that may be followed by an arbitrary number of filtering search
expressions and finally followed by an aggregation expression with a condition.
- Brackets
```selection1 and (keywords1 or keywords2)```
- Aggregation expression
agg-function(agg-field) [ by group-field ] comparison-op value
agg-function may be:
- count
- distcount (count distinct values)
- min
- max
- avg
- sum
Example: ```count(UserName) by SourceWorkstation > 3```
The comparison operates on the result values of all aggregation groups or buckets. It is sufficient when one group matches
the condition.
Operator Precedence (least to most binding)
- |
- or
- and
- not
- x of search-identifier
- ( expression )
## FalsePositives
A list of known false positives that may occur.
## Level
A score between 0 and 100 to define the degree of likelyhood that generated events are actually incidents.
A rough guideline would be:
- 20 : Interesting event but less likely that it's actually an incident. A security analyst has to review the events and spot anomalies or suspcious indicators. Use this in a dashboard panel, maybe in form of a chart.
- 40 : Interesting event, that shouldn't trigger too often. A security analyst has to review the events and spot anomalies or suspcious indicators. List the events in a dashboard panel for manual review.
- 60 : Relevant event that should be reviewed manually on a more frequent basis. A security analyst has to review the events and spot anomalies or suspcious indicators. List the events in a dashboard panel for manual review.
- 80 : Relevant event that should trigger an internal alert and has to be reviewed immediately.
- 100 : Highly relevant event that triggers an internal alert and causes external notifications (eMail, SMS, ticket). Events are clear matches with no known false positives.
## Placeholders
## Examples
```
title: Eventlog Cleared
description: Some threat groups tend to delete the local 'Security'' Eventlog using certain utitlities
detection:
selection:
- EventLog: Security
EventID:
- 517
- 1102
condition: selection
falsepositives:
- Rollout of log collection agents (the setup routine often includes a reset of the local Eventlog)
- System provisioning (system reset before the golden image creation)
level: 70
```
* Creation of a reasonable set of sample rules
* Release of the first rule converters for Elastic Search and Splunk
* Integration of feedback into the rule specifications
* Collecting rule input from fellow researchers and analysts
* Attempts to convince others to use the rule format in their reports, threat feeds, blog posts, threat sharing platforms