34% систем управления инфраструктурой ЦОД работают на устаревших прошивках

Одновременно 84% BMS обмениваются данными по небезопасным протоколам, а 800 устройств содержат известные эксплуатируемые уязвимости из категории KEV. Годом ранее исследование BMS в 529 организациях показывало другую сторону той же проблемы: 72% компаний эксплуатировали BMS с KEV, у 66% организаций присутствовали уязвимости, которые ранее использовались в ransomware-атаках, а у 48% такие уязвимости сочетались с небезопасным подключением к сети. Устаревшая прошивка опасна именно в сочетании с открытым протоколом и доступом из соседнего сегмента сети – а именно так выглядит типичная BMS. 

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

Кроме того, значительная часть оборудования проектировалась в расчете на закрытую технологическую сеть, где основным требованием была стабильность обмена данными. Отсюда широкое распространение BACnet, MODBUS и других протоколов, в базовых реализациях которых отсутствуют привычные для IT-среды механизмы аутентификации и шифрования. 84% BMS используют небезопасные протоколы, причем BACnet применяется примерно на 42% таких систем. Это значит, что даже свежая прошивка не решает проблему целиком: обновление закрывает уязвимости в коде, но не меняет архитектуру протокола без аутентификации. Для систем мониторинга электропитания доля небезопасных протоколов составляет 82%, для UPS – 86%, для OT-контроллеров – 85%. В результате проблема старой прошивки редко существует изолированно. Одно устройство может одновременно иметь неподдерживаемую версию ПО, доступную для эксплуатации уязвимость и возможность принимать команды по протоколу, который изначально не предусматривает полноценной проверки отправителя.

Разбивка по векторам атак показывает, что прямое подключение BMS к интернету представляет лишь один из сценариев. Из 66 395 исследованных BMS напрямую доступны из внешней сети 369 устройств, то есть менее 1%. Вместе с этим, реальный сценарий атаки — не сканирование интернета, а один шаг lateral movement из уже скомпрометированного IT-сегмента. Гораздо существеннее риск перемещения злоумышленника из уже скомпрометированного сегмента. В отдельной выборке инфраструктуры ЦОД 5 410 из 39 335 BMS, или 14%, находились всего в одном сетевом переходе от системы, связанной с интернетом. Для PDU этот показатель достигает 41%, для HVAC – около трети. Поэтому первым вектором остается компрометация смежного IT-, IoT- или сетевого узла с последующим lateral movement в технологический сегмент. Второй вектор связан с эксплуатацией известных уязвимостей в старых версиях прошивок. Третий – с воздействием непосредственно на технологический обмен через BACnet, MODBUS и другие протоколы без достаточной аутентификации. Еще один сценарий формируют средства удаленного администрирования и подрядчики, которым требуется доступ к BMS для обслуживания оборудования. Исследование BMS 2025 года отдельно относит неуправляемый сторонний удаленный доступ, открытые сетевые порты, слабую аутентификацию и неподдерживаемые версии ПО к характерным проблемам таких сред.

Ситуацию осложняет организационное устройство эксплуатации ЦОД. Инженерная инфраструктура нередко находится в зоне ответственности служб, для которых приоритетами служат доступность, температурный режим, энергопотребление и выполнение SLA. ИБ-подразделение при этом может видеть серверы, сетевое оборудование и корпоративные системы, но не иметь такой же полноты данных о версиях прошивок контроллеров, шлюзов и BMS. Часть устройств устанавливается интеграторами или поставщиками инженерных систем и годами работает без пересмотра исходной конфигурации. Это создает сложный парк оборудования разных поколений, где одномоментное обновление невозможно. Наличие резервного оборудования само по себе проблему не закрывает: основной и резервный контроллеры могут иметь одинаковую версию прошивки и один набор уязвимостей. Если атакующий эксплуатирует эту уязвимость, откажут оба контроллера одновременно, резервирование страхует от отказа оборудования, но не от кибератаки. Именно поэтому наличие физического резервирования нельзя автоматически считать защитой от киберинцидента, связанного с эксплуатацией программной ошибки.

Самая высокая доля устаревших прошивок обнаружена в системах мониторинга электропитания – 59%. Далее идут OT-системы управления с 48%, BMS с 40%, IoT и интеллектуальные датчики с 37% и UPS с 23%. Для операторов коммерческих и colocation-ЦОД особенно чувствительны BMS, PDU и охлаждение, поскольку нарушение их работы затрагивает одновременно инфраструктуру нескольких клиентов. Для облачных площадок и центров обработки данных с высокой плотностью вычислений возрастает зависимость от охлаждения и управления питанием. В корпоративных ЦОД тот же риск дополняется длительным сроком эксплуатации инженерного оборудования, которое зачастую обновляется значительно реже серверной части.

Приоритетом для владельца ЦОД должна стать инвентаризация инженерных активов с привязкой к версии прошивки, модели устройства, статусу поддержки производителя и роли в технологическом процессе. Простого перечня IP-адресов здесь недостаточно: необходимо понимать, какие BMS управляют охлаждением, какие контроллеры участвуют в энергоснабжении, какие системы связаны с генераторами и пожарной автоматикой и по каким сетевым маршрутам к ним можно добраться. Обновления следует планировать исходя из эксплуатационной критичности и наличия реально используемых уязвимостей, в первую очередь закрывая KEV и устройства, доступные из смежных сегментов. Там, где установка новой прошивки невозможна, нужны компенсирующие меры: изоляция BMS от корпоративной сети, микросегментация, отказ от прямого интернет-доступа, контроль подрядчиков и выделенные механизмы удаленного подключения. Для BACnet, MODBUS и других технологических протоколов необходим мониторинг команд и отклонений от штатного поведения. Такая схема позволяет работать с устаревшим оборудованием без иллюзии, что закрытый внешний периметр автоматически делает инженерную инфраструктуру недоступной для атакующего.