SIEM Alerting

Overview

SIEM alerting uses notification rules. A rule on the Security detection trigger runs each time the SIEM creates a detection. The rule’s conditions decide which detections match, and its destinations decide where the alert goes: a Slack channel, an organization email address, a webhook, or people (the organization admins or a specific member, by email, Slack DM, or in-app notification). You can create as many rules as you need, for example one for critical detections to Slack and one for everything to your own system.

Prerequisites

• An active SIEM subscription (paid feature).
• Permission to edit organization settings (organization admins have it).
• At least one destination:
  • Slack: a connected Slack workspace.
  • Email: a verified organization email address (under Settings > Emails).
  • Webhook: an HTTPS endpoint on a public address that accepts POST requests.

How it works

When the SIEM creates a detection, Fencer checks it against every enabled Security detection rule in your organization. Each rule that matches sends one alert to each of its destinations. A rule can also wait before it sends and check the detection again, skip a detection it alerted on recently, or roll detections into one message per time window.

Members also get their own default Security Detection rule when they join a SIEM organization (every role except Penetration Tester). It notifies them of every detection in the in-app inbox and by email. Members whose role can manage personal rules (every built-in role except Penetration Tester) can narrow or pause it under User settings > Notifications.

Usage / Configuration

Opening the alerting rules

Open Operations > Security Monitoring and select the Alerting tab. It opens the organization’s notification rules, filtered to the Security detection trigger. You can also go to Settings > Notifications and filter by the trigger.

If there are no detection rules yet, the page offers starter templates for them.

Creating a rule

1. On the Alerting page, click New rule or pick a template.
2. Set the trigger to Security detection.
3. Add conditions. All conditions must match:
   • Severity: for example Critical and High.
   • Event Type: Intrusion, Network, Malware, Authentication, Access, or Not categorized.
   • Detection Rule: one or more built-in, custom, or external rules.
   • Asset: the asset the detection belongs to.
   • Status, Assignee, Tracked Externally: a new detection is always New, unassigned, and not tracked. These conditions are only useful together with a wait (step 4).
4. Optionally, under Wait to confirm before sending?, pick a wait. The rule checks the detection again when the wait ends and only sends if it still matches. For example, “Status is New” with a one-hour wait alerts on detections that nobody has triaged within an hour.
5. Optionally, under Skip repeats of the same vulnerability? (the label is shared with vulnerability rules), pick how long a recurring detection stays muted after an alert. Under How often should this rule send?, pick a window to roll detections into one message.
6. Under Send it to, turn on one or more destinations, then click Save rule.

Note

Not categorized is the event type of a detection whose rule was deleted, and of a detection from an external rule source that has no default event type. Set a default event type on the external rule source to categorize its future detections.

Adding a webhook destination

1. In the rule’s destinations, add Webhook.
2. Enter the Endpoint URL. It must use HTTPS and a public address.
3. Optionally enter Headers as a JSON object with text values, for example {"Authorization": "Bearer your-token"}. Readers without edit permission do not see the endpoint URL, and see header values masked.
4. Optionally enter a Signing secret to verify each request (see Webhooks). The secret is 32 to 100 base64 characters; a whsec_ prefix is optional. Leave it blank when you edit the rule to keep the current secret.
5. Choose the Payload format:
   • Standard event (v1): one request per rule run, the same shape for every trigger.
   • Detection (legacy format): one request per detection, in the format SIEM alert webhooks used before rules.
6. Save the rule, then click Test send, choose Send to Webhook only, and confirm to send a sample to the endpoint.

Editing, pausing, and deleting a rule

Click a rule to edit it. Use its toggle to pause it without losing its settings. Deleting a rule stops all its deliveries immediately and also removes its webhook endpoint.

Alert configurations from before rules

Fencer moved each SIEM alert configuration to a Security detection rule with the same severities, event types, and destinations. There are three differences:

• A rule that had event types also includes Not categorized and the default event types of your external rule sources, because the old alerts sent those detections to every configuration. Remove them from the rule’s Event Type condition if you do not want them.
• The old alerts sent Info detections to every configuration. The rules do not include Info. Add it to a rule’s Severity condition if you want it.
• A configuration with every severity turned off was not moved.

Examples

Critical detections to Slack

• Condition: Severity is Critical.
• Destination: Slack, #security-critical.

Untriaged high-severity detections to email

• Conditions: Severity is Critical or High, and Status is New.
• Wait: one hour.
• Destination: Email, your security team’s address.

Every detection to your own system

• No conditions.
• Destination: Webhook, https://your-siem.example.com/api/alerts, payload format Detection (legacy format).

Troubleshooting

• The Alerting tab is missing: you need permission to read organization settings.
• Slack is greyed out with “Slack isn’t available for this organization.”: click Connect Slack to connect it first.
• A test send is skipped with “Security detection notifications are only produced by a real detection.”: a test uses a real detection from the last 14 days. Wait for a detection, then send the test again.
• “Enter a valid HTTPS URL” or “The webhook URL must be a public address”: use an HTTPS URL that resolves to a public host.
• “Save the rule to apply your changes, then send a test.”: a webhook test uses the saved endpoint. Save the rule first.
• A rule never sends: check that it is enabled and that a new detection can match its conditions. Status, Assignee, and Tracked Externally only change after a wait.

Related pages

• Security Monitoring (SIEM)
• Detections
• Detection Rules
• Notifications and Alerts
• Webhooks
• Slack Integration