UTMStack v12 includes a library of 721 built-in detection rules that watch your logs for threats, suspicious activity and risky changes. The rules run in the UTMStack correlation engine and map to the MITRE ATT&CK framework (a public catalogue of attacker tactics and techniques).

What are detection rules?

A detection rule is a YAML file that describes a pattern of malicious or suspicious activity in one kind of log. When an incoming event matches the rule's conditions, UTMStack creates an alert with a severity, a MITRE ATT&CK classification and recommended next steps.

Each rule includes:

• Name: a short title that describes what the rule detects. It also becomes the alert name.

• Description: the threat scenario and why it matters, usually followed by "Next Steps" for the analyst.

• Data types: the kind of events the rule examines, for example wineventlog for Windows events. A rule only looks at events of its data types.

• Category: the MITRE ATT&CK tactic, for example Credential Access or Lateral Movement.

• Technique: the MITRE ATT&CK technique ID and name.

• Impact: a Confidentiality / Integrity / Availability score. Each value goes from 0 to 3.

• Adversary: which side of the event is treated as the attacker, the origin or the target.

• Detection logic: the condition that an event must meet. Some rules also count earlier matching events (for example "10 failed sign-ins from the same address in 10 minutes"), and many rules group repeated alerts or drop duplicates.

• References: links to MITRE ATT&CK entries and vendor documentation.

How severity is set

The rule files have no severity field. UTMStack takes the highest of the three impact values:

Of the 721 built-in rules, 644 produce high, 57 medium and 20 low severity alerts.

You can also tell UTMStack how important a host is: on the Data Sources page, open a data source and set its Asset sensitivity (Confidentiality, Integrity and Availability). When an alert's target host or address matches that data source's name or IP address, each of the rule's impact values that is not 0 is replaced by the rounded average of the rule's value and the data source's value, and never more than the data source's value. The highest result then sets the severity, so the same rule can give a different severity on that host. SOC-AI also uses these values in the risk score it writes on alerts it assesses. See Data Sources Page and SOC-AI Assistant.

How to read a catalogue page

Each page in this section covers one source and has the same parts:

How to read the values:

• Impact (C/I/A), for example C:3 / I:2 / A:1, are the confidentiality, integrity and availability values from 0 to 3. The highest one sets the alert severity (table above): C:3 / I:2 / A:1 gives a high-severity alert.

• Category can list several tactics, separated by commas.

• The rule name is exactly what you see on Threat Management > Alerts, and what you type in a response flow trigger or a tagging rule. Names are case-sensitive there.

• The rule file link opens the rule as it is in the UTMStack repository for version 12. To see the file exactly as it runs on your server, export it from Configure > Alerting Rules (see Alerting Rules).

Supported data sources

Rules are organized by the data source they apply to. Each page in this section lists every rule for one source, with its MITRE ATT&CK mapping, impact and a link to the rule file.

What changed since v11

• New source: Microsoft 365 through Microsoft Graph, with 20 rules.

• More rules: Linux has 21 more rules, Windows 8 more and Office 365 2 more.

• Removed: one macOS rule, "Keychain Credential Dumping via CLI".

• Updated rule bodies: most rules were rewritten for the v12 event fields. Vendor-specific fields are now read as log.<field>; v11 rules used event.<field>. If you bring your own rules from v11, check their field names before you import them.

How rules work

1. Log ingestion: UTMStack receives logs from agents, the UTMStack Collector and cloud integrations.

2. Parsing: pipelines turn each raw log into the UTMStack standard event fields (Configure > Pipelines).

3. Correlation: the correlation engine checks each event against every active rule for the event's data type.

4. Alert generation: when a rule's conditions are met, UTMStack creates an alert with full context. Rules that group alerts add repeats to the first alert instead of creating new ones, and rules that drop duplicates ignore a repeat for 7 days.

5. Response: alerts appear in Threat Management > Alerts. An alert can also start a response flow in SOAR when it matches the flow's trigger conditions.

Where to see and switch rules

All rules, built-in and your own, are listed in Configure > Alerting Rules. The Configure menu is shown to users with the Administrator role.

• The list shows the rule name (a lock marks built-in rules), data types, category, technique, adversary, impact and an Active switch. You can search by name and filter by category, adversary, state (Active or Inactive), owner (System or Custom) and data type.

• To see the rules for one integration, open Configure > Integrations, open the integration's card and click Rules. Alerting Rules opens filtered to that data type.

• Built-in rules cannot be edited or deleted, but you can switch them off. They are updated with each UTMStack release, and your on and off choices are kept. See Shipped and Custom Rules and Pipelines.

Switch a rule on or off for your tenant

All built-in rules are on when UTMStack is installed, and every tenant starts with all of them on.

1. 1

   Find the rule

   On Configure > Alerting Rules, type part of the name in Search rules…, or pick its data type in All data types.

2. 2

   Use the Active switch

   Turn the Active switch in the rule's row off or on. You can also open the rule and use the switch in its panel. The page confirms "Rule deactivated" or "Rule activated".

3. 3

   Check

   Choose Inactive in All states to list every rule switched off in your tenant. The change reaches the engine within about a minute.

What to know:

• The switch applies to your tenant only. On a multi-tenant installation, each tenant has its own switches, and switching a rule off in one tenant does not affect the others.

• Switching a rule needs the eventprocessing.write permission, which only the Administrator role has by default.

• The rule flood guard uses the same switch: a rule it switched off shows as Inactive, and you switch it back on the same way (see below).

• On a multi-tenant installation, the instance operator can switch a built-in rule on or off in many tenants at once with Apply to all tenants in the rule panel. See Apply to All Tenants.

• Programs can do the same with PUT /api/v1/eventprocessing/correlation-rule/activate-deactivate. See Rules and Pipelines API.

Before you switch off a rule because it is noisy, consider tuning it instead: see Tuning Rules and Reducing False Positives.

Rule flood guard

The rule flood guard protects you from alert floods. When one rule creates too many alerts, UTMStack switches that rule off automatically and tells you.

How it decides:

• Every 5 minutes it counts, for each tenant, rule name and data source, the alerts of the last 24 hours that are Open, are not grouped under another alert, and are not tagged False positive.

• When one count is more than 50, the rule is switched off for that tenant only. Other tenants keep it. If several rules share that name (capital and small letters are treated as the same), all of them are switched off.

• The tenant gets a warning in the notification bell. No email is sent. The message names the rule, the number of alerts and the data source, and suggests what to do.

1. 1

   Find the cause

   Open Threat Management > Alerts and look at the alerts of the rule named in the notification. Decide whether the alerts are real activity or expected, harmless activity.

2. 2

   Close or tag the flood

   Close the alerts you have reviewed, or mark expected ones as False positive. A tagging rule (Threat Management > Tagging Rules) can do this automatically for future alerts. Completed alerts and alerts tagged False positive are not counted.

3. 3

   Reduce repeats (custom rules)

   If the rule is one of your own, add groupBy or deduplicateBy fields so that repeats of the same activity are grouped or dropped. Built-in rules cannot be edited.

4. 4

   Switch the rule back on

   Open Configure > Alerting Rules, find the rule and turn its Active switch on.

plugins:
  rule-flood-guard:
    enabled: true
    threshold: 50
    windowHours: 24
    intervalSeconds: 300

See Rule Flood Guard for more detail.

Rule source code

All built-in detection rules are open source and available in the UTMStack GitHub repository:

github.com/utmstack/UTMStack/tree/v12/definitions/rules

Browse the pages in this section to see every rule organized by source, with descriptions, MITRE ATT&CK mappings, impact scores and links to the YAML files.

Creating custom rules

You can write your own rules in Configure > Alerting Rules with New rule, or import YAML files with Import. Custom rules belong to your tenant. For the rule format, the condition functions and how to test a rule before you rely on it, see Alerting Rules, Rule File Format, Condition Functions Reference and Testing Pipelines and Rules. Rule Examples has complete rules to copy, and Pipeline Examples shows how to produce the fields a rule reads.