Proposal: Sigma Defeats

[sifex]

Hi Team,

I've drafted the following proposal on a problem that I had at my previous role. Please let me know your thoughts and if there's anything you're currently doing to fill this gap.

---

Proposal

Defeats are a way to collect and apply false positives to Sigma rules.

Abstract

Defeats are designed to sit alongside Rules as a method of preventing future false positives when implementing Sigma rules. They answer the question of:

How do I as a Security Analyst prevent this rule from triggering on host XXXXXX.domain.com

or

How to I as a Security Analyst locally apply false positives to some client environments, and not to others?

The advantages that Defeats have over using the existing filter strategy are:

• their scope can be localised to a client or SIEM instance, giving end-users the ability to prevent future false positives when implementing Sigma rules
• they don't modify or impact on any existing Sigma rule, and provides a solution to those wanting to keep existing upstream Sigma repositories "as-is", and without local modification
• they can apply to multiple rules, de-duplicating existing filters across Sigma alerts

These are located in files separated from the Sigma rule itself.

Defeats can but shouldn't replace the commonly seen pattern of including filter as a part of the Sigma rule. This strategy of using filters in a Sigma rule should be kept in-place, where everyone in the community can benefit from a contribution of a Pull Request to prevent known false positives.

Naming

The name of a "Defeat" came from an analyst team "defeating" reoccurring false-positives as part of the tuning process. Name is not final and is likely to change in later revisions.

Versioning

Defeats are proposed to be implemented in Sigma version 2 and above.

Backwards compatibility

This proposal ensures backwards compatibility by not modifying the existing Sigma rule specification, and exists as an entirely optional feature.

Implementation

Similar to other Sigma standards, Defeats are YAML files that would sit alongside a repository of rules, typically under the defeats/ directory. They would supply information about when a given detection should not trigger.

Some examples of this could include:

• do not trigger against a Domain Controller based on hostname naming (for detections targeting Security Group additions and deletions)
• do not trigger against service the following service accounts, based on how clients name their service accounts

Defeats would act as a standard interface that backends can support within pySigma's pipeline hooks.

In the case of Splunk (or other backends that can include CSV lookups) their implementation strategy for defeats could include:

| search NOT [|inputlookup exclude_common_administration_accounts.csv]

as a method of not bloating out the search string itself. Other backends can inline Defeats within searches.

Usage

Defeats should be applied by passing an additional optional flag to the sigma-cli convert command as -D or --defeat.

The existing method of detection should be used as to not overcomplicate the intent to new users.

ids field is used to list the rules in which the defeats applies.

# defeats/global/exclude_common_administration_accounts.yml
name: Exclude common administration accounts
description: ...
ids:
    - 12345678-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
    - 91011121-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
    - 31415161-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
detection:
    service_accounts:
        AccountName|startswith:
            - SVC_
    condition: not service_accounts

Applied to an existing rule, you would see the following after conversion.

Basic Interpretation

---

index="..." EventCode=123
| search NOT AccountName="SVC_*"

Complex Interpretation

index="..." EventCode=123
| search NOT [|inputlookup exclude_common_administration_accounts.csv]

Challenges

• Field Names / Validation across rules
• Keeping v1 unaffected by keeping existing filter in rules (essentially don't remove)
• Communication and Integration with existing pySigma Backends / pySigma probing whether the backend fully supports this feature.

Development

The following developers take on the responsibility of providing the PR as part of pySigma.

• Alex (@sifex)

Contribution

This proposal welcomes any feedback / changes. When doing so, please ensure constructive feedback if at all possible.

[nasbench]

First of all thanks for your contribution and an Interesting proposal indeed. I have a couple of questions first.

1st point is who would provide these "defeats"? Because from what I Understand these are specific to organizations and how they want to apply (or in this case not apply) certain rules depending on certain conditions. Basically, it requires specific knowledge of the org itself. So it cannot be community driven to a certain extent. And in the case where the "defeat" condition is "generic" enough it would be equal to a filter since it would be considered an FP to the rule.

2nd point is. Why make it part of SIGMA if it's specific and different on an org-by-org basis and also backend-dependent? Meaning why would someone write in SIGMA rather than his own backend language?

I think of this as typical work of detection/analyst teams. They know their env the best and they choose to apply or remove certain rules based on their knowledge and the tools available to them from a backend perspective (similar to how you showed the example with Splunk).

Please correct me if I'm wrong in my understanding.

Cheers.

[sifex]

Yea all good points. I think the only reason why this comes into major relevancy is that the whole Ctrl+C & Ctrl+V nature of Sigma rules is archaic, and CI/CD methodologies are making their way into our SOCs, as well as others.

To answer both points, this resolves the issue of:

I have 10 Sigma rule repos, containing exactly which rules best apply to each client (including paid and custom rules), all continuously deploying out to 10 different SIEMs using Gitlab/Github CI. Where do I as an analyst add my false positives? I can append them to the end of the query using some hack, but then I don't get field mapping for that logsource. Do we manually convert them when it comes to deploying them? What happens if a lead forgets to add / removes / typos the FP snippet?"

The reason why this should be a part of Sigma is imho Sigma backends now have the ability - and strong encouragement - to deploy straight to the SIEM (using API calls for the most part) thanks to pySigma. You can see this need in SEIGMA and Sigma2SplunkAlert for this to become standard, just in Splunk alone.

---

Opinion (separate from Proposal, but maybe provides context).

I'm definitely over in On-Prem land where this stuff is definitely more prevalent than cloud.

Sigma's future has the ability to streamline the workflow for thousands of SOCs. You have one repository per client - filled with rules, defeats, workflows, notes, lookups - all continually being contributed by your analyst & detection teams, updates made over - and reviewed using PRs, and deployed out to your SIEM automatically, possibly even validating rules against known true-positive log snippets as part of your test suite.

Edit: Defeats are also probably just syntactical sugar for what Sigma Rule implementators are going to have to do with pySigma piplines anyway using wildcards.

[frack113]

For me there are 3 completely different things:

• the sigma specification
• the rule deposit
• the conversion tools

Having a way to manage not filter but specific FP in the specifications is a good thing.

name: Exclude common administration accounts
description:  WHY I do it 
ids:
    - 12345678-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
    - 91011121-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
    - 31415161-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
logsource:
exclution:
    service_accounts:
        AccountName|startswith:
            - SVC_

• name no comment
• description This is a good practice
• ids would like to change for something like rule/cover (IDS brings me back to my WAF , firewall dark age)
• logsource I don't want someone make a windows exclution on auditd rules
• exclution I can only exclude local FP

Usage Case:
I have a internal application with a powershell script that look like a APT and you can not kill the dev .
I will not make a PR on SigmaHQ , We are the only one with this application.

• Sigma Specification V1
  I edit all the FP rule and add a filter filter_bad_script with the name and path .
  If the rule is updated, I have to do it again

• Sigma Specification V2
  I edit a exclution file add the id of the FP rules.
  If the rule is updated, I say my boss i have 2 days of works like in V1

The converter should work "Signa condition AND NOT sigma exclution"

I want to keep this case as simple as possible.
If you have to make many exclusion for a rule , you should ask your self why.

[sifex]

🧡 Great additions, thanks for the feedback, I'll update it in a quick moment.

• Re: converter
  I'm really really torn on whether the design of Defeats should perform an inclusive or exclusive by default –
  ie.
  selection not (defeat) (negation implied) or
  selection (not defeat) (negation explicit / with the "not" in the defeat itself).

  Mainly this is to avoid the double negative that happens when you want to ONLY include certain selections.

  I totally see why & where a defeat should lose the "not". I guess the thinking behind it is

  • How do people expect it to work without thinking about it,
  • How complicated does the negation of AND / OR operations become and
  • How much pain is there context switching behind thinking
    • "OK, I'm writing a detection, so this is an inclusive search" vs
    • "OK, I'm writing a defeat, this is an exclusive search, so they're technically a NOT in-front of everything I write (in brackets).

[sifex]

nvm I didn't see the field name exclusion. That makes sense to have exclusion (and by extension inclusion) so that it's clear what the defeat is doing.

Edit:

Exclusion Example:

# rules/example_rule.yml
logsource:
    product: windows
    service: security
detection:
    selection: 
        field: value
    condition: selection

# defeat/default_exclusion_example.yml
name: Defeat Exclusion Example
description: Example description
ids:
    - 12345678-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
logsource:
    product: windows
    service: security # Will throw a warning / fatal if the ID is not targeting this log-source.
exclude:
    excluded_hosts:
        ComputerName|startswith:
            - DEV_
            - TST_

index="win_security" source="WinEventLog:Security" field="value"
| search NOT ( host=DEV_* OR host=TST_* )

Inclusion Example:

# defeat/default_inclusion_example.yml
name: Defeat Inclusion Example
description: Example description
ids:
    - 12345678-bef0-4204-a928-ef5e620d6fcc # rules/windows/builtin/...
logsource:
    product: windows
    service: security # Will throw a warning / fatal if the ID is not targeting this log-source.
include:
    included_hosts:
        ComputerName|startswith:
            - PROD_
            - STAG_

index="win_security" source="WinEventLog:Security" field="value"
| search ( host=PROD_* OR host=STAG_* )

[frack113]

For me "defeat" don't have a condition, so to keep it simple

action: include/exdude
selection: <= need a better name to avoid someone think it the same selection from rule :)
   fieldname|contains: only_you

so the converter can say I have my condition "A" with action I know if I must "and" or "and not" the "selection" part.

I would like to keep with a single selection (can be a list )

[Neo23x0]

I would call the section selection. It's a good term for what it does.
In combination with the action, it should be readable. The field actions should be used right before the selection, so that users read: "Ah, the action is exclude and it selects this and that."

[sifex]

Do we allow for multiple selection groups, or force one? It allows for the grouping of selections but implies that you also need to include a condition section for logic to be applied.

[Neo23x0]

I really like the idea because of three reasons:

1. It doesn't break things. Filter rules can be added in a separate folder with a reference to an existing rule. Nothing has to be changed in the existing rule.
2. We keep filtering general false positives in the rules and give users the option to add their own filters. Sigma users would have a native way to define filters that is supported by the converter (pySigma) and don't have to work on their own custom solution. And yes, they would have to work on their own solution whenever the filters aren't flexible enough and they have to make use of query language-specific functions of their SIEM. But I like the idea of providing a native way to filter events.
3. I expect a further acceleration of the trend of threat actors using legitimate tools (including remote access software, process dumpers etc.) that may or may not be legitimately used in a particular organization. This means that we're going to get many more rules for "suspicious use of tool X" and organisations would want to filter out legitimate events in their org.

What I don't like is the term "defeats". For me it has a negative connotation.

I'd like to propose a different name. It should reflect the function of the rules in the most generic form OR the function for what they're most commonly used.

My proposals:

• Sigma Filters
• Sigma Selectors
• Sigma Directives
• Sigma Event Screens
• Sigma Event Masks

[frack113]

the goal is to make a local adaptation of the rule.
I think of

• Sigma detection alteration
• Sigma detection adaptation

• Sigma Filters : I would like keep filter in the rule detection section
• Sigma Selectors : It gives me more the idea to activate or deactivate
• Sigma Directives : It gives me more the idea of the configuration or conversion part
• Sigma Event Screens : no idea
• Sigma Event Masks: 👍 as we remove FP

[thomaspatzke]

The more I think about it, the more I like it 😊 I think the concept fits quite well into the existing Sigma specification and pySigma.

The first idea that came into my mind: defeats already look mostly like Sigma rules, why shouldn't we make special-purpose Sigma rules out of it? There's already the action attribute used for Sigma rule collections and correlations. Furthermore, correlations already have an attribute rule for referencing other rules. I propose to use the same attribute (perhaps renamed to the plural form rules) to maintain consistency across these different Sigma extensions.

Technically, some of the enhancement required for Sigma correlations could also be used for defeats. I plan to implement the dependency resolving into the SigmaCollection class or perhaps a new one. Basically, the process for defeats would be as follows:

1. All rules including defeats are read and parsed as Sigma rules.
2. All defeats are applied to their referenced rules by extending the condition and detection definitions of the rules (see below for some consideration about details).
3. Sigma rules are then preprocessed/transformed as usual. In this stage, the field mappings can be applied logsource-aware. Therefore I think Challenge 1 should be already mostly solved.

The advantage of putting defeats in the front of the Sigma rule conversion process would be that all the rule handling stuff, especially processing pipelines, could be reused for defeats. This would include field name mappings and value transformations as well as generation of lookups from placeholders, like it's done in this example. There must also be no backend support for defeats because all the magic would happen in the Sigma rule preprocessing stage before the backend comes into play. So far I don't believe that Challenge 3 is really one.

Regarding the condition I like the idea of @frack113 to define it via the action attribute of the rule. On the other way I think we should give the user the possibility to define the defeat condition that can reference to the detection definitions of the defeat in an arbitrary way to make the thing flexible. It's by the way something I've already implemented at least for the inclusion part in the AddConditionTransformation.

I think we should define defeats as extension to Sigma in a dedicated specification document like we've done with correlations. For the name I would prefer "Sigma Filters", but I'm also fine with naming it "Sigma Defeats" 😉

[frack113]

Let's make a short summary :
Sigma specification will be in 2 files:

• rule file specification
• global action
  • correlations
    • Event Count
    • Value Count
    • Temporal Proximity
  • cross filter (first wrote "global filter" but change to avoid repetition)
  • As it is open more options

global action should have a unique skeleton to keep simple.
The converter (no name in the specification) :

1. read the global action
2. read the rule
3. makes the magic happen

One question , In PySigma it is possible to deal with a "cross filter" over "correlations" over rules ?

[thomaspatzke]

Currently in pySigma all rules exist as own objects without interconnections. This will change with the enhancement of SigmaCollection.

We should also consider to drop the global rule thing in v2. It's kind of legacy used before generic log sources for maintaining different logsources (mostly Sysmon/1, Security/4688) in one file and is not used widely and error prone through its implicit nature. With correlations and defeats the relation will become explicit.

[sifex]

Awesome feedback everyone. I'll be compiling the spec hopefully across this next coming week with implementation across by mid Feb.

I'm fairly sure I'm going to name it "Local Filters" (as the best interpretation as someone who is familiar with the concept of "Global Filters", that also gives the best OOTB explanation. Docs could then just contain a section called "Filters" that explain both techniques.

[00willo]

@sifex Really looking forward to see this added to the spec.

[sifex]

So am I, though I'm still recovering from jet-lag as well as many other life events, sorry I wasn't able to keep to this deadline. I'll keep everyone posted once I get around to it. 🙂

[sifex]

@00willo getting there... SigmaHQ/pySigma#226

[sifex]

Added in https://github.com/SigmaHQ/sigma-cli/releases/tag/v1.0.3, closing as complete