Detection Rules

Overview

Detection rules are the logic that powers Fencer’s SIEM. Each rule runs against your ingested security events on a schedule. When a rule matches, it creates a detection with a severity level, confidence score, and actionable recommendations. Fencer ships built-in rules for AWS, GCP, GitHub, 1Password, Google Workspace, Cloudflare, and DigitalOcean. You can tune them for your environment, and import your own Sigma rules from a Git repository.

Note

Detection rules are part of the Security Monitoring (SIEM) paid feature. You need an active subscription with the SIEM entitlement to access them.

Prerequisites

• Security Monitoring enabled for your organization.
• At least one monitoring data source connected and ingesting events (for example AWS CloudTrail, GCP Cloud Audit Logs, GitHub, or 1Password).
• To enable or disable rules and edit their variables: the detections:edit ability, which the built-in Administrator role has.
• To manage global variables and external rule sources: the secops:create, secops:edit, and secops:delete abilities, which the built-in Administrator and Team Member roles have.

How it works

Most rules are written in Sigma, an open YAML format for detection rules, which Fencer compiles to a SQL query. A few are written directly in SQL. A rule matches single events, or counts and correlates events within a time window, for example one principal calling AWS from more than one IP address within an hour.

Each rule also carries metadata: a title, a severity, a confidence score, a detection event type, and recommendations. A scheduled pipeline runs every enabled rule against your security events. When a rule produces results, Fencer applies any severity or confidence modifiers that match the result, fills in the recommendations, and creates detections. Detections are deduplicated using a grouping key, so repeated matches for the same activity do not create duplicate entries.

A rule only runs when the data source it reads is connected. A rule whose data source is missing shows as Disabled, with the reason, for example “AWS CloudTrail isn’t a configured datasource for this organization.”

Built-in rules

Fencer provides rules organized by data source:

AWS — AWS CloudTrail Important Change (stop, update, or delete a trail), AWS Root Credentials, AWS IAM Backdoor Users Keys, AWS Snapshot Backup Exfiltration, AWS GuardDuty Important Change, AWS Config Disabling Channel/Recorder, AWS CloudTrail Multiple IP Detection, AWS S3 Access Denied Spike, AWS ALB SQL Injection Detection, AWS ALB Unencrypted Connection Detection, AWS RDS PostgreSQL Brute Force Detection, AWS Route53 DNS Tunneling Detection, and heartbeat rules for CloudTrail and VPC Flow Logs.

GCP — GCP Anonymous Access Attempt, Google Cloud Service Account Disabled or Deleted, Google Cloud Firewall Modified or Deleted, GCP Firewall Denied Traffic to Sensitive Ports, GCP VPC Flow Denied Traffic, GCP VPC Flow Traffic to Cleartext Protocol Ports, GCP VPC Flow Traffic to Crypto Mining Ports, GCP Cloud Armor Rate Limiting Action, GCP Cloud Armor Request Denied, GCP Cloud DNS NXDOMAIN Response, GCP Cloud SQL Failed Authentication, and GCP Cloud Storage Public Access or Permission Change.

GitHub — Github Push Protection Disabled, GitHub Repository Ruleset Change, GitHub Tag Modification, GitHub Webhook Created, GitHub Webhook Configuration, GitHub IOC Repository Created, GitHub Package Publish (releases, registry publishes, and tag pushes), and GitHub Workflow Configuration Change (workflow file edits and enable/disable). See OWASP SPVS Coverage for how the last two map to provenance controls.

1Password — 1Password Geo Improbable Access, 1Password Non-MFA Login Detected, 1Password Sensitive Item Access, 1Password Unusual Client Detected, and 1Password User Targeted Brute Force.

Google Workspace — Google Workspace Drive Item Shared Externally, Google Workspace OAuth Sensitive Scope Granted, and Google Workspace Suspicious Login.

Cloudflare — Cloudflare API Token Created or Modified, Cloudflare Global API Key Used, Cloudflare Logpush Job Deleted, Cloudflare Security Control Deleted, and Cloudflare Worker Modified Interactively.

DigitalOcean — DigitalOcean Droplet Backups Disabled, Droplet Destroyed, Droplet Password Reset, Droplet Rebuilt or Restored, Droplet Snapshot Created, Floating IP Released, and Image Destroyed.

Each rule has a detection event type that classifies it as one of: Intrusion, Network, Malware, Authentication, or Access.

Usage / Configuration

Viewing rules

1. Go to Operations > Security Monitoring and open the Rules tab. Below the page tabs, Rules, Global Variables, and External Rule Sources switch between the rule list and its settings.
2. The rules list shows each rule’s Rule title, Event Type, Severity, Confidence, whether it is Enabled, and its Source (Built-in or External).
3. Use the search box to find rules by title or rule ID, or use Filter to narrow by Severity, Event Type, Source, or External Rule Source.
4. Click a rule to open Rule Details in a side panel.

The detail panel shows the Rule ID, Status (Enabled or Disabled, with the reason when Fencer turned it off), Event Type, Severity, Confidence, and Source. Below that are the rule’s Recommendations, Conditional Recommendations, Severity Modifiers, Confidence Modifiers, and Variables, then the Sigma Rule and its Generated SQL Query, or the SQL Query for a rule written in SQL.

Customizing a rule variable

Rules can define variables that let you tailor their behavior without editing the query. For example, the 1Password Geo Improbable Access rule has an EXCLUDED_USER_EMAILS list variable that controls which users it ignores. A variable is a List (several values), a String (one value), or a Dict (key and value pairs).

1. Open a rule from the rules list.
2. In the Variables section, click the pencil icon (Edit variable) next to the variable.
3. In Edit Variable, leave Use Global Variable set to Use custom value (no override) to enter your own value, or choose a global variable of the same type.
4. For a list, enter each value under Values and press Enter or comma after each one. For a string, enter the Value. For a dict, enter the Entries, or switch to CSV to paste one key,value per line.
5. Click Save Changes. Fencer regenerates the rule’s query with the new values.

A value cannot contain template syntax such as {{ or {%.

Enabling or disabling a rule

1. Open the rule detail panel.
2. Click Disable Rule or Enable Rule. The button is unavailable when Fencer turned the rule off because its data source is not connected.
3. Disabled rules are not executed during the scheduled processing pipeline.

External rules have no button: they follow the Enabled setting of their rule source. To change several rules at once, select them in the rules list and choose Enable or Disable.

Resetting a rule to defaults

If you have customized a rule and want to revert to the original configuration:

1. Open the rule detail panel.
2. Click Delete Custom Configuration and confirm with Delete. This removes your custom variable values, global variable links, and enabled setting for the rule.
3. The rule reverts to its built-in defaults.

Managing global rule variables

Global rule variables are organization-wide values that can be shared across multiple rules. Instead of updating the same exclusion list in every rule, you define it once as a global variable and link it wherever needed.

1. Open the Rules tab and click Global Variables.
2. Click Create Global Variable.
3. Enter a Variable Name. It must start with a letter and contain only letters, digits, and underscores. now and today are reserved.
4. Choose the Variable Type: List, String, or Dict.
5. Enter the value or values and click Create variable.

To link a global variable to a rule:

1. Open the rule detail panel and click the pencil icon next to a variable.
2. Under Use Global Variable, choose the global variable. Only global variables of the same type as the rule variable are offered.
3. Click Save Changes. The variable shows the global variable’s name, and the rule query uses its value.

The detail panel of a global variable lists the Rules using this variable.

Caution

Deleting a global variable is blocked if it is linked to any rules. Unlink it from all rules first, then delete it.

When you update a global variable’s value, all rules linked to it are automatically re-interpolated with the new value.

Importing rules from your own repository

On External Rule Sources you can pull Sigma rules (.yml or .yaml files) from a Git repository, such as your own detection repository or a public one like SigmaHQ. Imported rules appear in the rules list with the source External.

1. Open the Rules tab, click External Rule Sources, and click Add Rule Source.
2. Under Repository access, keep Public repository (no authentication) for a public repository and enter its HTTPS Repository URL. For a private repository, choose one of your source-control connections and pick the Repository.
3. Set the Branch (default main) and, optionally, a Path filter to pull only part of the repository.
4. Choose the Sync frequency, from Every hour to Every week. The default is Every day.
5. Optionally, under Detection defaults, set the Default severity, Default event type, and Default confidence for rules that do not set their own.
6. Click Add rule source.

The sources list shows each source’s Repository, Branch, Status, and Last synced result, with the number of rules imported, skipped, and failed. Use Sync now to sync at once. A disabled source keeps its settings but never syncs, and its rules do not run. Deleting a source stops the sync and removes its rules.

Deployment status

Fencer manages a deployment status for each built-in rule, which controls whether it runs:

• Draft — The rule is under development and does not run.
• Testing — The rule runs without creating detections.
• Production — The rule runs and creates detections.

The status applies across all organizations and is not shown in the app.

Examples

Excluding known travelers from an improbable-travel rule:

1. Open the 1Password Geo Improbable Access rule.
2. The rule has an EXCLUDED_USER_EMAILS list variable, empty by default.
3. Click the pencil icon on the variable and add the email addresses of users who often travel (for example ops-traveler@example.com), pressing Enter after each.
4. Click Save Changes. The rule no longer raises detections for those users.

Creating a shared exclusion list with global variables:

1. Open Global Variables, click Create Global Variable, and create a variable named AUTOMATION_ACTORS with type List and the values deploy-bot@example.com and ci-runner@example.com.
2. Open each Cloudflare rule that has an EXCLUDED_ACTORS variable, such as Cloudflare API Token Created or Modified, and link the variable to AUTOMATION_ACTORS.
3. Later, when you add a new automation account, update the global variable once — all linked rules update automatically.

Troubleshooting

• Rule not generating detections — Verify the rule shows Enabled for your organization and that the relevant data source is connected and ingesting events. If it shows Disabled, the detail panel gives the reason.
• Variable changes not taking effect — After you save a variable change, the rule’s query is regenerated and used from the next scheduled run.
• Cannot delete a global variable — The variable is still linked to one or more rules. Its detail panel lists them. Open each linked rule, set the variable back to Use custom value (no override), then try deleting again.
• Reserved variable name error — Variable names now and today are reserved by the rules engine. Choose a different name for your global variable.
• An external rule shows Disabled — Fencer could not convert it into a query, or its source is disabled. The rule’s detail panel gives the reason.

Related pages

• Security Monitoring (SIEM)
• Detections
• SIEM Alerting
• OWASP SPVS Coverage