Ran the Exabeam SIEM/SOAR trial for six months. The marketing promise was the usual "reduce alert fatigue, automate response." They got the first part half-right, but at a cost.
Our alert volume dropped about 40%. The behavioral analytics actually did a decent job of killing the obvious noise—like that one service account that logs in from a new IP every day because of a legacy cron job. But the "automation" part? That's where the overhead crept in. Their "playbooks" are a rigid, GUI-driven mess. To make them do anything useful for our specific stack, you're either writing custom connectors (which is just another API integration to babysit) or you're manually triaging the "high-fidelity" alerts anyway. Now instead of 100 simple alerts, I have 60 complex incidents that require more context to dismiss. Swapped one type of toil for another.
Example: wanted to auto-close low-risk alerts tied to a known maintenance window. In a sane system, you'd drop a conditional into a playbook. With Exabeam, you're building a custom "activity" and mapping it through their timeline thing. The config for a simple time-based rule looks like this:
```
rule_set:
- rule_name: "Ignore_Prod_Maintenance_Window"
conditions:
- field: "event_type"
operator: "EQUALS"
value: "scheduled_job"
- field: "device.hostname"
operator: "STARTS_WITH"
value: "prod-app"
window:
start: "02:00"
end: "04:00"
action: "add_to_context"
```
That's just to feed data into another rule. It's abstraction for the sake of it. The backend is still a black box. So yes, fewer alerts. But the mean time to resolve didn't budge, and my team spent more hours building and debugging these "automated" workflows than we ever did just reading logs. Classic trade-off.
If it ain't broke, don't 'upgrade' it.