Skip to content
Notifications
Clear all

TIL: You can use the API to automate threat containment. Sample script inside.

3 Posts
3 Users
0 Reactions
5 Views
(@marktomark)
Trusted Member
Joined: 2 months ago
Posts: 33
Topic starter   [#61]

I was building a custom dashboard for our security alerts and realized the manual threat containment in Intercept X was creating a bottleneck. Turns out, the API is pretty robust for this! I've started automating isolation for endpoints that flag certain critical threats, which saves the team a ton of time.

Here’s a basic Python snippet I used to get started. It looks for a specific malware ID from a scan report and then contains the host:

```python
import requests

api_url = 'https://your-central-server/api/endpoint/contain'
headers = {'Authorization': 'Bearer YOUR_API_KEY', 'Accept': 'application/json'}
data = {'id': 'endpoint_id_here', 'comment': 'Auto-contained via API due to critical malware'}

response = requests.post(api_url, headers=headers, json=data)
if response.status_code == 200:
print("Endpoint contained successfully.")
else:
print(f"Error: {response.text}")
```

Some things I learned the hard way:
* The `endpoint_id` isn't always obvious — I had to pull it from the threat investigation log first.
* Setting up the role permissions in Central for the API key took a few tries (needs "Manage Endpoints" at least).
* You'll probably want to build in a delay or check the endpoint status before triggering containment to avoid conflicts.

Has anyone else built workflows around this API? I'm especially curious about:
* Triggering containment from external SIEM alerts
* Automating the *release* from containment after a clean scan
* Any gotchas with large-scale deployments (we're only at ~150 endpoints)

I'm working on connecting this to our lead scoring system's alert rules (sounds weird, but the logic is similar!). Will share a spreadsheet comparing response times before/after once I have more data.



   
Quote
(@sre_night_shift_3)
Eminent Member
Joined: 3 months ago
Posts: 19
 

That's a great example. The permission setup especially, it's a step that's easy to miss until the script fails in production. A related nuance we hit was the difference between API endpoints for *containing* a device vs. *isolating* it from the network; the docs sometimes use the terms interchangeably but they're different actions.

Did you consider adding a verification step? After posting the contain command, we often poll the endpoint's status to confirm it actually transitioned before logging it as a success. Otherwise, you risk a false positive if the API call is accepted but the agent can't be reached.


nightowl


   
ReplyQuote
(@cloud_ops_learner_99)
Estimable Member
Joined: 2 months ago
Posts: 137
 

That's super helpful, thanks for sharing! The bit about the `endpoint_id` being tricky is exactly the kind of thing I'd get stuck on.

I'm trying to do something similar with our AWS VPCs, like auto-blocking IPs, and this gives me a template to start from.

> Setting up the role permissions... took a few tries
This part makes me nervous. Did you have to create a dedicated service user in Central, or is there a way to use an existing admin's API key without giving it full rights? Sorry if that's a basic question.



   
ReplyQuote