Журнал "Information Security/ Информационная безопасность" #1, 2026

Речь не об абстрактных рассуждениях, а о вполне конкретном феномене: штат- ные функции инженерных протоколов могут использоваться для нанесения физического урона инфраструктуре. При этом классический SOC, ориентирован- ный на мониторинг трафика North-South и вооруженный SIEM, такие атаки чаще всего пропускает. Откуда взялась проблема? Лет пятнадцать назад инженерные системы ЦОД существовали в изолиро- ванном контуре. Проприетарные шины, аналоговые датчики, отдельные пульты управления создавали массу неудобств для эксплуатации, но гарантированно защищали от сетевых атак хотя бы за счет отсутствия подключения к сети. Запрос рынка на централизацию управления и удаленный мониторинг сделал свое дело. Производители OT- оборудования, такие как Schneider Elec- tric, Siemens, Vertiv, пошли по пути кон- вергенции. Контроллеры получили стан- дартные ОС, Ethernet-порты и веб-интер- фейсы. Этот переход проходил без орга- ничного усвоения культуры информа- ционной безопасности. Приоритетом оставалась отказоустойчивость – MTBF, резервирование каналов. Но на втором плане оказались управление уязвимо- стями, регулярное обновление прошивок, безопасная разработка. В результате инженерные системы получили весь набор уязвимостей корпоративных ИТ- систем, но сохранили детскую наивность промышленных протоколов, заклады- вавшихся в эпоху, когда о сетевых атаках никто не думал. Как это работает? Ключевая проблема – в свойствах протоколов управления инженерными системами: BACnet/IP и Modbus/TCP. Они создавались для замкнутых сред и не предусматривают аутентификации критических команд. На конференции Black Hat USA в 2016 г. исследователи Кристофер Уэйд и Крис Уильямс продемонстрировали: любой узел в одном сегменте сети с BACnet-устрой- ством может отправить контроллеру команду WriteProperty и изменить его пара- метры. Никакого взлома, только штатный функционал протокола. Цепочка событий выглядит так. Фишинг открывает доступ в офисный сегмент. Дальше – движение в сторону слабо сег- ментированной сети инженерной инфра- структуры (BMS), к которой часто имеют доступ подрядчики. Сканирование, обна- ружение BACnet-устройств, отправка команды на повышение порогового значения температуры в чиллере. Тем- пература в зоне серверных стоек растет, срабатывает аварийная защита – стойка или модуль обесточиваются. Формально атака не оставляет следов: все действия выполнены легитимными командами из авторизованного сегмента. Вспомним масштабный инцидент в Южной Корее в сентябре 2025 г., когда за несколько часов до проверки ЦОД на предмет хакерского взлома в машинном зале вспыхнул пожар, уничтоживший серверы местных госуслуг. Официальная причина – техническое возгорание, но хронология событий заставила экспертов говорить о неслучайности совпадения. Почему не работает мониторинг? Здесь возникает закономерный вопрос: почему SIEM и SOC не видят таких атак? По данным экспертов, спе- циализирующихся на OT-безопасности, большинство инцидентов в конвергент- ных средах обнаруживаются не по дан- ным мониторинга, а по физическим последствиям – задымлению, срабаты- ванию пожарной сигнализации или ава- рийному отключению оборудования. Аналитики SOC обучены выявлять аномалии в HTTP, DNS, SQL-трафике. Но Modbus и BACnet для них – терра инкогнита. Этот трафик либо не попадает в периметр мониторинга, либо воспри- нимается как легитимный шум инже- нерных систем. Сигнатурные IPS не содержат правил на команды WriteProp- erty – формально это не эксплуатация уязвимости, а разрешенная операция. Что можно сделать? Проблема не решается простой уста- новкой патча или закупкой очередного сканера. Но есть несколько рабочих направлений. 1. Сегментация OT-сетей на уровне, исключающем бесконтрольный доступ из корпоративного сегмента к инженер- ным системам. Физическая или логиче- ская изоляция сетей BMS/DCIM должна стать стандартом – таким же обязатель- ным, как выделение DMZ. 2. Инструментальное. Нужны решения класса NDR, которые понимают семан- тику промышленных протоколов. Мони- торинг должен сместиться с учета паке- тов на анализ содержания команд: изме- нение уставки температуры, переключе- ние фаз питания, отключение вентиля- торных групп – эти события должны вызывать реакцию SOC. 3. Организационное. Модель взаимо- действия команд ИБ и инженерной экс- плуатации нуждается в пересборке. Кросс-функциональное обучение, совместные учения и единая система классификации событий – изменение параметра в BACnet-протоколе должно расцениваться как инцидент, потенци- ально ведущий к отказу оборудования. Проблема киберфизической уязвимо- сти ЦОД не решится сама собой. Инже- нерная инфраструктура – это уже не просто железо, она стала полноценным участником сетевого взаимодействия, и относиться к ней нужно соответственно. А пока мониторинг инженерных прото- колов не стал рутиной, атаки на физи- ческую инфраструктуру будут оставаться за пределами видимости. l 42 • СПЕЦПРОЕКТ Инженерная инфраструктура ЦОД: новый фронт работ для ИБ профессиональной среде принято считать ЦОД образцом конт- ролируемой среды. Многоуровневый физический периметр, строгий СКУД, видеонаблюдение – все это создает ощущение тотального контроля. Однако за последние несколько лет кон- фигурация угроз заметно сместилась. Физическая инфра- структура дата-центров – чиллеры, ИБП, прецизионные кон- диционеры, интеллектуальные блоки розеток – окончательно стала цифровой и, что существенно, сетевой. И, судя по доступным данным, с защитой этих систем есть проблемы. В Алексей Карабась, эксперт по сетевой безопасности в ЦОД Фото: А. Карабась