synoti logosynoti logo
Configuration & Implementation Implementing Rules

Implementing Rules

This is a fresh page. Begin editing to insert your content.

Rule Definition Reference

YAML objects known as rules establish what counts as a security threat. They are handled by the Analysis engine.

FieldTypeDescription
iduint32Unique ID for the rule.
namestringName that is human-readable (the Alert Title).
descriptionstringIn-depth description of the threat.
categorystringThe category of the threat (for example, Malware, System Integrity).
techniquestringTechnique from MITRE ATT&CK (such as T1059.003).
references[]stringCollection of external URLs that provide more context.
dataTypes[]stringCatalog of event types (for example, syslog, wineventlog, linux).
adversarystringIn the standard schema, which side stands for the attacker (origin or target). The default is origin.
impactobjectMapping for confidentiality, integrity, and availability (0-3).
wherestringCEL Expression. The main condition that triggers.
correlation[]objectCorrelation logic. Sets the historical searches to run when where is true.
deduplicateBy[]stringFields that suppress similar alerts. When matches persist inside the window, no new alert is generated.
groupBy[]stringFields that establish alert parents. When a similar alert is present, new alerts are attached as children.

Triggers vs. Correlation

1. Basic Analysis (Trigger)

If your rule only has a where clause, it qualifies as a simple rule. Each time an event matches the condition, an alert is produced.

  • Example: Identify any sign-in by a Restricted User.

    where: 'equals("origin.user", "admin_backup")'

2. Correlation (correlation)

Correlation rules examine past data to identify patterns spanning multiple events. If where matches, the engine searches the historical database (OpenSearch).

  • Logic: The alert is ONLY created if the count of found events matches the threshold within the within window.

  • indexPattern: Usually v1-7-22-log-* for events.

  • with: Specifies the search filters. You may use values from the triggering event using {{.path}}.

Impact and Severity

The Impact Score of an alert is calculated as the maximum value across its three CIA components (Confidentiality, Integrity, and Availability). This score then dictates the alert's Severity:

Impact Score (Max of CIA)Severity
0Information
1Low
2Medium
3High

Advanced Example: Brute Force Success

Identifies a successful login after 5 or more failures from the same IP within the past 12 hours.

- id: 1001
  name: "Brute Force Success"
  description: "A successful login was preceded by multiple failures from the same source IP."
  dataTypes: [syslog, wineventlog, linux]
  adversary: origin
  impact:
    confidentiality: 3
    integrity: 3
    availability: 0
  
  # Trigger: A SUCCESSFUL login
  where: 'equals("action", "login") && equals("actionResult", "success")'

  # Correlation: Find FAILURES from the same address
  correlation:
    - indexPattern: v1.7.22-log-*
      within: now-12h
      count: 5
      with:
        - field: origin.ip.keyword
          operator: filter_term
          value: '{{.origin.ip}}' # Use the IP from the success event
        - field: actionResult.keyword
          operator: filter_term
          value: 'failure'

  deduplicateBy: [adversary.ip, adversary.user]

correlation Operators

These operators define how historical searches are performed in OpenSearch:

These operators define how historical searches are performed in OpenSearch:

  • filter_term: Exact match (Case-sensitive).

    • Uses an OpenSearch term query.

    • Recommended for keyword, ip, or numeric fields.

    • If used on a text field, the engine automatically attempts to use its .keyword sub-field to guarantee an exact match.

  • filter_match: Full-text search (Case-insensitive).

    • Uses an OpenSearch match query.

    • Recommended for text fields in which you want to locate words without regard to case.

    • If used on a keyword field, the engine automatically converts it to a term query for efficiency.

  • must_not_term: Exclude exact match. The inverse of filter_term.

  • must_not_match: Exclude full-text match. The inverse of filter_match.

For more CEL functions, see the CEL Overloads Guide.