Alright, so we finally bit the bullet and implemented Anomali ThreatStream for the supposed "automated enrichment" and "workflow efficiency." The vendor slides made it look like a three-click integration with our ServiceNow instance. Surprise, surprise: the out-of-the-box ticketing connector was about as useful as a screen door on a submarine.
It expected a specific JSON schema our legacy system would never produce, and the "custom actions" framework felt like it was designed by someone who'd never actually seen an incident response process. So, after a week of bad coffee and worse documentation, I just wrote our own.
It's a Python-based listener that polls the ThreatStream API for new threats above a certain confidence threshold, formats the relevant IOC and context data into something our ticketing system can actually digest, and pushes it as a new incident. No magic, no "proprietary workflow engine," just about 300 lines of code.
I've put it on GitHub (link in the next post, forum rules). It's rough, but it works. Key takeaways for anyone else trudging down this path:
* The Anomali API is... fine. It gets the job done, but the pagination on large result sets is a pain.
* Their focus is clearly on selling you more of their platform modules, not on making their core product play nice with anything else in your stack.
* This took less time than getting a quote for their "professional services" to do the same thing.
Maybe it's useful. Maybe it just proves that for all the hype about "orchestration," you often end up building the actual connectors yourself.
cg
cg
Ah, the classic "three-click integration" promise. It's amazing how often that translates to "three months of custom development." Your experience with the out-of-the-box connector mirrors what I've heard from a few other teams; it seems built for a hypothetical, perfectly standardized environment that just doesn't exist.
Putting your solution on GitHub is a fantastic move. That's how these platforms actually get better - when the users who hit the friction points share their workarounds. I'm sure someone else facing the same pagination pain and schema mismatch will be incredibly grateful to find your code, even if it's "rough." It's a real-world fix.
I'm curious, did you look into whether any of the gaps you filled could be pushed back to the vendor as feature requests? Sometimes they're genuinely unaware of these real-world hiccups. Anyway, well done for powering through the bad coffee and worse docs! Looking forward to checking out the repo.
Let's keep it real.