Сколько стоят ложные срабатывания в SOC: метрики, экономика и пошаговый план снижения

Ложные срабатывания — это измеримая проблема. Доля таких срабатываний (FPR), точность детектирования и нагрузка на аналитика — вот три показателя, которые показывают, насколько эффективно работает центр управления безопасностью (SOC). В статье рассказываем, как считать эти метрики и расходы на разбор ложных алертов, с чего начать автоматизацию, чтобы сократить «шум», не увеличивая при этом риск пропустить реальную атаку.

Сколько вы теряете на ложных срабатываниях

Ложноположительное срабатывание (ЛПС) — это алерт, который система создала, но реальной угрозы за ним нет. Само по себе это не страшно, проблема начинается, когда таких алертов становится много — в некоторых SOC их доля доходит до 80–90% от общего потока.

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

Как посчитать стоимость одного ложного срабатывания

Формула такая: стоимость одного FPR = (зарплата аналитика в час) × (время на обработку одного алерта в часах).

Разберем на примере. В SOC работает 5 аналитиков первой линии. Предположим, что каждый получает 150 000 рублей в месяц. С учетом накладных расходов (налоги, аренда, софт, администрирование) эта цифра вырастает примерно до 250 000 рублей в месяц на человека.

В месяце в среднем 22 рабочих дня, в день — 8 часов. Получается, что час работы одного аналитика стоит около 1500 рублей. Возьмем для примера среднее время на проверку одного алерта — 10 минут, то есть 0,17 часа.

Значит, стоимость одного разобранного алерта: 1500 × 0,17 = 255 рублей

Теперь посчитаем масштаб. В день в SOC приходит 1000 алертов. Из них 80% — ложные. Это 800 пустых уведомлений в день.

Затраты на них: 800 × 255 = 204 000 рублей в день. За 22 рабочих дня: 204 000 × 22 = 4 488 000 рублей

За год: 4 488 000 × 12 ≈ 54 миллиона рублей. 

Но это только одна сторона. У этих 54 миллионов есть альтернатива — стоимость пропущенного инцидента. По данным InfoWatch, средний ущерб от утечки данных в России составляет 11,5 млн рублей, а максимальный превышает 41 млн. К этому добавляются затраты на расследование. Поэтому оптимизация ЛПС — это не столько про экономию на аналитиках, сколько про баланс: снизить шум, не потеряв чувствительность к реальным атакам. 

Что дает эта цифра

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

Также можно будет оценивать эффект от каждого изменения: снизили FPR на 10% — получили конкретную сумму экономии.

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

Пример из практики. В одной компании-разработчике ПО штат аналитиков первой линии составлял 6 человек. За смену они обрабатывали около 1200 алертов, доля ложных срабатываний достигала 85%. После внедрения автоматического триажа и пересмотра правил корреляции FPR снизился до 40%. Экономия за год превысила 30 миллионов рублей. Освободившееся время команда направила на охоту за угрозами и анализ новых сценариев атак, то есть на то, что действительно приносит пользу бизнесу.

Какие метрики реально работают

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

Доля ложных срабатываний (False Positive Rate, FPR)

Это отношение ложных срабатываний к общему числу алертов.

Формула: FPR = FP / (FP + TP), где FP — ложные, TP — истинные.

Например, за день пришло 1000 алертов. Аналитики проверили и признали 900 ложными, 100 — реальными инцидентами. FPR = 90%. Это значит, что 90% рабочего времени команда тратит на разбор пустых уведомлений. Из 12-часовой смены почти 11 часов уходят впустую.

Если FPR выше 20% — уже есть над чем работать. Выше 50% — система практически не помогает, а мешает. В запущенных центрах управления безопасностью доходит до 90–95%.

Важный нюанс. Чтобы посчитать FPR, нужно знать, сколько алертов оказались истинными (TP). А это становится понятно только после того, как аналитик проверил алерт и подтвердил инцидент. Поэтому метрика строится на обратной связи от команды: каждый закрытый тикет должен содержать пометку — ложный или истинный.

Точность детектирования (Precision)

Показывает, какая доля алертов действительно указывает на инцидент. Другими словами, если система выдала алерт, с какой вероятностью это реальная угроза.

Формула: Precision = TP / общее число алертов 

Например, вчера система создала 200 алертов. После проверки 50 оказались реальными инцидентами, 150 — ложными. Precision = 50 / (50 + 150) = 25%. Это означает, что каждый четвертый алерт — настоящая угроза. Остальные три — пустая трата времени.

Чем отличается от FPR. FPR говорит о доле ложных среди всех алертов. Precision — о том, насколько можно доверять конкретному алерту. Если Precision низкая, аналитик перестаёт верить системе, даже когда она действительно что-то нашла, — и проще пропускает реальную атаку.

Важный нюанс: Precision не учитывает ложноотрицательные срабатывания (FN) — случаи, когда система не заметила угрозу. Поэтому по нему оценивают нагрузку на команду, а не эффективность детектирования в целом. Для полноты картины Precision смотрят в связке с FPR и числом пропущенных инцидентов.

Нагрузка на аналитика

Тут надо ответить на вопрос: сколько алертов в смену обрабатывает один специалист. Например, в центре управления безопасностью работает 5 аналитиков первой линии. За 12-часовую смену приходит 500 алертов. На каждого — 100 алертов. Это уже критический порог. 

Указанная цифра — средняя. Если алерты сложные и требуют глубокого анализа, порог снижается. Если простые и однотипные, может быть выше. Но 80–100 — тот ориентир, при котором стоит начинать беспокоиться.

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

Как эти метрики работают в связке

FPR показывает, сколько шума создает система. Precision — насколько этому шуму можно доверять. Нагрузка — в каком состоянии находится команда.

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

Рекомендуем собирать эти цифры каждую неделю и сравнивать динамику. Если FPR и нагрузка растут, а Precision падает — система деградирует. Значит, пора вмешиваться.

Информационная безопасность бизнеса

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

Оставить заявку

Что делать с метриками: три шага к порядку

Шаг 1. Замерить текущее состояние

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

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

Также сравните показатели по разным источникам данных. Бывает, что одно правило дает 90% шума только потому, что источник логирует события с ошибками. Если так, то сначала чините источник, а не правило. Обязательно зафиксируйте текущие цифры как отправную точку (baseline), чтобы потом было с чем сравнивать.

Шаг 2. Настроить самые шумные правила

Возьмите топ-3–5 правил по числу ложных срабатываний. Для каждого разберитесь, что именно вызывает ложные алерты. Часто проблема не в самом правиле, а в отсутствии исключений для конкретных сервисов или учетных записей.

Проверьте:

• можно ли уточнить временные окна или пороговые значения
• какие легитимные операции попадают под правило (резервное копирование, обновления, служебные аккаунты) — добавьте их в исключения
• не дублируется ли правило с другим, создавая двойные алерты на одно событие

Вносите изменения по одному, а не все сразу. Иначе не поймете, что именно сработало. После настройки дайте системе поработать 2–3 дня и снова замерьте метрики. Если доля ложных срабатываний снизилась хотя бы на 10–20%, вы на правильном пути. Если нет, значит, причина глубже. Возможно, не хватает контекста или источников данных, а может быть, само правило построено на неверной гипотезе. Тогда его лучше пересмотреть с нуля или временно отключить, пока не появится решение.

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

Шаг 3. Внедрить автоматический триаж для остальных

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

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

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

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

В результате вы получите автоматическое закрытие 50–70% ложных срабатываний без участия человека. Аналитики перестанут тонуть в потоке и смогут заниматься тем, что действительно важно: поиском новых угроз, анализом новых сценариев атак и развитием системы мониторинга.

Реклама 16+

Расследуйте инциденты со Staffcop

Выявляйте и расследуйте утечки, мошенничество и другие инциденты, происходящие по вине сотрудников.

Оставить заявку

Автоматизация: как снизить нагрузку на аналитиков

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

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

Оркестрация и автоматизация реагирования

SOAR (Security Orchestration, Automation and Response) — это платформа, которая связывает SIEM, инструменты управления инцидентами и средства реагирования.

Что дает SOAR:

• автоматический сбор данных из разных источников по одному алерту
• запуск плейбуков — заранее прописанных сценариев реагирования
• автоматическое обогащение контекста
• формирование отчётов

Вместо того чтобы вручную собирать информацию по инциденту из пяти разных систем, аналитик получает готовую картину. Или вообще не получает, если SOAR закрыл инцидент автоматически.

На что обратить внимание. SOAR эффективен, когда сценарии реагирования четко прописаны. Если процессы в компании не формализованы, внедрение SOAR может разочаровать. Начните с простых плейбуков для типовых инцидентов, например, блокировка подозрительного IP или учётной записи, и только потом усложняйте.

Машинное обучение для фильтрации

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

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

Для обучения модели нужна качественная разметка — каждый закрытый тикет должен содержать пометку: ложный или истинный. Без этого модель не сможет отличить паттерны ложных срабатываний от реальных угроз. 

База знаний типовых ложных срабатываний

Если аналитик уже потратил час на расследование конкретного типа ложного срабатывания, зачем тратить еще час на следующее такое же?

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

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

Как справиться с усталостью от алертов и сохранить команду SOC

Признаки усталости от алертов у аналитиков

Alert fatigue — состояние, когда у аналитика вырабатывается рефлекс быстро закрывать алерты, лишь бы очистить очередь.

Основные признаки:

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

По данным отраслевых исследований, большинство SOC-аналитиков сталкиваются с выгоранием. В России проблема стоит так же остро: эксперты на SOC Forum 2025 назвали высокий уровень стресса и выгорание одной из главных угроз для команд.

Ложные срабатывания — один из главных драйверов этого состояния. Чем больше шума, тем быстрее команда теряет мотивацию и профессионализм.

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

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

Процесс выстраивают так:

• простые, однотипные алерты отдают младшим аналитикам (L1) — они требуют минимальной квалификации и быстрого закрытия;
• сложные расследования, требующие анализа нескольких источников, передают старшим (L2 и L3);
• внедряют ротацию: чередуют обработку входящего потока с проектной работой и threat hunting — это дает передышку от рутины и поддерживает интерес к работе.

Когда нагрузка распределена с учетом сложности, аналитики не перегорают, а инциденты обрабатываются быстрее и качественнее.

Внедрение мотивации

Когда аналитик видит не бесконечную ленту алертов, а понятные цели и обратную связь, качество работы растет.

Что можно внедрить:

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

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

Что делать прямо сейчас: чек-лист для руководителя SOC

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

Начните считать. Без метрик вы не поймёте, где теряете время и деньги. Посчитайте FPR, Precision и нагрузку на аналитика за последнюю неделю. Увидите проблемные правила — возьмите их в работу.

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

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

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

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