Overview

Xpernix ships with hundreds of pre-built detection rules mapped to MITRE ATT&CK. But every environment is different — a rule that fires on every failed login makes sense for some orgs and creates noise for others. This guide explains how to create and tune rules for your specific context.

Understanding the Rule Library

Navigate to Detections → Rules. Each rule shows:

Name and MITRE tactic/technique mapping
Severity (Critical / High / Medium / Low / Informational)
Source (Xpernix-managed vs. custom)
Hit rate (alerts per day over the last 7 days)
Status (Active / Paused / Backtest)

Xpernix-managed rules are updated automatically when new threat intelligence is available. You can’t edit them directly, but you can clone them to create a customized copy.

Step 1: Clone or Create a Rule

Clone an existing rule

Find a rule close to what you need, click the ⋮ menu → Clone. The cloned rule will be prefixed with [Custom] and is fully editable.

Create a new rule

Click + New Rule. Fill in:

Name — descriptive, e.g. Brute force on VPN - > 10 failures/5min
Description — what the rule detects and why it matters
MITRE mapping — optional but recommended for reporting
Severity — be conservative; you can always escalate later

Step 2: Write the Rule Logic

Our rule engine uses a SQL-like syntax. Example — detect 10+ failed logins from the same IP within 5 minutes:

SELECT
  source_ip,
  COUNT(*) AS attempt_count
FROM events
WHERE
  event_type = 'authentication_failure'
  AND timeframe = '5m'
GROUP BY source_ip
HAVING attempt_count >= 10

Key normalized fields

Field	Description
`event_type`	Normalized event category
`source_ip`	Originating IP address
`dest_ip`	Destination IP
`user`	Username or UPN
`host`	Source hostname
`action`	`allow`, `deny`, `block`
`severity`	Original source severity
`geo.country`	GeoIP country code

Use the Field Reference panel (right side of the editor) to browse all available fields for your connected sources.

Step 3: Add Exceptions (Allowlist)

Almost every rule needs exceptions to reduce false positives. Common patterns:

AND source_ip NOT IN ('10.0.0.0/8', '192.168.0.0/16')
AND user NOT IN ('svc-backup', 'monitoring-agent')

You can also reference dynamic lists — IP allowlists, known-good asset lists — that your team manages in Settings → Reference Lists.

Step 4: Set Threshold and Suppression

Setting	Description
Threshold	Minimum match count before alert fires
Time window	Rolling window to count events in
Suppression	Don’t re-alert on the same entity for N minutes
Group by	Field to group events by (e.g. `source_ip`)

For high-volume rules, always set a suppression window (e.g. 60 minutes) to avoid alert storms.

Step 5: Backtest Before Enabling

Click Backtest to run the rule against the last 30 days of your log data without generating live alerts.

Review:

Match count per day — is this rule too noisy?
Sample matches — are these genuine true positives?
False positive rate — adjust thresholds until you’re satisfied

Once happy, click Enable. The rule will go live within 60 seconds.

Rule Tuning Best Practices

Start broad, tune narrow — enable a rule, watch it for a week, then add exceptions based on real FPs
Use reference lists for dynamic allowlists rather than hardcoding values
Group similar rules using tags so you can pause/enable them in bulk
Monitor hit rates weekly — a rule that never fires might be misconfigured; one firing 1000x/day needs tuning
Review Xpernix-managed rule updates monthly via the changelog in the portal

Getting Help

Your Xpernix detection engineer reviews all custom rules on request. Open a ticket in your portal or ask in your dedicated Slack channel.

How to Configure Custom Alert Rules