Trying to write a simple rule to alert on a specific user login from an unusual location. In other SIEMs, this is a 2-3 line filter. In Anomali's rule syntax, I'm wrestling with nested conditionals and verbose field mappings.
Their example for a multi-condition rule:
```yaml
rule:
condition: all
rules:
- field: event.user
operator: equals
value: "admin"
- field: event.geoip.country_code
operator: not_in
value: ["US", "CA"]
actions:
- severity: high
```
Why is this a nested YAML structure when a more declarative, flattened approach would be clearer? The complexity isn't in the logic, it's in the ceremony required to express it.
* Slows down iteration during investigations.
* Obfuscates simple true/false logic.
* Makes bulk rule updates error-prone.
Is this a case of over-engineering, or am I missing the intended benefit?
Oh my gosh, yes. I just tried to set up a rule for something similar last week and spent like an hour just getting the indentation right in their editor. It feels like you're writing a configuration file for a server, not a simple "if this, then that" rule.
I'm new to this platform, but is the nested structure supposed to make it easier when you have *really* complex logic later on? I can see how having that `condition: all` or `condition: any` at the top might help organize a huge rule. But for the basics, it's a huge barrier.
You're definitely not alone in feeling that way. While the structure you quoted is consistent and powerful once you get used to it, I've found the initial learning curve for simple rules to be steeper than it needs to be.
The nested approach does have one clear benefit in my work: it makes vendor risk assessment and compliance audits easier. When you need to prove a rule's exact logic for a control framework, that explicit hierarchy is actually helpful. But you're right, it overcomplicates the daily creation and tuning. I often build simple rules in a text editor first, using snippets, because the platform's own editor makes the ceremony feel heavier.
Have you tried their UI's visual rule builder, or are you writing the YAML directly? I've noticed the visual tool sometimes generates cleaner syntax for straightforward conditions, but then you hit its limits quickly.
read the contract
The audit benefit you mention is real, I've seen it help teams during SOC 2 reviews. But that trade-off between audit clarity and daily usability is something I think the platform hasn't fully reconciled.
You're right about building in a text editor first. It's ironic that their own editor adds friction. I wonder if they'd see higher adoption of their rule syntax if the editor had a "simple mode" that flattened the structure for basic conditions, generating the correct YAML behind the scenes. The visual builder tries this, but as you said, it hits limits fast.
Stay grounded, stay skeptical.
You've hit on the core problem: the syntax is optimized for the wrong phase of the workflow. It's structured for long-term rule maintenance and validation by a reviewer, not for rapid creation and iteration by an analyst.
That specific YAML structure is great for programmatic rule generation or when you're managing hundreds of rules as code. But for the task you described - whipping up a one-off detection during an investigation - it's friction. The cost is developer velocity and alert tuning speed. I'd wager most rules are written exactly once, not audited monthly.
The real missed opportunity is that their compiler or frontend parser doesn't accept a simpler DSL and transform it into this verbose YAML internally. The complexity should be in their engine, not forced onto the user for every single condition.
Measure twice, migrate once.