Detection engineering: считайте не только правила, но и шум

Проблема

Команды любят считать detections по количеству или по наличию ATT&CK mapping. Но без метрик полезности rule sprawl быстро съедает доверие аналитиков и превращает triage в однообразную очистку шума.

Даже хороший сигнал может устареть, если его не проверять на новых логах, не держать owner-а и не фиксировать, как он вёл себя на реальных учениях, пентестах и инцидентах.

Решение

Полезно вести небольшой набор зрелых метрик: false positive rate, time-to-tune, detection coverage intent, mean time to production, red-team validation rate, stale-rule ratio.

Важно не только число alerts, но и вопрос 'что rule хотел увидеть'. Тогда coverage считается не по шуму, а по защищаемым сценариям и по качеству обратной связи от аналитиков.

Что проверить руками

• Для каждого правила хранить owner, цель, data source, FP notes и дату последнего review.
• Сравнить noisy rules и never-fired rules: обе категории важны.
• Отдельно учитывать, какие правила были подтверждены red team/pentest или real incident.
• Сделать простую процедуру downgrade/archive для stale rules.

Типичные ошибки

• Считать шум ценой 'большего покрытия'.
• Не отделять detection intent от конкретной query implementation.
• Не использовать QA feedback аналитиков как источник улучшения program.

Defensive checklist

• У rules есть owner и review date.
• Есть метрики FP rate и tune latency.
• Coverage считается по сценариям, а не по числу yaml-файлов.
• Stale/noisy rules имеют путь к архиву или переработке.

Безопасный пример кода

Простой подсчёт FP rate и stale rules. Пример рассчитан на owned/lab-среду и показывает инженерную логику проверки, а не эксплуатационную цепочку.

from datetime import date


def rule_health(rule: dict) -> dict:
    alerts = max(rule.get("alerts", 0), 1)
    fp_rate = rule.get("false_positives", 0) / alerts
    stale = (date.today() - date.fromisoformat(rule["last_review"])).days > 90
    return {"rule_id": rule["id"], "fp_rate": round(fp_rate, 2), "stale": stale}


sample = {"id": "edge-404-burst", "alerts": 42, "false_positives": 18, "last_review": "2026-03-20"}
print(rule_health(sample))

Как это должно попасть в отчёт

• Program view: coverage intent, noise, tuning debt, stale rule ratio.
• Evidence: recent alerts, validation notes, owner feedback, last review.
• Retest: updated rule produces better signal/noise on the same scenario.