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

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

Считаем

Возьмём организацию, где в сутки происходит 200 000 входов в системы, и предположим, что два из них — настоящая компрометация. Правило с заявленными характеристиками: ловит 99% вредоносных событий, ошибается на 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% применяется не ко всем входам, а только к административным и сервисным учётным записям — четыре тысячи событий в сутки, и одна компрометация из двух приходится на них:

популяция  200000, атак 2 -> алертов 2002, точность 0.10%
популяция    4000, атак 1 -> алертов   41, точность 2.42%

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

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

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

Каскад вместо одного правила

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

этап 1: верных 1.98, ложных 2000, на разбор 2002
этап 2: верных 1.88, ложных   40, на разбор   42, точность 4.5%
итоговая чувствительность: 94.0%

Второй этап отсеивает 98% ложных и теряет 5% верных. Итог — сорок два события вместо двух тысяч при обнаружении 94% атак вместо 99%.

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

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

Дальше начинается то, что видно уже не в формулах, а в тикетах.

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

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

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

Если из ста срабатываний подтверждается ноль, правило не защищает, а расходует внимание, и это расход, который вычитается из способности заметить остальное.

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

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

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

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

Правило ловит 99% атак и ошибается в 1% случаев. На одну находку аналитик разберёт тысячу ложных