Sigma Filters

Sigma filters let you tune Sigma rules for your environment without changing the underlying Sigma rules. A filter identifies one or more Sigma rules and describes the events that AlphaSOC should suppress for those rules.

For example, you can filter an approved administrative account, a trusted scanner, or another known source of expected activity from several Sigma rules at once. Keeping this logic in a separate filter makes it easier to update the targeted Sigma rules later.

caution

An overly broad filter can hide important security activity. Use the narrowest possible logsource and selection, then monitor the affected Sigma rules after enabling the filter.

How Sigma filters work in AlphaSOC

When a new event matches an enabled filter's logsource and filter.condition, the Sigma rules listed in the filter don't trigger for that event. All other rules process the event as usual.

Filters apply only to new events. They do not remove alerts or findings that AlphaSOC created before the filter was enabled.

You can target Sigma rules in your workspace using their YAML id or name.

A filter can't target another filter. Every rule a filter lists must exist and be enabled when you save or enable the filter. While the filter is enabled, you can't disable or delete the rules it lists. Disable the filter first.

Filter structure

A Sigma filter is a YAML document that uses a top-level filter section instead of a detection section. It does not have a severity level because it does not create a detection by itself.

The following example suppresses a custom Sigma rule for events from a trusted source IP:

title: Filter trusted AWS console login
id: 12f93b6e-3123-4c81-b411-769701b9b38a
description: Suppress approved console logins from the corporate egress IP.
logsource:
  product: aws
  service: cloudtrail
filter:
  rules:
    - 14701da0-4b0f-4ee6-9c95-2ffb4e73bb9a
  selection:
    sourceIPAddress: 203.0.113.10
  condition: selection

Replace the example IP address and target ID with values from your environment.

The main fields are:

Field	Required in AlphaSOC	Description
title	Yes	A short, descriptive name for the filter.
id	Yes	A unique UUID. The console generates it in the new-filter template; keep it in the document.
description	No	The reason for the filter and any context future maintainers need.
logsource	Yes	The events to which the filter applies. Use a log source compatible with the targeted Sigma rules.
filter.rules	Yes	One or more Sigma rule id or name values.
filter.selection	Yes	The field values that identify events to suppress.
filter.condition	Yes	The expression AlphaSOC evaluates. When it evaluates to true, AlphaSOC suppresses the listed Sigma rules.

The rules list must contain unique values and can contain up to 100 targets. Selections and conditions support the same fields and modifiers as Sigma detection logic. See Supported Attributes for compatibility details. You can also use AlphaSOC's OCSF and Wisdom field formats in filters.

note

AlphaSOC suppresses a target when filter.condition evaluates to true. In the example above, condition: selection suppresses events from the selected IP. If you use a negated expression such as condition: not selection, AlphaSOC suppresses every applicable event that does not match the selection.

Create and manage filters

You can create, edit, enable, disable, and delete filters from the Detections page in the AlphaSOC console. You can also deploy filters programmatically through the detection management API, including as part of a Detection-as-Code pipeline.

Workspace Users and Owners can manage Sigma filters. Guests can view them but cannot make changes.