Alert Rules

Alert rules define the relationship between events, environments, and destinations. Each rule says: "When this event happens in this environment, send a notification to this destination."

Creating a Rule

1. Navigate to Integrations > Alert Rules.
2. Click Add Rule.
3. Fill in the rule configuration:

Name (required): A descriptive name that identifies what this rule does. Examples: "KEV to Teams", "Critical OT to PagerDuty", "All findings to SIEM webhook".

Trigger Event (required): What event causes the rule to fire. Select from:

Environment (required): Which environment triggers this rule. Select a specific environment or All Environments for org-wide rules.

Severity Floor (optional): Minimum CVSS or BCS score to trigger. Example: set to 8.0 to fire only for BCS 8.0+ findings, even if the event type would normally include lower scores.

Layer Filter (optional): Fire only for findings on a specific layer (OT, OS, NETWORK). Useful for routing OT findings to the OT team and NETWORK findings to the network team.

Destination (required): Where the alert is sent. Select from your configured connections:

• Email (enter address directly)
• Microsoft Teams connection
• Slack connection

• Webhook connection

• Click Save Rule.

Rule Examples

Example 1: All KEV Matches to Slack

• Name: KEV to Slack Critical
• Event: kev.new
• Environment: All Environments
• Destination: Slack connection "#vuln-critical"

Every new KEV match across all environments posts to the critical Slack channel.

Example 2: OT Critical Findings to Teams

• Name: OT Critical to Teams
• Event: cve.critical
• Environment: Water Plant Alpha
• Layer: OT
• Destination: Teams connection "OT Security Channel"

Only critical OT findings in the water plant trigger this alert. OS and NETWORK findings are excluded.

Example 3: High+ to SIEM Webhook

• Name: High+ to SIEM
• Event: asset.matched
• Environment: All Environments
• Severity Floor: 7.0
• Destination: Webhook connection "Splunk HEC"

Every new finding with BCS 7.0 or higher sends data to your SIEM for correlation.

Example 4: Reports to Manager Email

• Name: Reports to CISO
• Event: report.ready
• Environment: All Environments
• Destination: Email [email protected]

The CISO gets an email whenever a report is generated.

Managing Rules

Navigate to Integrations > Alert Rules to see all configured rules.

Each rule shows: name, event, environment, destination, and enabled status.

Enable/Disable: Toggle a rule on or off without deleting it. Disabled rules do not fire. Use this for temporary suppression (e.g., during a planned outage when you know findings will spike).

Edit: Modify any field on an existing rule.

Delete: Permanently remove the rule.

Test: Send a test notification to the configured destination. The test uses a sample finding payload so you can verify the format and delivery.

Rule Evaluation Order

When an event occurs, BreachSpider evaluates all enabled rules:

1. Does the rule's event type match?
2. Does the rule's environment match (or is it set to All)?
3. Does the finding meet the severity floor (if set)?
4. Does the finding match the layer filter (if set)?

If all conditions are met, the alert is sent. Multiple rules can match the same event, resulting in multiple alerts to different destinations. This is by design -- you may want a KEV match to go to both Slack and email simultaneously.

Avoiding Alert Fatigue

Be specific with event types. Using asset.matched for all environments with no severity floor can generate dozens of alerts per day. Reserve asset.matched for SIEM webhooks. Use kev.new and cve.critical for human-facing channels.

Use severity floors. A severity floor of 7.0 or 8.0 dramatically reduces alert volume while keeping the most important findings visible.

Use layer filters. Send OT alerts to OT engineers, NETWORK alerts to network engineers. Each team sees only relevant findings.

Use digest mode for email. Lower-priority events can be batched into daily or weekly digests instead of individual emails. Configure under Account > Notifications.