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

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

«ИТ и ИБ часто смотрят на одну инфраструктуру, но объясняют событие разными языками. Для эксплуатации это может быть рост нагрузки или ухудшение показателей сервиса, для SOC — признак атаки или компрометации. Если эти данные не связываются в одну картину, компания теряет время не на устранение причины, а на согласование того, что вообще происходит», — сообщает «Код Дурова».

Пока ИТ и ИБ работают в отдельных контурах, компания получает разрозненные сигналы, которые приходится вручную связывать и согласовывать. Это приводит к потере времени во время инцидентов. Исторически информационная безопасность развивалась из ИТ-подразделений, но с ростом угроз и требований регуляторов SOC стал отдельной функцией со своими инструментами и процессами, что усилило разрыв между эксплуатацией и защитой.

ИТ отвечает за доступность, производительность, емкость, сеть, стабильность приложений и восстановление сервисов. ИБ отвечает за атаки, доступы, расследования, выполнение требований и снижение рисков. На практике обе команды часто работают с одним событием, но называют его по-разному. Например, при DDoS-атаке ИТ-мониторинг фиксирует рост нагрузки, а ИБ видит аномальный трафик и признаки атаки. Если данные не сопоставляются, возникают два параллельных расследования.

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

Эксплуатационная телеметрия может быть ранним признаком атаки. SOC обычно строит собственный контур наблюдения, собирая события из SIEM, EDR, NDR, NTA и XDR. Однако корпоративный ITM часто остается в стороне от полноценного анализа в SOC, хотя там содержится важный слой данных: загрузка CPU, рост сетевого трафика, заполнение диска, ухудшение времени отклика, нестандартная нагрузка на сервис, изменения в поведении приложения. Эти данные помогают раньше увидеть отклонение и проверить, не связано ли оно с действиями атакующего.

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

«Самые сложные для расследования события часто выглядят штатными. Сервис доступен, нагрузка объяснима, пользовательская функция работает. Но если этот сервис выставлен наружу, связан с критичными ресурсами или имеет лишние доступы, для ИБ это уже не просто инфраструктурный объект, а возможный маршрут атаки», — отмечает «Код Дурова».

Слепая зона чаще всего появляется там, где событие не похоже ни на классический отказ, ни на очевидную атаку. Например, новый внутренний сервис может быть работоспособным с точки зрения ITM, но для ИБ он может стать потенциальной точкой входа, если выставлен наружу или слабо защищен. Такие ситуации неприятны, потому что формально все участники правы, но бизнес получает новый риск. Поэтому SOC должен видеть, какие инфраструктурные аномалии совпадают с подозрительной активностью, а ITM должен понимать, какие события безопасности могут повлиять на доступность сервиса.

Когда нет общей картины, инцидент быстро превращается в спор о зоне ответственности. Пока команды ищут владельца, ситуация развивается. ИТ может восстанавливать доступность, не понимая, что ухудшение показателей связано с атакой. ИБ может ограничивать активность ради безопасности, не видя, какие сервисы и бизнес-процессы затронет это действие*. В результате команды двигаются в разных направлениях, что приводит к задержке реакции, риску лишнего простоя и противоречивым решениям.

Единую модель инцидента нужно строить до аварии. Начинать стоит с проверки совместного реагирования, отрабатывая реалистичные сценарии. На таких учениях быстро видно, где возникают разрывы, кто первым замечает событие, какие данные использует и кому передает информацию. Результатом должна стать единая модель инцидента: общий идентификатор события, согласованные уровни критичности, ответственные, схема эскалации, правила передачи информации между ITM и SOC, общий таймлайн и связь с бизнес-значимостью ресурса.

Важно заранее определить, какой контекст передается автоматически: активы, связанные сервисы, инфраструктурные метрики, события безопасности, статус обработки, владелец ресурса, текущая критичность, бизнес-влияние. Чем больше такой информации появляется без ручных запросов, тем меньше времени уходит на первичную диагностику. Единая картина не требует полной замены существующих ITM- и ИБ-систем. Практичнее использовать их как источники уже обработанных сигналов, а поверх этих контуров создать слой корреляции, который связывает данные по активу, сервису, времени, инциденту и критичности.

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

«Единая модель инцидента нужна не для того, чтобы объединить все алерты в одном интерфейсе. Ее задача — заранее договориться, как ИТ и ИБ принимают общее решение: что считать критичным, кто оценивает влияние на сервис, кто разрешает изоляцию и как бизнес понимает последствия выбранного действия», — подчёркивает «Код Дурова».

ИТ и ИБ часто оценивают себя по внутренним метрикам, но для бизнеса итоговая ценность проявляется в непрерывности сервисов, понятной реакции, снижении последствий, быстром восстановлении и отсутствии хаоса в момент кризиса. Эффективность совместной работы стоит оценивать по сквозным показателям: времени на определение первопричины, скорости достижения общей версии, числу инцидентов, ушедших в «пинг-понг», и снижению ложных тревог.

Ни ИТ, ни ИБ не могут обеспечить этот результат в одиночку. ИБ зависит от ИТ при действиях на уровне инфраструктуры, а ИТ без защитного контекста может лечить симптомы, не видя причины. Зрелость начинается с управленческого сдвига: команды оценивают свою работу по тому, насколько быстро и согласованно защищают непрерывность бизнеса.

Современная компания страдает от избытка сигналов, но нехватки общей картины. Алерт сообщает, что что-то произошло, но контекст объясняет, что это значит. Управляемость начинается там, где компания умеет перейти от первого ко второму быстрее, чем инцидент успевает разрастись.

*Минюст России включил «Действие» в реестр иностранных агентов

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе всех новостей и событий Рунета.