Routing Tickets by Environment
Ticket routing ensures that remediation tasks reach the right team based on which environment the finding belongs to. A water plant finding should not land on the substation team's board, and vice versa.
How Routing Works
When you create an auto-ticket rule, you specify which environment the rule applies to. This creates environment-specific routing:
- Rule A: Water Treatment Plant Alpha > trigger: kev.new > destination: [email protected]
- Rule B: Substation Beta > trigger: kev.new > destination: [email protected]
- Rule C: Corporate IT > trigger: cve.critical > destination: Jira project IT-SEC
Each environment gets its own routing path. The same trigger event (kev.new) routes to different destinations depending on which environment the affected asset belongs to.
Routing Strategies
Strategy 1: Per-Environment Email
The simplest approach. Create one email rule per environment:
| Environment | Email Destination |
|---|---|
| Water Plant Alpha | [email protected] |
| Substation Beta | [email protected] |
| Manufacturing Floor 3 | [email protected] |
| Corporate IT | [email protected] |
Each team receives tickets only for their site.
Strategy 2: Per-Environment Jira Projects
If your organization uses Jira, route tickets to different Jira projects by environment:
| Environment | Jira Project |
|---|---|
| Water Plant Alpha | WPA |
| Substation Beta | SUB |
| All Environments (critical) | SEC |
The SEC project catches all critical findings org-wide, while site-specific projects handle routine findings.
Strategy 3: Severity-Based Routing
Route by severity rather than (or in addition to) environment:
| Severity | Destination |
|---|---|
| Critical (BCS 9.0+) | PagerDuty (immediate alert) |
| High (BCS 7.0-8.9) | Jira with sprint assignment |
| Medium (BCS 4.0-6.9) | Email digest to team lead |
Strategy 4: Layer-Based Routing
Use the layer field to route tickets to the right team:
- OT findings > OT engineering team
- OS findings > IT patching team
- NETWORK findings > Network operations team
This requires creating separate auto-ticket rules for each layer, using the layer filter in the rule configuration.
Combining Strategies
Most organizations combine strategies. A common configuration:
- All KEV matches, all environments > Email to [email protected] (org-wide awareness)
- Critical findings, Water Plant > Jira project WPA + Email to [email protected]
- Critical findings, Substation > Jira project SUB + Email to [email protected]
- Weaponized exploits, all environments > PagerDuty
This ensures critical findings reach both the site team and the security leadership, while exploit confirmations trigger immediate escalation.
MSSP Routing
For managed security providers managing multiple clients:
- Create separate auto-ticket rules for each client's environments.
- Route tickets to each client's designated contact or ticketing system.
- Optionally, create a parallel rule that also sends tickets to your internal MSSP triage board for oversight.
| Client | Environment | Destination |
|---|---|---|
| Acme Utility | Water Plant | [email protected] |
| Acme Utility | Substation | [email protected] |
| Beta Manufacturing | Factory Floor | [email protected] |
| All clients (internal) | All Environments | Jira project MSSP-TRIAGE |
Testing Your Routing
After configuring routing rules, test each one:
- Navigate to Integrations > Ticketing.
- Click Test on each rule.
- Verify the test ticket arrives at the expected destination.
- Confirm the ticket content includes the correct environment name, CVE details, and assignee.
Test before relying on auto-rules for production alerts. A misconfigured rule means a critical finding goes to the wrong team or nowhere at all.