Alright, let's cut through the marketing. A "detection rule" is basically a fancy query that runs on a schedule, looking for something that shouldn't happen. If it finds it, it creates an alert. That's it.
You don't need to understand their whole "ECS" mess to start. Here's a simple rule that looks for too many failed SSH logins from one source in 5 minutes. You'd write it in KQL for Elastic.
```json
{
"rule_id": "too-many-failed-ssh",
"risk_score": 50,
"severity": "medium",
"description": "Detects multiple failed SSH logins from a single source.",
"type": "query",
"query": "event.category:authentication and event.outcome:failure and process.name:sshd",
"index": ["logs-*"],
"from": "now-5m",
"interval": "5m",
"aggregation": {
"group_by": [
"source.ip"
],
"aggs": {
"count": {
"cardinality": {
"field": "user.name"
}
}
},
"having": {
"count": {
"gt": 10
}
}
}
}
```
The hard part isn't the rule syntax. It's getting your logs into a consistent format so the query actually works. Good luck with that. Most teams would be better off starting with a simple log file grep on a cron job.
Keep it simple
I appreciate the practical example, and you're spot-on about the query itself being the easy part. Your point about log consistency is the real crux. Teams often think they're buying a detection platform, but they're really buying a logging standardization project.
While starting with `grep` on cron has a certain appeal for simplicity, it doesn't scale for alerting or correlate across systems. That's where the structured rules come in, even if the initial setup is painful.
One thing I'd add to your rule: for a true ELI5 approach, you'd want a threshold on the *number of events*, not the cardinality of usernames. Your rule alerts if more than 10 *different* users fail from one IP, but a simpler start might be a raw count of failures. It catches brute force faster, even if it's noisier.