Having recently completed a production integration between Exabeam and ServiceNow, I've documented the end-to-end workflow and several key implementation details. The primary objective was to automate the creation of ServiceNow Incidents from specific, high-priority Exabeam Security Alerts, ensuring a closed-loop ticketing system for our SOC.
The core mechanism is built upon Exabeam's "Add-on Actions" feature, which triggers an HTTP POST to the ServiceNow REST API endpoint (`/api/now/table/incident`) upon alert generation. The complexity lies not in the basic connection, but in the meticulous data mapping and state management.
**Primary Workflow Steps:**
1. **Alert Qualification in Exabeam:** We use a rule-based filter to ensure only alerts meeting specific risk-score and category thresholds proceed to the integration. This prevents ticket spam.
2. **Payload Transformation:** The Exabeam alert JSON must be remapped to ServiceNow's incident schema. This is done within the Exabeam action configuration using its template variable system.
3. **API Call to ServiceNow:** The transformed payload is sent via a secure, authenticated POST request.
4. **State Synchronization:** The returned ServiceNow Sys_ID and Incident number are written back to the Exabeam alert as custom fields.
5. **Closure Sync (Manual):** Currently, closing the incident in ServiceNow does not auto-close the alert in Exabeam. We achieve this via a scheduled report in Exabeam that checks the state of synced alerts against the ServiceNow API.
**Critical Configuration Example:**
Below is a sanitized version of the key payload mapping configured in the Exabeam Add-on Action. The `short_description`, `description`, and `comments` fields are concatenated from multiple Exabeam alert attributes.
```json
{
"u_source": "Exabeam",
"impact": "2",
"urgency": "2",
"short_description": "Exabeam Alert: {{alert_name}} | Risk Score: {{risk_score}}",
"description": "**Alert Details:**\n- Alert ID: {{alert_id}}\n- Primary User: {{primary_user}}\n- Assets: {{assets}}\n\n**Rule Description:**\n{{rule_description}}",
"comments": "Initial alert logged from Exabeam. Refer to Exabeam Case ID: {{case_id}} for full context.",
"u_exabeam_alert_id": "{{alert_id}}",
"u_exabeam_case_id": "{{case_id}}"
}
```
**Key Observations & Pitfalls:**
* **Authentication:** Using OAuth 2.0 (Client Credentials grant) for ServiceNow API access is preferable over basic auth. The token management, however, must be handled externally, as Exabeam's action configuration does not natively support OAuth token refresh within the HTTP action node.
* **Idempotency:** The workflow lacks a native deduplication check. We implemented a pre-check script (a separate scheduled task) that queries ServiceNow for existing open incidents with the same `u_exabeam_alert_id` before allowing the main action to fire.
* **Error Handling:** Exabeam's action retry logic is limited. Any 4xx/5xx response from ServiceNow will cause the action to fail silently after retries. We supplemented this by routing all action logs to a SIEM for monitoring failures.
* **Data Enrichment Gap:** The Exabeam alert context (User Timeline data, peer groups) is not automatically included in the ServiceNow payload. To provide analysts with crucial context, we append a deep link back to the Exabeam alert in the `description` field.
The integration is functionally stable but requires ongoing maintenance, particularly around API version compatibility and the monitoring of the state-synchronization script. A true bi-directional sync for incident/alert closure remains a gap that would require a middleware orchestrator or custom app in ServiceNow.