Sigma Correlations in AlphaSOC

A single "PowerShell base64 payload" detection is noisy and usually benign. Combine it with a new outbound connection to a low-prevalence domain within five minutes and your false-positive rate drops significantly. AlphaSOC now supports Sigma Correlations: the ability to link multiple rule matches over a defined time window and produce a single, high-confidence OCSF detection finding for multi-stage attack patterns that individual rules cannot catch.

Why Individual Rules Fall Short

Standard Sigma rules match against a single event. That is their strength for precision, and their limitation for coverage. Modern attack patterns unfold across multiple steps: a credential access technique followed by lateral movement, a file access followed by compression followed by an upload. Each step in isolation looks unremarkable. The pattern is what matters.

Correlations address this directly. Instead of asking "did this event happen?", a correlation asks "did this sequence or volume of events happen, for the same entity, within this time window?" The result is a finding with meaningfully higher confidence than any of the constituent rule matches.

How Correlations Work in AlphaSOC

A Sigma correlation is defined alongside its base rules in a single YAML file. The correlation block specifies four things: the type of aggregation, which rules to aggregate, the fields to group by, and the condition that must be met for the correlation to fire.

title: Multiple Cmdkey.EXE Executions Indicating Cached Credential Reconnaissance
id: 921f3b51-4ef9-4ca3-82e5-b4b7805d0ba4
name: windows_cmdkey_recon_multiple
status: test
description: |
  Detects multiple executions of cmdkey.exe listing cached credentials
  by the same user within a short period, which may indicate credential
  reconnaissance or automated discovery activity.
correlation:
  type: event_count
  rules:
    - windows_cmdkey_recon
  group-by:
    - User
  timespan: 10m
  condition:
    gte: 5
tags:
  - attack.credential-access
  - attack.t1003.005
level: high

This correlation references a base rule (windows_cmdkey_recon) that detects a single execution of cmdkey.exe /list. On its own that rule fires at level: low and generates significant noise. The correlation promotes it: five or more executions by the same user within ten minutes produces a level: high finding mapped to MITRE ATT&CK T1003.005 (Cached Domain Credentials). A finding that would have been lost in low-severity noise becomes a prioritised investigation item.

The base rule and the correlation are uploaded together to AlphaSOC via the console or the Detection Management API. AlphaSOC handles the aggregation in real time as telemetry flows through the pipeline.

Supported Correlation Types

AlphaSOC supports five of the correlation types defined in the Sigma specification:

Type	What it measures	Example use case
event_count	Number of matching events within the timespan	Multiple failed logins, repeated recon commands
value_count	Number of distinct values in a field	Unique repositories cloned, unique destinations contacted
value_sum	Sum of a numeric field	Total bytes transferred over SSH
value_avg	Average of a numeric field	Average outbound traffic per source IP
temporal	Multiple distinct event types occurring together	IAM user created followed by access key creation

value_percentile and ordered_temporal are not currently supported.

Each type accepts the standard comparison operators (gt, gte, eq, neq). The value_avg type additionally supports lt and lte, which are not available for other types given AlphaSOC's real-time architecture.

Detection Patterns

Brute-force and credential access

The event_count type is the natural fit for volume-based attacks. The AWS console login example below fires at level: medium when a single IAM identity accumulates five or more failed authentication attempts within ten minutes, mapped to MITRE ATT&CK T1110 (Brute Force):

title: Several unsuccessful AWS console login attempts for a user
id: 0b1cdcb9-8170-4c5e-983c-32e2831940b5
name: aws_console_login_failure_user
status: stable
correlation:
  type: event_count
  rules:
    - aws_console_login_failure
  group-by:
    - userIdentity.arn
  timespan: 10m
  condition:
    gte: 5
tags:
  - attack.credential-access
  - attack.t1110
level: medium

Reconnaissance and unusual access patterns

The value_count type detects anomalies involving many unique occurrences of a field value. This rule fires when a single actor clones five or more distinct GitHub repositories within an hour, a pattern consistent with insider data harvesting or compromised developer credentials:

title: High number of GitHub repositories cloned
id: 50509146-108a-4f4d-b503-40d8ed07acff
status: test
correlation:
  type: value_count
  rules:
    - b4354cde-0ced-44a7-a653-88639da38ca8
  group-by:
    - actor_id
  timespan: 1h
  condition:
    field: repository_id
    gte: 5
level: high

Data exfiltration over legitimate channels

The value_sum type aggregates numeric field values, making it effective for detecting data volume thresholds. This rule fires when outbound SSH traffic from a single source IP exceeds one megabyte within an hour, a threshold that separates normal interactive sessions from bulk data movement:

title: High volume of outbound traffic over SSH
id: e0f7d63f-3d1a-4595-ac95-c774e201b54d
name: high_volume_ssh
status: stable
correlation:
  type: value_sum
  rules:
    - ssh_outbound
  group-by:
    - src_ip
  timespan: 1h
  condition:
    field: bytes_out
    gt: 1000000
level: medium

Multi-stage cloud attacks

The temporal type detects sequences: multiple distinct event types occurring within a window, grouped by a shared entity. This rule fires when an IAM user creation and an access key creation are observed for the same username within twelve hours, a pattern used by threat actors to establish persistent access after initial compromise:

title: AWS access key created for a newly registered IAM user
id: 3269cacb-2a8e-41c6-bd3e-e6dc957c4e3b
status: stable
correlation:
  type: temporal
  rules:
    - aws_iam_user_created
    - aws_access_key_created
  group-by:
    - requestParameters.userName
  timespan: 12h
level: low

MITRE ATT&CK Mapping and Custom Names

Correlations support the same optional tags field as standard Sigma rules. MITRE ATT&CK tags follow the standard Sigma naming convention (attack.t1234 or attack.tactic-name). You can also set a name field to give the correlation a human-readable identifier that surfaces in the OCSF finding, making findings descriptive in downstream tooling without requiring analysts to cross-reference rule IDs.

Adding Correlations to AlphaSOC

Correlations are uploaded via the AlphaSOC console under Rule Management > Sigma Rules, or via the Detection Management API. The base rule and the correlation rule must be uploaded together in the same YAML file, separated by ---. AlphaSOC validates the correlation structure on upload and will reject rules that reference base rules not present in the submission.

For the full field reference, supported operators per correlation type, and current limitations, refer to the Sigma Correlations documentation.

Detection Coverage This Enables

Individual Sigma rules give you breadth. Correlations give you depth on the patterns that matter most: repeated low-level activity that resolves into a high-confidence finding, sequential steps across cloud APIs that reveal account takeover, data volumes that cross thresholds no single event could expose.

The PowerShell example in the introduction is a direct application of temporal correlation: a base rule matches the encoded command, a second rule matches the outbound connection, and the correlation links them by source host within a five-minute window. Neither finding alone justifies escalation. Together they do.

The Sigma community repository contains thousands of rules across Windows, macOS, Linux, cloud platforms, and applications. Correlations extend that coverage to the multi-event patterns that detection engineers have historically had to express in SIEM query language, outside version control, and outside the standard rules ecosystem.