Характеристика, которую пишут в описании правила детектирования и произносят на защите архитектуры: обнаруживает 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%.
Этот размен и есть суть работы: пять процентов чувствительности обменяли на почти пятидесятикратное сокращение ручного разбора. Разговор о том, что «мы можем пропустить атаку», здесь ведётся неправильно — с двумя тысячами событий в сутки атаку пропустят гарантированно, просто это будет выглядеть не как решение, а как усталость смены к четвёртому часу.
Почему это заканчивается выключенным правилом
Дальше начинается то, что видно уже не в формулах, а в тикетах.
Правило с точностью в одну десятую процента приучает аналитика закрывать его срабатывания не глядя. Это рациональное поведение: за месяц работы человек получил тысячу подтверждений, что событие ничего не значит. К моменту, когда придёт настоящее срабатывание, привычка уже сформирована. Правило отработает штатно и уйдёт в ту же корзину, что и предыдущая тысяча.
Дальше правило переводят в «низкий приоритет», потом в отчёт, потом отключают. Формально покрытие сохраняется — правило в системе есть, в матрице покрытия галочка стоит. Фактически его нет.
Поэтому метрика, которой не хватает в отчётах, — доля подтверждённых срабатываний. Требовать её надо в паре с покрытием: по отдельности каждая ломается — правило, которое не срабатывает никогда, даёт идеальную долю подтверждений, а правило, срабатывающее на всё, даёт идеальное покрытие. Пара из двух чисел описывает правило, одно число — нет.
Если из ста срабатываний подтверждается ноль, правило не защищает, а расходует внимание, и это расход, который вычитается из способности заметить остальное.
Что сделать со своими правилами
Выгрузить тикеты за квартал и посчитать по каждому правилу две величины: сколько было срабатываний и сколько из них подтвердилось. Отсортировать по доле подтверждённых. Первые же строки списка обычно объясняют, куда уходит время смены.
Для правил из конца списка решать по очереди: сузить область применения, добавить второй этап проверки или убрать совсем. Убирать — нормальный исход; правило, дающее ноль подтверждений на тысячу срабатываний, не выполняет свою работу и при этом мешает выполнять чужую.
И поменять вопрос, который задаётся поставщику при выборе продукта. Вместо «какой процент атак обнаруживается» — «сколько событий в сутки на тысячу сотрудников порождает эта конфигурация и какая доля из них подтверждается у ваших действующих заказчиков». Ответ на первый вопрос вам дадут сразу и с запасом. Ответ на второй придётся ждать, и то, найдётся ли он вообще, скажет о продукте больше, чем вся презентация.