От алертов к контексту: почему ваши ИТ и ИБ смотрят на одну систему, но видят разные реальности

У компании может быть много инструментов мониторинга, защиты и реагирования, но при этом не быть единой картины инцидента. ITM видит доступность сервисов, нагрузку и состояние инфраструктуры, ИБ - атаки, аномалии и признаки компрометации. Пока эти контуры живут отдельно, бизнес получает не понятный сценарий происходящего, а набор сигналов, которые нужно вручную связывать между собой. Этот разрыв заметен и на уровне бизнес-оценки ИБ-функции. В исследовании The Edgers, SuperJob и PT Education более 40% CISO оценили зрелость своей роли на 8–9 баллов из 10, тогда как высокую оценку со стороны CEO получили только 25% директоров по информационной безопасности. Проблема не в том, что ИБ не работает, а в том, что ее результат часто остается внутри профессионального контура. Для бизнеса ценность безопасности проявляется через устойчивость сервисов, скорость решений и снижение последствий инцидента. О том, почему мониторинг и безопасность не складываются в единую картину, где между ними возникает слепая зона и как компаниям вернуть управляемость инцидентом, рассказал Денис Назаренко, руководитель отдела технической поддержки продаж UDV Group.

Мониторинг без защиты, безопасность без контекста

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

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

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

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

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

Почему данные мониторинга и безопасности не усиливают друг друга

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

SOC обычно строит собственный контур наблюдения за инфраструктурой безопасности: SIEM, EDR, NDR, XDR, средства анализа сетевой активности, а иногда и отдельный ИТ-мониторинг для ИБ-продуктов. Эти системы фиксируют алерты, подозрительные действия, признаки атаки или аномального поведения.

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

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

Обратная проблема возникает на стороне ITOM (IT Operations Management). Классический ITM хорошо показывает, жив ли сервер, отвечает ли приложение, хватает ли ресурсов, доступен ли канал. Но события из SIEM, EDR, NDR или XDR обычно не становятся частью этой системы наблюдения. Для ITM это данные другого типа: у них другие форматы, другая логика обработки и другие сценарии доставки.

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

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

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

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

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

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

Единая модель инцидента вместо спора о зоне ответственности

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

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

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

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

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

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

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

Главный критерий - бизнес-центричность

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

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

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