Sigma Streaming

RunReveal also offers Sigma streaming detections that can be checked while the event is being processed in the pipeline.

How it works

A Sigma detection consists of a yaml file that lists metadata about the detection and the detection rule that will be matched against events.

A user will upload a Sigma detection yaml file with at least a title and a detection. Sigma yaml can also contain additional context for the detection that will be saved when the detection matches.
When an event is ingested we check if the Sigma detection is setup to run for this source.
If it is, we run the event's raw log and any defined enrichments through our Sigma processor to look for a match.
If the Sigma rule matches, we check if the rule supplies any notification channels to alert to and then the event is inserted into your detections table in Clickhouse.

Building Sigma detections in the UI

You don't have to hand-write YAML to create a Sigma detection. When you create or edit a Sigma detection in the app (Detections → Create Detection → Streaming Detection), RunReveal presents a form-based builder:

Detection configuration — name, description, and enabled state.
Source scoping — logsource category/product/service plus the sourcetypes and sourcenames lists that control which events the rule runs on.
Detection logic — add named selection blocks (field matches, keyword lists, or an "Advanced YAML" block for anything the visual editor can't represent), then combine them in the condition (for example, 'selection and not filter').
Notifications — notification channels, template, and auto-investigation settings.
Detection metadata — severity, risk score, categories, MITRE tactics/techniques, important fields, and notes.
Extra Sigma fields — a key/value editor for any other top-level Sigma keys (such as author, references, or status) that the form doesn't manage directly. These are preserved verbatim in the saved rule.

Use Upload Sigma YAML to import an existing rule into the form, Validate Rule to check it against the Sigma engine (and optionally recent events), and Preview YAML to see the exact rule that will be saved. Behind the scenes the builder marshals your inputs into the same Sigma YAML described below, so anything you can express in YAML is still supported.

If a block uses Sigma features the visual editor can't model (mixed lists, nested maps, or list-of-conditions), the builder automatically falls back to an editable YAML view for just that piece so no detail is lost.

Detections managed by detection as code (createdFrom: cli) remain view-only in the UI and are edited through runreveal detection sync.

Sigma Rules

RunReveal supports standard Sigma rule properties along with additional fields that help provide more context to the detection. At its most basic level a Sigma detection requires a title which is a unique descriptor to tell your detections apart, and a detection block which contains the rules that are checked.

Sources

If a Sigma rule only contains the required fields, your detection will be uploaded but won't run on any events unless a source is also defined in the yaml.

Sigma allows you to define a source using the logsource property.

logsource:
  category: cloud
  product: aws
  service: cloudtrail

RunReveal uses this field and checks all of the child properties to match them to a RunReveal source type. If one of these properties matches a source type, e.g. the service field matches our cloudtrail source type, then all events ingested with the cloudtrail source type will be checked.

We also offer two extra fields to specify which sources this rule applies to sourcenames and sourcetypes.

sourcenames is a string array where you can list the unique names of your sources that you want this rule to evaluate on. This is useful if you have multiple sources with the same type (like a cloudtrail source for different environments) but only want a detection to run for your 'prod-cloudtrail' source. sourcenames corresponds to the Name: listed in the source tile and on the edit source page.

sigma-docs-1

sourcetypes is also a string array where you can list multiple source types that the detection should match against. This can be useful if you want the same detection rule to match on different source types. sourcetypes corresponds to the Type: listed in the source tile.

sigma-docs-2

Sigma provided fields

Sigma rules have a few fields that RunReveal uses to provide some extra context to the detection.

description is used to provide a text description on what the detection does.

level is used to give a detection a severity, RunReveal uses low, medium, high, and critical levels.

tags are stored with a matched detection in the RunReveal category field. They can be used to help group detections.

fields is a list of event field names to emphasize for the detection. When the rule matches, these fields are extracted from the event and surfaced as context on the alert (and are available to notification templates).

Extra RunReveal fields

RunReveal also provides additional fields for the Sigma rule to provide additional context or control the detection. Use the field names exactly as written below.

Sigma Field	Field Description
disabled	If set to `true` the detection will be listed in your account but will not be checked with incoming events.
notes	Additional notes about your detection to give additional context.
categories	An array of strings used to group detections, stored in the RunReveal category field. An alternative to `tags`; if both are set, `categories` takes precedence.
riskScore	A score that can be assigned to a detection that can be used when performing signal chaining.
mitreAttacks	A list of MITRE ATT&CK tactic IDs (e.g., TA0001) that this detection checks. This can be used when identifying attack patterns.
mitreTechniques	A list of MITRE ATT&CK technique IDs (`T####` or `T####.###` for sub-techniques, e.g. T1078.004). Complements `mitreAttacks` for deeper attack-pattern context.
notificationNames	An array of notification channel names in your RunReveal workspace, if set and the detection triggers, an alert will be sent to the notifications listed.
notificationTemplate	The name of a notification template in your workspace to use when this detection alerts, overriding the channel's default template. The template must already exist in your workspace.
autoInvestigate	When set to `true`, RunReveal automatically creates an investigation when this detection fires. Case-sensitive.
autoTriage	When set to `true`, RunReveal automatically creates an investigation and runs the AI triage agent when this detection fires. Case-sensitive.
agentConfigIdOrName	Optional. The agent to use for triage when `autoTriage` is true. Can be the agent config ID, name (slug), or display name. Omit or leave empty for the default triage agent. Case-sensitive.

Example Rule

Copy the rule below and paste it into Detections → Create Detection (Sigma). It uses a single source type (okta) so Validate with recent events is more likely to complete without timing out. If your workspace has Okta events, you can run validation in the UI; otherwise use runreveal lint sigma <file> to check syntax.

title: Okta Failed Sign-In
description: Detects failed Okta sign-in events (user.session.start with outcome FAILURE).
logsource:
  product: okta
 
detection:
  filter:
    eventType: user.session.start
    outcome.result: FAILURE
  condition: filter
 
level: medium
riskScore: 50
mitreAttacks:
  - TA0001
mitreTechniques:
  - T1078.004
disabled: false

YAML schema

To learn more about writing detections using the Sigma schema check out the Sigma docs.

To learn more about the open source library RunReveal uses to parse Sigma rules, check out the SigmaLite repo.

The following can be copied into a blank file to start creating your own Sigma detections. It validates with runreveal lint sigma <file>.

# Required: A unique title of the detection to identify it.
title: The detection title
 
# Required: The detection that will be matched against the incoming events.
# In this scenario the detection will check the event for the text `runreveal.com`
detection:
  keywords:
    - runreveal.com
  condition: keywords
 
# Optional: Set to true to turn off this detection.
disabled: false
 
# Optional: A description of the detection.
description: A description of the detection and what it is doing.
 
# Optional: An array of strings to help group queries
tags:
  - tag1
  - tag2
 
# Optional: A severity string to identify the importance of the detection results.
# low, medium, high, critical
level: low
 
# Optional: An integer score to give the detection.
riskScore: 40
 
# Optional: Additional notes that can be attached to the detection.
notes: |-
  Extra info about the detection.
 
# Optional: An array of MITRE tactics IDs framework classifications.
# This is useful when identifying attack patterns.
mitreAttacks:
  - TA0005  # (evasion)
  - TA0001  # (initial-access)
 
# Optional: An array of MITRE technique IDs (T#### or T####.### for sub-techniques).
# This is useful to understand attack patterns in depth, when combined with the MITRE Tactics.
mitreTechniques:
  - T1543.001   # (Create or Modify System Process: Launch Agent)
  - T1134.001   # (Access Token Manipulation: Token Impersonation/Theft)
  - T1134.002   # (Access Token Manipulation: Create Process with Token)
 
# Optional: A list of event fields to emphasize on the alert. When the rule matches,
# these are extracted from the event and made available as context (and to templates).
fields:
  - actor.email
  - srcIP
 
# Optional: An array of notification channel names that should receive an alert if this detection triggers
notificationNames:
  - email
 
# Optional: The name of a notification template in your workspace to use when this
# detection alerts, overriding the channel's default template. Must already exist.
notificationTemplate: my-template
 
# Optional: When true, automatically create an investigation when this detection fires.
autoInvestigate: false
 
# Optional: When true, automatically create an investigation and run the AI triage agent when this detection fires.
# Use exactly "autoTriage" and "agentConfigIdOrName" (case-sensitive).
autoTriage: false
 
# Optional: Agent for triage when autoTriage is true (ID, name, or display name). Omit for default.
agentConfigIdOrName: ""
 
## logsource, sourcetypes, and sourcenames are all optional, but in order for the detection to be associated with specific events 
## one of them needs to be filled in with a source that your workspace uses.
# If the source type of the event matches on of the logsource fields, this detection will be checked.
logsource:
  category: cloud
  product: aws
  service: cloudtrail
 
# An array of source types, if the source type of any event matches one in this list the detection will be checked. 
sourcetypes:
  - okta
  - cloudtrail
 
# An array of source names, if the source name the event was generated from matches an item in this list the detection will be checked.
sourcenames:
  - runreveal-okta

Now that you understand Sigma streaming detections, explore these related guides:

Detections, Signals & Alerts Quick Start Guide - Complete setup guide for your detection workflow
How to Write Detections - Tips and tricks to write effective detections
Detection as Code - Manage detections through code and version control
Test/Upload Detections - Learn how to test and deploy your Sigma detections

On this page