Just automated risk score adjustments based on our ticket system.

Having recently completed an integration between Exabeam's New-School SIEM and our internal IT service management platform, I believe there is significant, under-discussed value in leveraging external business context to modulate security risk scores. The canonical use case—boosting the risk of a user who just submitted a resignation letter—is merely the entry point. Our implementation focuses on a more nuanced, bidirectional adjustment model based on ticket state, category, and resolution.

The core premise is straightforward: a security alert generated by Exabeam carries a certain risk score. However, if that alert correlates to an open ticket where the activity has been deemed legitimate (e.g., a "server patching" ticket justifying unusual after-hours logins from an admin), the risk should be attenuated. Conversely, the absence of a justifying ticket for anomalous behavior should provide a positive weighting factor. The technical execution, however, involves several distributed systems challenges.

Our architecture hinges on a lightweight middleware service, acting as an enrichment plugin within Exabeam's ecosystem. This service listens for notable asset or user sessions from the Exabeam Data Lake, performs a near-real-time query against the ITSM's REST API, and applies adjustment logic before the session is evaluated by the Behavioral Analytics engine. The critical design points were:

* **Idempotency and Retry Logic:** ITSM API calls can fail. Our enrichment service must store its adjustment decisions in a local, persistent cache (we used Redis) to ensure repeated processing of the same session doesn't lead to score drift.
* **Stateful Correlation:** Mapping a security event to a ticket is not trivial. We key on a combination of `asset_hostname` + `time_window` for infrastructure-related alerts and `username` + `activity_type` for user-centric ones.
* **Adjustment Rules as Code:** We avoid GUI-based rules for maintainability. The adjustment policies are defined in a declarative YAML configuration, version-controlled and deployed with the service.

```yaml
# Example adjustment policy (excerpt)
adjustment_policies:
- name: "legitimate_change_window"
trigger_event_category: "Authentication"
correlation_key: "asset_hostname"
itsm_ticket_query: "category='Change Management' AND status IN ('In Progress', 'Implemented') AND affected_assets CONTAINS {{asset}}"
score_adjustment: -30
max_adjustment_cap: -50
conditions:
- field: "event_operation"
operator: "IN"
values: ["Success", "Failure"]
```

We observed a measurable reduction in false positive notable user sessions—approximately 18% over a 90-day evaluation period—specifically in change management and incident response scenarios. However, pitfalls emerged:

* **Latency Introduced:** The synchronous API call to the ITSM adds 200-300ms to session processing. We had to tune the Exabeam session watermark accordingly to avoid pipeline stalls.
* **Data Model Discrepancies:** Aligning Exabeam's asset inventory (often from Active Directory) with the CMDB in the ITSM required a normalization layer, which became a significant sub-project.
* **Adjustment Overreach:** An initial rule that overly aggressively reduced scores for any open ticket led to a missed true positive where an attacker had exploited a known, ticketed vulnerability. We introduced a `max_adjustment_cap` and a blacklist of high-severity alert types that cannot be fully neutralized.

The integration ultimately shifts the SOC's workflow. Analysts now see a contextual tag on the notable session timeline: "Correlated with ITSM Ticket CHG-12345 (Change Management)". This provides immediate investigative context without requiring a manual tab switch. The more ambitious, and still ongoing, extension is feeding security incident tickets created in Exabeam back into the ITSM, creating a closed-loop system where risk scores influence operational priority, and operational context refines risk scores. I am interested in hearing from others who have attempted similar contextual integrations, particularly regarding how you handle the eventual consistency problem between the SIEM's data lake and the external system of record.