В компании может быть много систем наблюдения.
ИТ-мониторинг показывает доступность сервисов, загрузку серверов, состояние каналов связи и приложений. SOC видит алерты безопасности, подозрительные действия, признаки компрометации, события из SIEM, EDR, NDR и XDR. Каждая команда смотрит на одну и ту же инфраструктуру, но видит ее через свой набор данных.
Проблема начинается в момент инцидента. Для ИТ-службы рост нагрузки может выглядеть как сбой производительности. Для ИБ тот же рост нагрузки может быть частью атаки. Для бизнеса это вообще не спор о классификации, а конкретное последствие: сервис работает хуже, клиентская операция не проходит, сотрудники теряют время, деньги начинают уходить в простой.
Пока ИТ и ИБ живут в отдельных контурах, компания получает не единую картину происходящего, а набор сигналов. Их нужно вручную связывать между собой, согласовывать, передавать из одной команды в другую и спорить, кто должен реагировать первым. В спокойной ситуации это кажется организационной мелочью. В инциденте это превращается в потерянное время.
Две команды могут расследовать один инцидент отдельно
Исторически информационная безопасность во многих компаниях выросла из ИТ-подразделения. Потом угроз стало больше, требования регуляторов усложнились, SOC стал отдельной функцией, появились собственные инструменты, бюджеты, процессы и метрики. Это было логичное развитие. Но вместе с ним усилился разрыв между эксплуатацией и защитой.
ИТ отвечает за доступность, производительность, емкость, сеть, стабильность приложений и восстановление сервисов. ИБ отвечает за атаки, доступы, расследования, выполнение требований и снижение рисков. На бумаге разделение понятное. На практике обе команды часто работают с одним событием, только называют его по-разному.
DDoS-атака хорошо показывает этот разрыв. ИТ-мониторинг фиксирует рост нагрузки на канал, сервер или приложение. Эксплуатация видит ухудшение показателей и пытается восстановить доступность. Команда ИБ в это же время видит аномальный трафик, подозрительные источники и признаки атаки. Если данные не сопоставляются, возникают два параллельных расследования: одно про производительность, другое про безопасность.
«ИТ и ИБ часто смотрят на одну инфраструктуру, но объясняют событие разными языками. Для эксплуатации это может быть рост нагрузки или ухудшение показателей сервиса, для SOC - признак атаки или компрометации. Если эти данные не связываются в одну картину, компания теряет время не на устранение причины, а на согласование того, что вообще происходит», - говорит Денис Назаренко, руководитель отдела технической поддержки продаж UDV Group.
Бизнесу в этот момент не важно, в каком контуре родился инцидент. Ему важно понять, что происходит с сервисом, как это влияет на клиентов и операции, кто управляет ситуацией и когда работа вернется в норму. Если ответа нет, технический спор между подразделениями становится управленческой проблемой.
Эксплуатационная телеметрия может быть ранним признаком атаки
SOC обычно строит собственный контур наблюдения. SIEM собирает события, EDR смотрит на конечные точки, NDR и NTA анализируют сетевую активность, XDR помогает связывать данные между несколькими слоями. Эти системы хорошо работают с признаками атаки, подозрительными действиями и аномалиями поведения.
Но корпоративный ITM часто остается в стороне от полноценного анализа в SOC. Между тем там лежит важный слой данных: загрузка CPU, рост сетевого трафика, заполнение диска, ухудшение времени отклика, нестандартная нагрузка на сервис, изменения в поведении приложения. Все это не обязательно означает атаку. Причиной может быть неудачный релиз, ошибка конфигурации, рост легитимной нагрузки или технический сбой.
Именно поэтому такие данные важны. Они помогают раньше увидеть отклонение и проверить, не связано ли оно с действиями атакующего. Иногда сигнатурные правила еще молчат, а инфраструктура уже ведет себя иначе. Сервер начинает активнее общаться с соседними узлами. Приложение внезапно потребляет больше ресурсов. Резко меняется сетевой профиль. Диск заполняется быстрее обычного. Для ИТ это может выглядеть как эксплуатационная проблема. Для ИБ это может быть начало инцидента.
Обратная ситуация возникает на стороне ITM. Система мониторинга хорошо показывает доступность серверов, состояние приложений, ресурсы и каналы. Но события из SIEM, EDR, NDR или XDR не всегда попадают в эксплуатационную картину. Для мониторинга это другой тип данных: другие форматы, другая логика обработки, другие сценарии доставки.
Просто перелить все алерты ИБ в ИТ-мониторинг нельзя. Так компания получит дорогую копию SOC, только с еще большим шумом. Смысл не в том, чтобы смешать все потоки, а в том, чтобы точечно связать значимые сигналы.
Самые опасные события выглядят штатно
Слепая зона чаще всего появляется там, где событие не похоже ни на классический отказ, ни на очевидную атаку. Например, ИТ-команда внедряет новый внутренний сервис, API-шлюз, прокси, ассистента или интеграцию для удобства пользователей. С точки зрения ITM все нормально: сервис доступен, нагрузка объяснима, пользователи получили нужную функцию.
Но если этот компонент выставлен наружу, подключен к критичным ресурсам или слабо защищен, для ИБ он уже становится потенциальной точкой входа. Мониторинг видит работоспособность. SOC может не видеть угрозу, пока не началась явная подозрительная активность. Между ними появляется риск, который не считается ни сбоем, ни подтвержденным инцидентом.
Такие ситуации особенно неприятны, потому что формально все участники правы. ИТ действительно запустила рабочий сервис. ИБ действительно еще не получила явного сигнала атаки. Но бизнес уже получил новый риск, о котором может узнать только после компрометации.
То же происходит с лишними доступами, небезопасными интеграциями, временными каналами подрядчиков, незащищенными прокси и внутренними сервисами, которые постепенно становятся критичными. Они не падают, не создают явной аварии и не всегда вызывают сигнатурный алерт. Но именно через них атакующий может пройти дальше.
«Самые сложные для расследования события часто выглядят штатными. Сервис доступен, нагрузка объяснима, пользовательская функция работает. Но если этот сервис выставлен наружу, связан с критичными ресурсами или имеет лишние доступы, для ИБ это уже не просто инфраструктурный объект, а возможный маршрут атаки», - отмечает Денис Назаренко, руководитель отдела технической поддержки продаж UDV Group.
Поэтому SOC должен видеть, какие инфраструктурные аномалии совпадают с подозрительной активностью. А ITM должен понимать, какие события безопасности могут повлиять на доступность сервиса. Только тогда рост нагрузки, странные соединения, изменение поведения приложения и алерты ИБ перестают быть разрозненными фактами и становятся признаками одного сценария.
Спор о зоне ответственности замедляет реакцию
Когда нет общей картины, инцидент быстро превращается в спор о принадлежности. Это инфраструктура? Приложение? Сеть? Действия пользователя? Атака? Ошибка релиза? Проблема провайдера? Пока команды ищут владельца, ситуация развивается.
ИТ может восстанавливать доступность, не понимая, что ухудшение показателей связано с атакой. ИБ может ограничивать активность ради безопасности, не видя, какие сервисы и бизнес-процессы затронет это действие. В результате команды двигаются в разных направлениях. Одна пытается вернуть сервис в работу, другая - остановить подозрительную активность. Обе решают важные задачи, но без общей модели могут мешать друг другу.
Для бизнеса это уже не техническая деталь. Это задержка реакции, риск лишнего простоя, противоречивые решения и отсутствие понятного владельца ситуации. Чем критичнее сервис, тем дороже становится такой разрыв.
Например, при подозрении на компрометацию учетной записи ИБ может предложить немедленно заблокировать доступ. Но если эта учетная запись используется в критичном технологическом или бизнес-процессе, простая блокировка может остановить работу. Обратная ошибка тоже опасна: сохранить доступность любой ценой и дать атакующему время на развитие.
В таких ситуациях нужен не спор, а заранее согласованная логика. Кто подтверждает инцидент. Кто оценивает влияние на сервис. Кто принимает решение об изоляции. Кто согласует отключение. Кто отвечает за восстановление. Какие данные должны быть переданы автоматически, а какие требуют ручного подтверждения.
Единую модель инцидента нужно строить до аварии
Начинать стоит не с большой интеграции ради интеграции, а с проверки совместного реагирования. Командам нужно отыграть реалистичные сценарии: DDoS, компрометация учетной записи, аномальная нагрузка на бизнес-приложение, подозрительная активность в сети, сбой критичного сервиса, неудачный релиз, утечка через внутренний сервис.
На таких учениях быстро видно, где возникают разрывы. Кто первым замечает событие. Какие данные использует. Кому передает информацию. Когда подключает соседний контур. По каким признакам повышает критичность. В какой момент бизнес получает понятное объяснение. Кто принимает решение, если безопасность требует ограничения доступа, а эксплуатация боится остановить сервис.
Результатом должна стать единая модель инцидента. Не абстрактная схема, а рабочий порядок: общий идентификатор события, согласованные уровни критичности, ответственные, схема эскалации, правила передачи информации между ITM и SOC, общий таймлайн и связь с бизнес-значимостью ресурса.
Важно заранее определить, какой контекст передается автоматически. Активы, связанные сервисы, инфраструктурные метрики, события безопасности, статус обработки, владелец ресурса, текущая критичность, бизнес-влияние. Чем больше такой информации появляется без ручных запросов, тем меньше времени уходит на первичную диагностику.
При этом единая картина не требует полной замены существующих ITM- и ИБ-систем. Практичнее использовать их как источники уже обработанных сигналов. ITM продолжает отвечать за инфраструктурную телеметрию. SOC - за события безопасности. Поверх этих контуров появляется слой корреляции, который связывает данные по активу, сервису, времени, инциденту и критичности.
Строить все напрямую на сырых данных можно, но это дорого и сложно. Придется заново решать задачи, которые уже выполняют действующие платформы: фильтрацию шума, нормализацию событий, первичную классификацию, обогащение и приоритизацию. Разумнее не заменять инструменты, а заставить их работать на одну модель ситуации.
Автоматизация не заменяет плейбук
Автоматическая корреляция снимает часть ручной работы, но не решает главный управленческий вопрос: что делать дальше. Для критичных ресурсов заранее должны быть описаны сценарии, где правило не может принять решение само. Изолировать узел или сохранить доступность. Ограничить доступ или не остановить процесс. Отключить компонент или оставить его работать под усиленным контролем. Переключиться на резерв или сначала собрать дополнительные данные.
Это особенно важно в гибридных инцидентах. Когда событие одновременно похоже на сбой и на атаку, простая автоматическая реакция может быть опасной. Слишком мягкое действие даст атаке развиться. Слишком жесткое - остановит сервис сильнее, чем сам инцидент.
Поэтому общая модель должна включать не только данные, но и совместные плейбуки реагирования. Кто принимает решение. Какие ограничения допустимы. Как быстро подключается владелец сервиса. Как бизнес узнает о последствиях. Как фиксируется выбранный сценарий. Как потом разбирается результат.
«Единая модель инцидента нужна не для того, чтобы объединить все алерты в одном интерфейсе. Ее задача - заранее договориться, как ИТ и ИБ принимают общее решение: что считать критичным, кто оценивает влияние на сервис, кто разрешает изоляцию и как бизнес понимает последствия выбранного действия», - подчеркивает Денис Назаренко, руководитель отдела технической поддержки продаж UDV Group.
Без такого плейбука даже хорошая корреляция останется аналитикой без управленческого действия. Команды будут видеть больше связей, но все равно спорить в критический момент.
Бизнес-центричность важнее внутренней эффективности
ИТ и ИБ часто оценивают себя по внутренним метрикам. У эксплуатации это доступность, SLA, скорость восстановления, число инцидентов, загрузка ресурсов. У безопасности - количество обработанных событий, время расследования, закрытые уязвимости, выполнение требований, снижение риска.
Все это важно. Но для бизнеса итоговая ценность проявляется иначе: непрерывность сервисов, понятная реакция, снижение последствий, быстрое восстановление и отсутствие хаоса в момент кризиса.
Поэтому эффективность совместной работы стоит оценивать по сквозным показателям. Сколько времени уходит на определение первопричины. Как быстро команды приходят к общей версии. Сколько инцидентов ушло в «пинг-понг» между ИТ и ИБ. Сколько раз из-за несогласованных действий ухудшилась доступность. Насколько снизилось число ложных тревог после добавления инфраструктурного контекста. Как быстро бизнес получает понятную оценку последствий.
Ни ИТ, ни ИБ не могут обеспечить этот результат в одиночку. ИБ зависит от ИТ при действиях на уровне инфраструктуры, приложений и доступов. ИТ без защитного контекста может лечить симптомы, не видя причины. Поэтому зрелость начинается не с очередного инструмента, а с управленческого сдвига: команды оценивают свою работу по тому, насколько быстро и согласованно защищают непрерывность бизнеса.
Контекст стоит дороже алерта
Современная компания уже не страдает от нехватки сигналов. У нее скорее обратная проблема: сигналов слишком много, а общей картины мало. Один алерт говорит о нагрузке, другой - о подозрительной авторизации, третий - о сетевой аномалии, четвертый - о снижении доступности приложения. Но пока они не связаны с активом, сервисом, владельцем, временем и бизнес-влиянием, это не инцидентная картина, а набор фрагментов.
В момент атаки или сбоя ценность дает не количество событий, а способность быстро ответить на несколько вопросов. Что произошло. Какой сервис затронут. Есть ли признаки атаки. Кто владелец системы. Что будет, если ограничить доступ. Сколько пользователей и операций пострадают. Какое действие остановит развитие инцидента и не создаст лишний ущерб.
Именно поэтому ИТ и ИБ должны смотреть не только на свои панели, но и на общую модель реальности. Не для того, чтобы стереть границы между функциями. А для того, чтобы в критический момент бизнес не выступал арбитром между двумя командами, каждая из которых права только в своем контуре.
Алерт сообщает, что что-то произошло. Контекст объясняет, что это значит. Управляемость начинается там, где компания умеет перейти от первого ко второму быстрее, чем инцидент успевает разрастись.
Комментарии