Время обнаружения кибератак: 6 факторов скорости реакции

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

Цифры это подтверждают. В отчёте IBM Cost of a Data Breach Report 2024 среднее время выявления утечки данных составило 194 дня. В M-Trends 2025 медианное время скрытого присутствия атакующего — 11 дней. На первый взгляд показатели противоречат друг другу. На практике они показывают одну и ту же проблему: компании считают разные часы и часто обнаруживают не атаку, а уже её последствия.

Термин «военный уровень шифрования» здесь не поможет. Шифрование не обнаруживает компрометацию учётной записи, EDR не заменяет процесс реагирования, а SIEM с тысячами алертов легко превращается в цифровой шум. Скорость реакции определяется не наличием модного продукта в закупочной ведомости, а тем, насколько быстро инфраструктура превращает подозрительный сигнал в подтверждённый инцидент и действие.

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

Первый фактор — не искусственный интеллект и не очередной продукт с логотипом в виде щита. Это видимость.

Если организация не знает, какие сервисы опубликованы наружу, какие учётные записи имеют административные права и где хранятся журналы событий, разговор о MTTD становится бухгалтерией по несуществующим данным. Система может работать штатно только на бумаге. В реальной сети атакующий уже использует забытый VPN-шлюз, старый веб-сервис или сервисную учётную запись без MFA, а SOC продолжает смотреть на несколько аккуратно подключённых источников.

Минимальный набор телеметрии для корпоративной инфраструктуры обычно включает:

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

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

Именно здесь часто ломается маркетинговая конструкция «у нас всё защищено». Агент установлен на рабочих станциях, но серверы работают без EDR. SIEM получает логи контроллера домена, но не видит облачную почту. VPN отправляет события, но не передаёт идентификатор пользователя. В итоге система безопасности наблюдает не инфраструктуру, а её рекламный макет.

Невидимый актив — это не защищённый актив. Это подарок атакующему, который ещё не попал в инвентаризационную ведомость.

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

2. Качество детектирования: алерт не равен обнаружению

Вторая причина долгого времени выявления угроз — плохая аналитика. Компании часто считают обнаруженными все события, на которые система когда-либо выдала уведомление. Это удобная статистика. И почти бесполезная.

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

На практике скорость обнаружения ограничивают четыре свойства детектов:

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

2. Приоритет. Не все события требуют одинаковой срочности. Отклонённый вход и отключение EDR на контроллере домена не должны попадать в одну очередь.

3. Устойчивость к обходу. Хороший детект ищет не только имя известного файла или хеш. Малварь переименуют. Инструмент упакуют. Команду запустят через легитимный интерпретатор. Поведенческая аналитика здесь полезнее коллекции сигнатур.

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

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

MTTD в такой среде нужно считать по этапам:

• время от первого подозрительного события до срабатывания правила;
• время от алерта до его попадания в очередь аналитика;
• время первичной квалификации;
• время подтверждения инцидента;
• время передачи в команду реагирования.

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

3. Процессы SOC и дежурная смена: скорость определяется не инструментом, а маршрутом

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

Плохой процесс выглядит узнаваемо:

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

Формально SOC работал. Фактически он занимался пересылкой сообщений.

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

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

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

Здесь появляется разница между MTTD и временем реакции. MTTD отвечает на вопрос, когда угрозу заметили. Он не говорит, когда ограничили доступ, остановили распространение и начали восстановление. Можно обнаружить атаку быстро и провалить сдерживание из-за отсутствия прав, контактов и понятного регламента.

IBM в отчёте за 2024 год оценивал среднее время сдерживания инцидента в 64 дня. Это не продолжительность каждой атаки и не норма для конкретной компании. Но показатель хорошо демонстрирует разрыв между «мы увидели подозрительную активность» и «угроза перестала влиять на систему». Между этими фразами иногда лежит полноценная авария.

4. Автоматизация и ИИ: ускоритель, а не индульгенция

Четвёртый фактор — автоматизация. По данным, приведённым в исследованиях IBM и связанных с ними аналитических материалах, организации, активно использующие ИИ и автоматизированные средства защиты, обнаруживали и ликвидировали инциденты в среднем на 98–100 дней быстрее компаний без такой автоматизации.

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

Полезная автоматизация в ИБ закрывает конкретные операции:

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

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

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

Сервисная модель MDR показывает, насколько важна не только технология, но и скорость передачи информации. В MDR Kaspersky среднее время от первичного детектирования до уведомления клиента о критическом инциденте сократилось до 42 минут. Это уже операционный показатель, а не обещание из рекламного буклета. Однако уведомление за 42 минуты всё ещё не означает, что компания за 42 минуты закрыла все каналы атаки. Клиент должен иметь готовый процесс действий после звонка или сообщения.

Сравнение подходов выглядит так:

Автоматизация не делает слабую защиту зрелой. Она просто позволяет быстрее понять, насколько процесс был не готов.

5. Начальный вектор атаки: эксплойт и учётные данные по-прежнему работают

Пятый фактор — то, с чего начинается атака. В M-Trends 2025 эксплуатация уязвимостей составила 33% начальных векторов, а компрометация учётных данных — 16%. Это не повод списывать всё на фишинг и закупать ещё один тренажёр для сотрудников.

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

С компрометацией учётных данных ситуация ещё неприятнее. Пароль может быть достаточно длинным, но это не спасает, если:

• токен уже украден;
• сессия не отзывается после смены пароля;
• MFA включена только для части пользователей;
• администратор работает из обычной пользовательской среды;
• сервисная учётная запись не имеет владельца;
• доступ подрядчика не закрывается после завершения работ;
• облачные API-токены живут дольше, чем нужно для операции.

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

В корпоративной среде стоит разделять как минимум три класса событий:

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

2. Компрометация личности. Вход из нетипичной среды, массовая смена правил почты, регистрация нового приложения, использование токена из другой географии или автономной системы.

3. Внутреннее распространение. Доступ к нескольким хостам, обращение к административным ресурсам, извлечение учётных данных, изменение политик домена.

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

6. Регламенты и нормативы: три часа — это не время на размышления

Шестой фактор — формальные обязательства и внутренняя дисциплина. Для субъектов критической информационной инфраструктуры в России нормативный срок первичного уведомления ГосСОПКА и НКЦКИ об инциденте безопасности составляет не более трёх часов.

Это не означает, что любой коммерческий сервис обязан сообщать об инциденте в течение трёх часов. Универсальной нормы для всех компаний вне КИИ и отдельных регулируемых отраслей нет. Но для организации, которая относится к субъектам КИИ, трёхчасовой срок превращает обнаружение в управляемую процедуру, а не в задачу «сначала разберёмся, потом решим».

Чтобы выдерживать такие сроки, компания должна заранее знать:

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

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

Метрики тоже должны быть разделены. Внутри процесса полезно отслеживать:

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

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

Почему MTTD 194 дня и dwell time 11 дней не противоречат друг другу

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

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

Dwell time — время скрытого присутствия атакующего до обнаружения или момента, когда его активность была зафиксирована. Mandiant в M-Trends 2025 приводит глобальное медианное значение 11 дней за 2024 год.

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

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

Для внутренней отчётности компания должна сама зафиксировать точки отсчёта. Например:

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

Без таких определений MTTD превращается в метрику для презентации совету директоров. Выглядит строго. Проверить невозможно.

Что действительно сокращает время обнаружения

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

Сначала закрыть слепые зоны

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

Затем определить активы, отсутствие телеметрии по которым недопустимо. Для большинства компаний это контроллеры домена, системы удалённого доступа, облачная идентификация, почта, файловые хранилища и рабочие места администраторов.

Затем настроить несколько сценариев, а не тысячу правил

Начинать стоит с цепочек, которые соответствуют реальным рискам:

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

Такой подход полезнее бесконечного импорта сигнатур. Сигнатура знает, что файл плохой. Поведенческий сценарий пытается понять, что происходит с системой.

После этого убрать ручные задержки

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

Для внешнего мониторинга нужно закрепить понятный SLA уведомления. В MDR-сервисах можно ориентироваться на показатель в 42 минуты для уведомления о критичном инциденте, но переносить его на любую организацию механически нельзя. У компании может не быть круглосуточной смены, а у подрядчика — доступа к необходимым данным. В результате договор будет быстрым только на бумаге.

Наконец, измерять не количество алертов

Большое число закрытых уведомлений не доказывает эффективность SOC. Система должна отвечать на другие вопросы:

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

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

Жёсткие рекомендации по настройке политики безопасности

1. Зафиксировать определения MTTD, времени квалификации и времени сдерживания. Не смешивать их в одну красивую цифру и не называть MTTR тем, что на самом деле является временем обнаружения.

2. Подключить к мониторингу не только рабочие станции, но и идентификацию, VPN, облачные сервисы, серверы и средства удалённого администрирования. Один EDR на ноутбуках не даёт видимости корпоративной сети.

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

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

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

6. Настроить playbook для компрометации учётной записи, отключения EDR, эксплуатации внешнего сервиса и массовой выгрузки данных. Эти сценарии должны приводить к конкретным действиям, а не к созданию тикета.

7. Контролировать false positives и держать их долю ниже рабочего ориентира в 15%. Если аналитики тонут в шуме, добавление новых детектов ухудшит ситуацию.

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

9. Для субъектов КИИ встроить трёхчасовой срок уведомления ГосСОПКА и НКЦКИ в операционный регламент. Ответственный и резервный ответственный должны быть назначены до инцидента.

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

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

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