# Why Most Security Detections Fail in Week One (and How to Fix Yours)
A lot of teams write detection rules that look strong on paper but fail quickly in production. Usually one of two things happens:
- too noisy, everyone ignores alerts
- too strict, real attacks slip through
Think of detection rules like smoke alarms. If the alarm goes off every time you make toast, people remove the battery. If it never goes off, it is useless.
The goal is a rule that is sensitive enough to catch danger, but calm enough to keep team trust.
## Step 1: Start from attacker behavior, not log fields
Bad starting point: "I have this field, what query can I write?"
Good starting point: "What suspicious behavior am I trying to catch?"
Example behavior: privileged token used from an unusual geography.
## Step 2: Map one behavior to one data source
Do not mix five systems in your first rule. That creates brittle logic and slow tuning cycles.
```yaml
rule_id: DET-201
name: Admin token used from unusual country
log_source: auth_gateway
severity: high
condition: |
event.type == "token_used" and
event.actor_role == "admin" and
event.ip_country not in event.usual_countries
```
Keep v1 narrow. Expand later.
## Step 3: Build a tiny local test harness
Before deployment, test with synthetic events.
```python
def should_alert(event: dict) -> bool:
if event.get("type") != "token_used":
return False
if event.get("actor_role") != "admin":
return False
usual = set(event.get("usual_countries", []))
return event.get("ip_country") not in usual
safe_event = {
"type": "token_used",
"actor_role": "admin",
"ip_country": "US",
"usual_countries": ["US", "CA"],
}
risky_event = {
"type": "token_used",
"actor_role": "admin",
"ip_country": "RU",
"usual_countries": ["US", "CA"],
}
```
When `safe_event` is false and `risky_event` is true, your rule is ready for controlled rollout.
## Step 4: Roll out with feedback labels
For the first week, tag every alert as:
- true positive
- false positive
- inconclusive
Those labels are your tuning data. Without them, teams argue from memory instead of evidence.
## Step 5: Tune thresholds with a fixed schedule
Set a weekly tune session. One rule, one owner, one measurable adjustment. Small iterations beat giant rewrites.
## Teaching summary
Good detection engineering is less about clever query syntax and more about disciplined iteration.
1. Behavior first.
2. One source first.
3. Test before rollout.
4. Tune with labels.
That process is what turns noisy rules into reliable security signals.