Реальные инциденты и уроки из практики
Раздел рассматривает реальные примеры киберинцидентов, связанных с операционными системами в ЦОД. Анализируются технические причины, уязвимости инженерных протоколов и ошибки эксплуатации, приводившие к простоям и финансовым потерям.
Определение киберинцидента
Согласно определению Национального института стандартов и технологий США (NIST), киберинцидент — это событие, которое фактически или потенциально ставит под угрозу конфиденциальность, целостность или доступность информационной системы либо нарушает установленные политики безопасности.
Киберинцидент может быть:
непреднамеренным (ошибка конфигурации, сбой системы);
умышленным (целевая атака или эксплуатация уязвимости).
Не каждое нарушение работы является атакой. Если невозможно определить злонамеренность действий, событие всё равно классифицируется как киберинцидент.
Пример: авария в ЦОД British Airways (Великобритания, 2017)
27 мая 2017 года в двух британских ЦОД компании British Airways (Boadicea House и Comet House) произошли масштабные отключения электропитания. Инцидент привёл к остановке авиасистем на несколько часов и значительным финансовым потерям.
Хронология и причины:
в ЦОД произошёл кратковременный импульс напряжения, после чего источники бесперебойного питания (UPS) не перешли на батареи, а самостоятельно выключились;
генераторы не запустились, так как UPS находились в линии с общей системой питания;
поставщик электроэнергии подтвердил отсутствие внешних сбоев — проблема возникла внутри инфраструктуры ЦОД;
система управления UPS содержала SNMP-карты с активированными устаревшими функциями «graceful shutdown»;
настройки привели к немедленному завершению работы UPS при ложном сигнале о сбое.
Проблема не была связана с атакой, а представляла собой уязвимость конфигурации SNMP-карт. Параметры отключения могли быть изменены дистанционно или остались в заводских настройках. Даже при наличии резервирования ошибка одного узла привела к полной потере питания в двух дата-центрах.
Технический разбор уязвимости
Типичные опасные параметры SNMP-карт UPS, оставшиеся со времён 1990-х:
установка таймера в 0 секунд для работы от батареи;
установка порога отключения при 100 процентах заряда батареи;
активация опции shutdown on transfer to battery (отключение при любом переходе на батарею).
Эти функции предназначались для старых систем, где один UPS обслуживал отдельный сервер, который завершал работу перед отключением питания. Современные ЦОД работают по противоположному принципу — серверы не должны выключаться при переходе на батареи. Многие производители не удалили эти опции из прошивок SNMP-карт.
Вывод расследования British Airways: не была реализована политика контроля конфигурации SNMP-устройств, а функции автоматического отключения остались активными по умолчанию.
Уроки для инженерных систем ЦОД
SNMP-карты и аналогичные устройства следует рассматривать как элементы повышенного риска.
Все функции, связанные с автоматическим выключением, должны быть отключены или ограничены по доступу.
Требуется централизованный аудит конфигураций инженерных устройств (UPS, PDU, системы охлаждения и т.д.).
SNMP-доступ должен быть изолирован отдельным VLAN с применением версии SNMPv3 с аутентификацией и шифрованием.
Необходимо исключить использование устаревших graceful shutdown функций и серверного ПО старых поколений.
Даже при наличии резервных источников питания и генераторов, ошибочная логика или несогласованная настройка в одной SNMP-карте может полностью нарушить отказоустойчивость системы.
Российская практика
В России подобные инциденты в ЦОД не становятся публичными, однако подход к управлению уязвимостями в инженерных системах закреплён нормативно.
Приказ ФСТЭК России №239 обязывает владельцев значимых объектов КИИ выявлять, устранять и документировать уязвимости технических средств, включая контроллеры и коммуникационные интерфейсы.
Принятые меры в отечественной практике:
аудит конфигураций SNMP, Modbus, BACnet при вводе и эксплуатации ЦОД;
использование шлюзов с фильтрацией команд управления;
чёткое разграничение ответственности между подрядчиками по направлениям IT, инженерные системы, информационная безопасность;
журналирование событий в системах SIEM и OT-SIEM;
отключение всех функций автоматического выключения на уровне оборудования.
Ключевые выводы
Логические уязвимости и ошибки конфигурации представляют не меньшую угрозу, чем сетевые атаки.
Необходимо вести учёт и контроль конфигураций всех контроллеров и интерфейсов связи.
Управление OT-инцидентами должно входить в контур общей системы ИБ.
Российские требования (Приказ ФСТЭК №239) формируют базу для предотвращения подобных событий.
Контроль конфигураций и аудит инженерных систем должны проводиться регулярно и документированно.