Detection rules and suppressions

Detection rules say which events to look at and what makes a detection. Tenvara ships a pack of built-in rules and runs them every few minutes over every customer's events.

The rules list#

Security > Rules opens the Detection rules page. Three tabs sit under the heading: Rules, Suppressions and Coverage (the MITRE ATT&CK matrix: see Threat intelligence and MITRE coverage).

The Rules tab lists every rule with its Severity, Source, Hits this week, Open detections, its Noise, Last run and an On switch. Filter by severity, source, category, what it looks for, MITRE tactic, on or off, and built-in or your own. The Noisiest view in Views sorts the rules that cry wolf most to the top.

The built-in pack covers:

• Windows: brute force, brute force then a logon, password spray, lockouts, Kerberos and NTLM failures, logons from the internet, remote desktop from a new address, privileged group additions, accounts created, logs cleared, sensitive changes out of hours, audit policy, services and PsExec-style services, scheduled tasks, Defender malware and tampering, suspicious PowerShell scripts and command lines, Office starting a shell, firewall off.
• macOS: sudo failures, sudo failures then a new admin, admin added, accounts, XProtect, Gatekeeper overrides, firewall off.
• Linux and SSH: SSH brute force, root over SSH, sudo failures, sudo, wheel and adm additions, accounts.
• Microsoft 365: brute force, password spray, failures then a sign-in, sign-in from a new country, legacy authentication, MFA prompts not completed, Entra ID Protection risk, forwarding inbox rules, mailbox forwarding, inbox rules, mailbox permissions, admin roles, MFA methods removed and registered, app consent, app credentials, Conditional Access changes, guests, mass download.
• Network devices: bursts of IPS alerts, severe IPS alerts, port scans, VPN brute force, admin logon failures.
• Tenvara itself: sign-in failures, many credentials revealed by one person, two-factor resets and role changes.

The Suspicious PowerShell script rule scores each script rather than matching single words. It counts real indicators, weighs where the script came from (its folder, who signed it, what started it and how many devices run it), scores the whole script and knows the scripts common vendors ship. Scripts a tool runs routinely can be put on a known tools list: see Working detections. "Internet address" in rule names means a public address only, so link-local and carrier-grade NAT ranges never count, and routine XProtect scans on Macs are not reported as malware.

When a pack update changes what a built-in rule matches, its open detections are judged again against the new version, and the ones that no longer match close by themselves.

Kinds of rule#

A rule's page#

Click a rule to see Why it matters, What it looks for (in words, or as YAML), its recent detections, the Runs (each window it looked at, with customers, hits, detections opened and merged, held back and how long it took), its details, which customers it works differently for, and its Versions.

Built-in rules cannot be edited in place. You can switch them off, tune them per customer, test them, or copy them with Copy to a rule of your own.

Tuning a rule for one customer#

When a rule is too noisy (or too quiet) for one customer:

1. Open the rule and press Tune for a customer.
2. Choose the Customer.
3. Set a Threshold of their own (leave empty to use the rule's), a Severity of their own, or Mute it for a day, a week, 30 days or until a date.
4. Add a Note saying why this customer is different.
5. Press Save.

Only that customer changes, and a pack update never touches it.

Testing a rule#

Press Test on a rule to run it as it stands over past events (the Test panel beside the rule form): the last hour, 24 hours, 7 days or 30 days, for every customer or one. It shows how many detections it would have made and what they are. Nothing is recorded and no alerts are raised.

Writing your own rule#

1. Press New rule (or Copy to a rule of your own on an existing one).
2. Under About the rule, give it a Title and Key, the Severity, Category, Source, MITRE ATT&CK tactic and technique, a one-sentence Description, and Why it matters (shown to technicians with every detection).
3. Under Which events, add conditions. Every condition must hold; add an "any of" group for alternatives.
4. Under What makes a detection, choose what it looks for, what to Group by (a user, host or address; every rule also groups by customer), the count, and what each detection is About.
5. Under When it runs, set how often, how far it looks back, and how long it waits for late events.
6. Use the Test panel beside the form to see what it would have found, then press Save rule.

You can switch between Form and YAML at any time, and paste a rule as YAML. The editor checks the rule as you type. A copy of a rule starts switched off. Every saved change is a new version, with what changed in words.

Rule noise and automatic lowering#

Every closed detection records how it ended (actioned, false positive, expected or harmless, our own work or vendor routine). The Noise column shows each rule's detections in the last 30 days, the share that were noise, and how many of its tickets nobody answered. Opened for one customer, the figures are that customer's.

When a rule has had at least 10 detections for one customer in 30 days and 80% or more of them were noise, it is lowered one severity step for that customer, never below Low, and stays lowered. The rule's noise then shows Lowered for and how many customers, with Undo for each. The security overview splits the week's false positives by rule.

Every built-in rule also states the most it may be and why, so Critical means something is broken or under attack now.

Rules switched off for failing#

A rule that fails five runs in a row (Switch a rule off after, on the Alerting tab of Settings > Security monitoring) is switched off with an alert that gives the error. The people who work security detections are told at once, or everyone who manages security when nobody has that work.

• Try again on the alert tests the rule over its latest window straight away. If it passes, the rule is switched back on and the alert resolves; if not, the error is shown and it stays off.
• Tenvara also tries every rule switched off for failing once an hour, and switches it back on by itself when a try passes, telling the same people.
• Until it is back on, the rule counts as a gap on the Coverage tab, in red, with its error.

A rule someone switched off by hand is never tried again.

Suppressions#

A suppression holds back hits that match it: they are counted, but do not become detections. Most come from marking a detection a false positive with Do not show hits like this again.

Go to Security > Rules and open the Suppressions tab. It lists them with the Reason, the conditions (When), the Rule, how many hits each Held back and when it Expires. Filter by rule, customer, expiry and whether it is active. Press New suppression to add one by hand:

1. Enter a reason.
2. Add conditions on the values a hit carries: the fields the rule groups by, the customer and device, or any field its events carry, such as a scheduled task's name, a service's program, an IDS signature or an app id. All must hold.
3. Optionally limit it to one rule and one customer.
4. Set when it expires.

A suppression on an event field holds back a hit only when every one of the hit's events fits it, so one noisy task can be quietened without hiding the whole device. A condition on a field a hit does not carry never matches, so a suppression written for one rule cannot silence another by accident.