What Snort is to network traffic, and YARA to files, is Sigma to logs. By creating and using Sigma rules you’ll have generic rules which can be shared and run against different targets (e.g. SIEMs). Sigma solves the issue of everyone working on their own analysis, searches and dashboards of log data they’ve collected by having a standardized format to create rules to be reused and shared with others, supporting many different target systems. Many targets are supported currently: Splunk (plainqueries and dashboards), ElasticSearch Query Strings, ElasticSearch Query DSL, Kibana, Elastic X-Pack Watcher, Logpoint, Microsoft Defender Advanced Threat Protection (MDATP), Azure Sentinel / Azure Log Analytics, Sumologic, ArcSight, QRadar, Qualys, RSA NetWitness, PowerShell, Grep with Perl-compatible regular expression support, LimaCharlie, ee-outliers. Some of the use cases for Sigma are:
A Sigma rule is a YAML file, following the specification which be found here, having the following sections:
The detection is the most important part of the rule, defining when the rule will be triggered. It consists of one or more selectors, each selector can be a map (all joined with a logical function and) or list (logical function or) and be nested. The map or list will contain the column to test (using wildcards for fields) and a value, with optional transformations (contains, all, base64, startswith, endswith, etc.) or type modifiers (regular expression). An optional timeframe will define the period for the selector to be aggregated on. The condition will tie everything together, evaluating the selectors using an expression that is usually complex. Within the condition, logical functions like and/or, not, one of, any of and aggregations expressions (count, min, max, avg and sum) on selectors (which can use wildcards) can be used. As an example, this rule detects the removal of immutable file attributes on linux systems logged by auditd. The selection will evaluate logs where the field type equals ’EXECVE’, and a0 contains “chattr” and a1 contains “-i”. (a0 and a1 are both arguments to execv). If the condition (in this case, if selection evaluates to true) applies, the rule will trigger.
Selections and conditions can become very sophisticated, allowing fine grained control and evaluations. A more complex detection is given below, where it will trigger if the sum of the question lengths, grouped by src_ip within 1m meeting the “selection” criteria (on each dns query).
The Sigma repository contains besides many rules, also sigmac, the sigma compiler. The sigma compiler compiles the Sigma rule to a different target system, e.g. Elasticsearch. If you want to play around with Sigma, it will be easiest to setup a docker container. As an example, we will use sigmac to compile the rule to an elasticsearch query, with as configuration of elk-windows resulting into the following query:
Another way to test and play with Sigma and the results it transforms into, is by using the website https://uncoder.io/ (powered by SOC Prime). Uncoder.io can convert Sigma (and other rules and queries) to many different formats, allowing easy experimenting. References:
Remco Verhoef (@remco_verhoef)
|
Remco 26 Posts ISC Handler Jun 19th 2020 |
Thread locked Subscribe |
Jun 19th 2020 2 years ago |
Sign Up for Free or Log In to start participating in the conversation!