Алерт о переборе паролей срабатывает 400 раз в сутки, и SOC закрывает его автоматом. Разберитесь и настройте правило.
Вы отвечаете за правило SIEM о переборе паролей. Оно срабатывает около 400 раз в сутки, и SOC закрывает его не читая.
Ограничения:
- Правило нельзя отключить, заглушить или удалить.
- После изменений password spraying должен по-прежнему детектироваться.
10.20.0.5— корпоративный VPN-шлюз; все удалённые сотрудники видны из-под него.
ALERT brute_force_failed_logons count=63 window=5m src_ip=10.20.0.5
distinct_accounts=54 successful_logon_after=0
sample: user=a.petrov EventID=4625 status=BAD_PASSWORD
sample: user=m.ivanova EventID=4625 status=BAD_PASSWORD
ALERT brute_force_failed_logons count=58 window=5m src_ip=10.20.0.5
distinct_accounts=51 successful_logon_after=0
ALERT brute_force_failed_logons count=12 window=5m src_ip=10.20.0.5
distinct_accounts=1 successful_logon_after=1 user=svc_backupОбъясните, почему первые два алерта ложные, и перепишите правило так, чтобы оно осталось полезным.
Неудачи считаются по исходному IP, а VPN-шлюз прячет за одним адресом сотни пользователей, поэтому обычные опечатки перебивают порог. Считайте по учётной записи, а для общего выхода алертите на число разных учёток с неудачами — так spraying остаётся видимым.
- ✗Поднять порог, что глушит spraying вместо устранения шума
- ✗Полностью исключить IP шлюза и потерять всю видимость за ним
- ✗Читать общий NAT-адрес как одного атакующего пользователя
- →Как доказать, что настроенное правило всё ещё ловит медленный spraying?
- →Каким контекстом обогатить алерт, чтобы ускорить разбор?
Первые два алерта — ложные срабатывания. Признак не в объёме, а в форме: 54 разные учётные записи, ноль успешных входов после неудач и стабильная повторяемость каждые пять минут. Это профиль общего выхода — за 10.20.0.5 сидят сотни сотрудников, и их обычные опечатки складываются в один счётчик. Третий алерт наоборот выглядит настоящим: одна учётка svc_backup и успешный вход после серии неудач.
Поднимать порог нельзя: это и есть «ослепить себя» — медленный spraying по 3 попытки на учётку никогда не наберёт 500. Правильный ход — сменить сущность агрегации и добавить отдельное правило для общих выходов.
- rule: failed_logons_per_account
group_by: [target_account]
where: "event_id == 4625"
threshold: 8
window: 10m
enrich: [account_owner, is_service_account, src_geo]
- rule: spraying_from_shared_egress
group_by: [src_ip]
where: "event_id == 4625"
metric: distinct(target_account) # не сырые неудачи
threshold: 25
window: 30m
applies_to: shared_egress_assets # 10.20.0.5 помечен как общий выходПервое правило работает для обычных хостов, второе оставляет шлюз под наблюдением, но считает разные учётки, а не суммарные опечатки. Дополнительно стоит поднимать приоритет, когда за неудачами следует успех.
