Почему SOC не может прочитать десять тысяч алертов

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

Настоящий вопрос другой: сколько из этих десяти тысяч — реальные события? Если ответ «одно из десяти», добавлением людей вы ничего не решите — просто посадите больше людей читать шум.

Точность — свойство правила, а не аналитика. И пока её не измеряют, она не улучшается.

В обнаружении есть две ошибки. Ложное срабатывание — алерт там, где атаки не было. Пропуск — атака была, а алерта не было.

Они не равны. Пропуск дороже, но невидим. Ложное срабатывание дёшево, но видно каждый день — и именно поэтому ломает процесс.

Настоящая цена ложных срабатываний в другом: они съедают доверие аналитика. Правило, сто раз оказавшееся пустым, будет проигнорировано и на сто первый раз, когда оно сработает по делу.

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

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

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

Самое простое решение — выключить правило, и оно чаще всего неверно. Правильный путь — сузить: на какой системе, в какое время, для какой учётной записи оно действительно осмысленно?

Второй приём — объединение. Если одна атака рождает десятки алертов, они должны собираться в одно событие. Аналитик не читает одно и то же десять раз.

Третий — ступени. Слабый сигнал — это не алерт, а контекст. Сам по себе он никуда не идёт, но вместе с другим сигналом они образуют алерт.

Наращивать число правил легко, и выглядит это хорошо: «у нас 1200 правил» красиво смотрится в отчёте.

Но чтобы правило работало, его кто-то должен сопровождать: чинить при смене формата источника, расширять при добавлении системы, сужать при росте шума.

Поэтому верная цель — меньше правил, но каждое измерено и у каждого есть владелец. Несопровождаемое правило теряет доверие и в итоге выключается — как раз в неудачный момент.

Основных метрик две: время от начала события до обнаружения и время от обнаружения до реакции.

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

Третья метрика встречается реже, но полезна: сколько алерт ждёт в очереди. Если она растёт, объём превысил ёмкость команды — а значит, пора пересматривать правила.

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

Это большая часть ручной работы аналитика. Её автоматизация сокращает время на один алерт в несколько раз.

Но если точность правила один к десяти, автоматизация даёт вам только более быстрый шум. Порядок такой: сначала точность, потом скорость.

Первый шаг — наладить измерение. Пусть при закрытии каждого алерта ставится отметка «настоящий или ложный». За две недели это даст первый реальный список.

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

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