Sigma Rules 101: Writing the Detection (Part 3)

How to define what to look for.

If you missed last weeks post, take a look at crafting the logsource section of a Sigma rule.

SIEM Rules Sigma detection

The most important part of a Sigma rule is the detection section. The detection section contains a set of search-identifiers that represent searches on log data and how they should be evaluated:

Selections — What you actually wish to select/search from the log data (search identifier)
Conditions — How should the selection or filters are to be evaluated

A definition can consist of two different data structures - lists and maps.

Lists are the simplest way to define a selection. They contain strings that are applied to the full log message and are linked with a logical ‘OR’.

List Example 1: Matches on ‘EvilService’ or ‘svchost.exe -n evil’ in a log line

detection:
  keywords:
    - EVILSERVICE
    - svchost.exe -n evil
condition: selection1

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.

They are different to lists, because lists do not allow you to define the key (search field) on which you want to match.

Lists of maps are joined with a logical ‘OR’. All elements of a map are joined with a logical ‘AND’.

Map Example 1: Matches on Eventlog ‘Security’ AND (EventID=517 OR EventID=1102)

detection:
  selection1:
    - EventLog: Security
      EventID:
        - 517
        - 1102
condition: selection1

Map Example 2: matches on Eventlog=’Security’ AND EventID=4679 AND TicketOptions=0x40810000 AND TicketEncryption=0x17

detection:
   selection1:
      - EventLog: Security
        EventID: 4769
        TicketOptions: '0x40810000'
        TicketEncryption: '0x17'
condition: selection1

Maps can be made more advanced through the use of value modifiers.

Map Example 3: matches on CommandLine CONTAINS (DumpCreds OR invoke-mimikatz)

detection:
    selection1:
        CommandLine|contains:
            - DumpCreds
            - invoke-mimikatz
    condition: selection1

Here, the selection (search-identifier) matches the CommandLine field in the log data and uses the transformation modifier (|contains) in order to check if the listed keywords are present.

The condition field shown in the examples above has always been the same (selection1). Essentially we are saying; the detection defined as selection1 must be true for the rule to trigger.

Though we can also add more complex conditions. These can prove useful in tuning the accuracy a rule.

Map Example 4: matches on (CommandLine CONTAINS DumpCreds OR invoke-mimikatz) OR (CommandLine CONTAINS rpc OR token OR crypto) OR (CommandLine CONTAINS bitcoin)

detection:
    selection1:
        CommandLine|contains:
            - DumpCreds
            - invoke-mimikatz
    selection2:
        CommandLine|contains:
            - rpc
            - token
            - crypto
    selection3:
        CommandLine|contains:
            - bitcoin
    condition: 1 of them

Here the condition 1 of them means that one of the defined search identifiers (selection1, selection2, selection3) must appear.

Conversely, you could use the condition all of them, ensuring all search identifiers are matched before the rules is triggered.

Once you deploy a rule to one of your security tools, for example to your SIEM, analysts will probably start to discover some incorrect detections.

These false positive alerts can be dealt with in 2 ways:

Update the rule with a more highly tuned detection. but if that is not possible;
Update the rule with false positive information

Choosing the second option, the falsepositive field can be used to describe a list of known false positives which can occur from a detection.

False positive Example 1:

falsepositives:
    - PIM (Privileged Identity Management) generates this event each time 'eligible role' is enabled. 

Whatever of the two options selected, you can use versioning in SIEM Rules to define and track the changes to the Rule.

When triggered, this information can help an analyst triaging alerts as to how they proceed (or if they follow up on it at all).

SIEM Rules Sigma false positive update version

Detections are the most complex part of a Sigma rule. Take a deeper look at the Sigma wiki for the selections and conditions available as you start to write more complex rules.

In the final part of this post series I’ll show you how to put it all together and import rules into your downstream security tools.