На защите архитектуры правило детектирования обычно описывают парой чисел: ловит 99% атак, ошибается на 1% нормальных событий. Пользователь Хабра под ником jbenderov разбирает, что из этой пары следует арифметически. Возьмём организацию с 200 000 входов в системы за сутки, из которых два — настоящая компрометация. Правило с заявленными характеристиками выдаст около 2000 ложных алертов и примерно одну реальную находку на тысячу разобранных тикетов.

Вывод, который автор предлагает забрать на планёрку: качество правила задаёт доля его ложных срабатываний. Доля пойманных атак на нагрузку смены почти не влияет. Поднять чувствительность с 99% до 100% — точность меняется с 0,10% до 0,10%. Сократить долю ошибок в сто раз, с 1% до 0,01%, — число алертов за сутки падает с 2002 до 22, а точность поднимается до 9%. Область, к которой применяется правило, весит столько же, сколько само правило.

Откуда берётся 0,1%

Считаем по шагам. Верных срабатываний: 2 × 0,99 = 1,98. Ложных: 199 998 × 0,01 = 2000. Всего алертов за сутки — 2002, доля настоящих среди них — 0,10%. Аналитик разбирает около тысячи событий на одну находку, если доживёт до неё за смену.

Причина в соотношении популяций. Вредоносных событий два, нормальных двести тысяч. Один процент ошибок на огромной популяции даёт в тысячу раз больше событий, чем сто процентов попаданий на крошечной. Чувствительность правила этот перевес не отыгрывает, потому что задаёт его редкость атаки, а не настройка правила.

Формально это теорема Байеса: точность = P·Se / (P·Se + (1 − P)·FPR). Здесь P — доля атак в потоке, Se — чувствительность, FPR — доля ошибок на нормальных событиях. Числитель ограничен сверху величиной P: больше двух событий из двухсот тысяч правило не найдёт при всём желании. В знаменателе рядом стоит (1 − P)·FPR — та же доля ошибок, помноженная на всю остальную популяцию. При P = 0,00001 и FPR = 0,01 второе слагаемое больше первого в тысячу раз, и работа над Se этой пропорции не трогает.

Что двигает цифру

Первое предложение на разборе — поднять чувствительность. При стопроцентном обнаружении верных срабатываний станет 2 вместо 1,98, ложных останется 2000, точность вырастет с 0,10% до 0,10%.

Теперь другой рычаг — доля ошибок при неизменной чувствительности:

• 1,00% — алертов 2002, точность 0,10%;
• 0,10% — алертов 202, точность 0,98%;
• 0,01% — алертов 22, точность 9,01%.

Сокращение ошибок в сто раз подняло точность в девяносто с лишним раз, пока она мала. Дальше пропорция кончается: точность упирается в сто процентов, и следующее стократное сокращение даст меньше двенадцатикратного роста. Объём работы при этом падает линейно — с двух тысяч событий в сутки до двадцати двух. Двадцать два события разобрать реально, две тысячи — нет.

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

Сужение популяции работает как рост точности

В формуле есть P — доля атак в том потоке, к которому применяется правило. Если сузить поток так, чтобы атаки встречались чаще, P растёт, и точность поднимается без единой правки в правиле.

Пусть то же правило с долей ошибок 1% применяется только к административным и сервисным учётным записям: четыре тысячи событий в сутки, и одна компрометация из двух приходится на них. Получаем 41 алерт и точность 2,42%. Правило не изменилось ни строкой, изменилась область применения — нагрузка упала почти в пятьдесят раз при потере половины покрытия.

Допущение здесь существенное, и его нужно проверять у себя: атаки должны концентрироваться в выделенной популяции сильнее, чем нормальные события. Если административные учётные записи шумят пропорционально своей доле, сужение не даст ничего — вы поделите на одно и то же число и алерты, и находки.

Отсюда приём: одно и то же условие имеет смысл завести как несколько правил с разными областями и приоритетами. Для администраторов — высокий приоритет и разбор вручную, для остальных — накопление в отчёт. Обычно делают обратное: одно правило на всех, средний приоритет, отключение через месяц.

Каскад из двух дешёвых правил

Третий подход — поставить два дешёвых правила последовательно. Первый этап широкий и грубый. Второй применяется только к тому, что прошло первый, и потому может быть дорогим: обогащение из внешних источников, проверка по журналам конечных устройств, сверка с расписанием отпусков.

На втором этапе остаётся 1,88 верных срабатывания и 40 ложных — 42 события на разбор, точность 4,5%, итоговая чувствительность 94%. Второй этап отсеивает 98% ложных и теряет 5% верных. Сорок два события вместо двух тысяч при обнаружении 94% атак вместо 99%.

Пять процентов чувствительности обменяли на почти пятидесятикратное сокращение ручного разбора. Возражение «мы можем пропустить атаку» здесь звучит мимо: с двумя тысячами событий в сутки атаку пропустят гарантированно, и выглядеть это будет как усталость смены к четвёртому часу.

Почему история заканчивается выключенным правилом

Правило с точностью в одну десятую процента приучает аналитика закрывать его срабатывания не глядя. Поведение рациональное: за месяц человек получил тысячу подтверждений, что событие ничего не значит. К моменту, когда придёт настоящее срабатывание, привычка уже сформирована, и оно уйдёт в ту же корзину, что и предыдущая тысяча.

Дальше правило переводят в низкий приоритет, потом в отчёт, потом отключают. В матрице покрытия галочка остаётся, правило в системе числится. Фактически защиты нет.

Метрика, которой не хватает в отчётах, — доля подтверждённых срабатываний. Требовать её нужно в паре с покрытием: по отдельности каждая ломается. Правило, которое не срабатывает никогда, даёт идеальную долю подтверждений. Правило, срабатывающее на всё, даёт идеальное покрытие. Пара чисел описывает правило, одно число — нет. Если из ста срабатываний подтверждается ноль, правило расходует внимание, и этот расход вычитается из способности заметить остальное.

Та же арифметика вне SOC

Соотношение редкого события и большого потока работает одинаково везде, где срабатывает автоматическое правило: антифрод на форме оплаты, фильтр спама на форме заявки, триггеры модерации контента. Когда доля «плохих» событий мала, правило, настроенное только на полноту обнаружения, хоронит оператора под ложными срабатываниями — и оператор перестаёт читать его сигналы.

Что сделать со своими правилами

Выгрузить тикеты за квартал и посчитать по каждому правилу две величины: сколько было срабатываний и сколько подтвердилось. Отсортировать по доле подтверждённых. Первые строки списка обычно объясняют, куда уходит время смены. Для правил из конца списка решать по очереди: сузить область применения, добавить второй этап проверки или убрать совсем. Убрать — нормальный исход.

И поменять вопрос поставщику при выборе продукта. Вместо «какой процент атак обнаруживается» — «сколько событий в сутки на тысячу сотрудников порождает эта конфигурация и какая доля из них подтверждается у действующих заказчиков». Ответ на первый вопрос дают сразу и с запасом. Ответа на второй иногда нет вовсе, и это говорит о продукте больше, чем цифра про 99%.