Skip to content
Notifications
Clear all

Just integrated with ServiceNow. Here's the workflow.

3 Posts
3 Users
0 Reactions
22 Views
(@annab)
Reputable Member
Joined: 3 months ago
Posts: 349
Topic starter   [#25877]

Hi everyone. I've been lurking for a while, learning a ton from all the discussions here. I work primarily in marketing tech, but my role has recently expanded into more of the security operations side, especially around our customer data. We've been using Exabeam for a few months now, and I just finished helping our team integrate it with ServiceNow for automated ticket creation.

I wanted to share the basic workflow we set up, mostly to see if this aligns with how others are doing it or if there are obvious improvements we missed. My background isn't in SIEM, so I'm sure there are nuances I haven't considered.

Our goal was to automatically create an incident in ServiceNow whenever Exabeam generates a High or Critical severity alert. We focused on keeping the ticket actionable from the start. The workflow triggers off the alert in Exabeam, uses a webhook to push the key details (like the alert title, assigned user, entities involved, and a link back to the Exabeam case) into a pre-defined template in ServiceNow.

The most useful part was mapping the Exabeam severity levels to ServiceNow's impact/urgency fields. We set Critical alerts to automatically be High Impact/High Urgency, which helps with prioritization on the ServiceNow side. We also made sure the ticket description includes the timeline of events from the Exabeam case, so the responder doesn't have to jump between systems immediately.

So far, it's cut down the manual ticket creation time significantly. But I'm curious—for those who've had this integration running longer, are there specific alert types or data points you found crucial to include that aren't obvious at first? Also, how do you handle alert updates? We're only creating on the initial alert, but I'm wondering if we should also close tickets when the Exabeam case is resolved.



   
Quote
(@consultant_carl)
Honorable Member
Joined: 6 months ago
Posts: 412
 

That's a solid foundation, especially focusing on making tickets immediately actionable. Mapping severity to impact/urgency is the right move.

One nuance I've run into: that direct severity mapping can sometimes cause alert fatigue if Exabeam's thresholds are a bit broad for your environment. We started adding a simple filter based on the "stage" of the Exabeam case - we only auto-create tickets for alerts attached to an "open" or "escalated" case, not "closed" or "in review". It cut down on duplicate tickets by about 30% for us.

How are you handling the link back to the Exabeam case? We found we needed to embed it in the description *and* a custom field, because some analysts would miss it.


Implementation is 80% process, 20% tool.


   
ReplyQuote
(@davidn3)
Reputable Member
Joined: 2 months ago
Posts: 277
 

Your point about mapping severity to impact/urgency is correct for initial triage, but I'd suggest codifying a logic step to periodically reassign those values after ticket creation.

ServiceNow's impact and urgency should ideally reflect business context, which Exabeam's severity often lacks. We built a scheduled job that runs 15 minutes after ticket creation. It queries the CMDB for the affected CI's business criticality and the user's department tier, then updates the ticket's impact/urgency fields accordingly. This corrected the priority for about 20% of our auto-generated tickets.

Are you populating the `assignment_group` dynamically based on the entity type (user vs. host) or using a static SOC group?


Data is the only truth.


   
ReplyQuote