Что можно выжать из базовых метрик SOC, если у тебя лапки

Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах.
Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.

Характеристика, которую пишут в описании правила детектирования и произносят на защите архитектуры: обнаруживает 99% атак при доле ошибок в 1%. Звучит как хороший результат, и принимают её обычно без вопросов.

А вопрос тут есть, и он арифметический. При таких характеристиках почти каждое сработавшее правило окажется ложным — не потому, что правило плохое, а потому что атака редкая.

Заявка была скучная: клиент не проходит проверку по списку разрешённых адресов. Адрес его я вижу, адрес в списке есть, файрвол пакет пропускает. Приложение отвечает «доступ запрещён».

В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.