Alright, so you've got Umbrella doing its thing, blocking DNS requests to shady crypto-mining pools and your users' favorite "totally work-related" gaming sites. But when it blocks something important and a VIP starts yelling, your security team is scrambling through logs while the help desk has no idea. Sound familiar? 😅
Time to connect the dots. Integrating Umbrella with ServiceNow for automatic ticket creation turns those security events into actionable tickets. It's not magic, but it's close. Here's the gist of how we set it up using Umbrella's Reporting API and ServiceNow's Inbound REST API.
First, you need a scheduled job (we used a simple Python script in a serverless function) that fetches blocked events from Umbrella's `reports/v2/activity/list/blocked` endpoint. You filter for what you care about—maybe high-risk categories or specific internal networks. Then, you map that data into a JSON payload for ServiceNow.
```python
# Simplified snippet of the mapping logic
incident_payload = {
"short_description": f"Umbrella Block: {event['domain']}",
"description": f"Umbrella blocked a request to {event['domain']} (category: {event['categories']}) from source IP {event['internalip']}.",
"urgency": "2",
"caller_id": "umbrella.integration",
"category": "security",
"subcategory": "dns"
}
```
The brutal truth? The hardest part isn't the code; it's the ownership. Does the ticket go to the network team, the security ops team, or the help desk? You'll spend more time in those meetings than writing the integration. Also, watch out for alert fatigue—tune your categories carefully, or you'll drown in tickets for "Social Media" blocks.
Overall, it’s a solid win for visibility. The help desk gets context, security gets a paper trail, and you get fewer midnight calls about "the internet being down" because someone tried to visit a malware domain.
- tm
That mapping approach is solid, but you'll want to add deduplication logic before hitting the ServiceNow API. Without it, a single domain getting blocked repeatedly for an hour can create a flood of identical tickets.
We added a simple cache (like a Redis set) to store the domain and source IP combo for a configurable window, maybe 15 minutes. Only if that key doesn't exist do you proceed with the ticket creation call. It cut our ticket volume by about 70% without losing meaningful alerts.
Commit early, deploy often, but always rollback-ready.
Good point on the deduplication. We implemented something similar but found the time window needed to be variable based on the domain's risk category. A blocked access attempt to a known phishing domain should probably create a ticket every time, while repetitive blocks for "adult content" can be batched.
We ended up adding a small lookup table in our script to define the deduplication window per category. Something like:
```python
dedupe_windows = {
"malware": 0, # No deduplication, alert every time
"phishing": 300,
"adult": 3600
}
```
The cache key then became `f"{source_ip}:{domain}:{category}"` and we used the TTL from that table.
MigrateMentor