topics:20:incidents []

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
<WRAP doku>

====== Реальные инциденты и уроки из практики ======
<WRAP box round>
Раздел рассматривает реальные примеры киберинцидентов, связанных с операционными системами в ЦОД. Анализируются технические причины, уязвимости инженерных протоколов и ошибки эксплуатации, приводившие к простоям и финансовым потерям.
</WRAP>

===== Определение киберинцидента =====
<WRAP info>
Согласно определению Национального института стандартов и технологий США (NIST), киберинцидент — это событие, которое фактически или потенциально ставит под угрозу конфиденциальность, целостность или доступность информационной системы либо нарушает установленные политики безопасности.
</WRAP>

Киберинцидент может быть:
  * непреднамеренным (ошибка конфигурации, сбой системы);
  * умышленным (целевая атака или эксплуатация уязвимости).

<WRAP important>
Не каждое нарушение работы является атакой. Если невозможно определить злонамеренность действий, событие всё равно классифицируется как киберинцидент.
</WRAP>

===== Пример: авария в ЦОД British Airways (Великобритания, 2017) =====
<WRAP info>
27 мая 2017 года в двух британских ЦОД компании British Airways (Boadicea House и Comet House) произошли масштабные отключения электропитания. Инцидент привёл к остановке авиасистем на несколько часов и значительным финансовым потерям.
</WRAP>

Хронология и причины:
  * в ЦОД произошёл кратковременный импульс напряжения, после чего источники бесперебойного питания (UPS) не перешли на батареи, а самостоятельно выключились;
  * генераторы не запустились, так как UPS находились в линии с общей системой питания;
  * поставщик электроэнергии подтвердил отсутствие внешних сбоев — проблема возникла внутри инфраструктуры ЦОД;
  * система управления UPS содержала SNMP-карты с активированными устаревшими функциями «graceful shutdown»;
  * настройки привели к немедленному завершению работы UPS при ложном сигнале о сбое.

<WRAP important>
Проблема не была связана с атакой, а представляла собой уязвимость конфигурации SNMP-карт. Параметры отключения могли быть изменены дистанционно или остались в заводских настройках. Даже при наличии резервирования ошибка одного узла привела к полной потере питания в двух дата-центрах.
</WRAP>

===== Технический разбор уязвимости =====
Типичные опасные параметры SNMP-карт UPS, оставшиеся со времён 1990-х:
  * установка таймера в 0 секунд для работы от батареи;
  * установка порога отключения при 100 процентах заряда батареи;
  * активация опции shutdown on transfer to battery (отключение при любом переходе на батарею).

<WRAP info>
Эти функции предназначались для старых систем, где один UPS обслуживал отдельный сервер, который завершал работу перед отключением питания. Современные ЦОД работают по противоположному принципу — серверы не должны выключаться при переходе на батареи. Многие производители не удалили эти опции из прошивок SNMP-карт.
</WRAP>

<WRAP center>
Вывод расследования British Airways: не была реализована политика контроля конфигурации SNMP-устройств, а функции автоматического отключения остались активными по умолчанию.
</WRAP>

===== Уроки для инженерных систем ЦОД =====
  * SNMP-карты и аналогичные устройства следует рассматривать как элементы повышенного риска.  
  * Все функции, связанные с автоматическим выключением, должны быть отключены или ограничены по доступу.  
  * Требуется централизованный аудит конфигураций инженерных устройств (UPS, PDU, системы охлаждения и т.д.).  
  * SNMP-доступ должен быть изолирован отдельным VLAN с применением версии SNMPv3 с аутентификацией и шифрованием.  
  * Необходимо исключить использование устаревших graceful shutdown функций и серверного ПО старых поколений.

<WRAP important>
Даже при наличии резервных источников питания и генераторов, ошибочная логика или несогласованная настройка в одной SNMP-карте может полностью нарушить отказоустойчивость системы.
</WRAP>

===== Российская практика =====
<WRAP info>
В России подобные инциденты в ЦОД не становятся публичными, однако подход к управлению уязвимостями в инженерных системах закреплён нормативно.  
Приказ ФСТЭК России №239 обязывает владельцев значимых объектов КИИ выявлять, устранять и документировать уязвимости технических средств, включая контроллеры и коммуникационные интерфейсы.
</WRAP>

Принятые меры в отечественной практике:
  * аудит конфигураций SNMP, Modbus, BACnet при вводе и эксплуатации ЦОД;
  * использование шлюзов с фильтрацией команд управления;
  * чёткое разграничение ответственности между подрядчиками по направлениям IT, инженерные системы, информационная безопасность;
  * журналирование событий в системах SIEM и OT-SIEM;
  * отключение всех функций автоматического выключения на уровне оборудования.

===== Ключевые выводы =====
<WRAP tip>
  * Логические уязвимости и ошибки конфигурации представляют не меньшую угрозу, чем сетевые атаки.  
  * Необходимо вести учёт и контроль конфигураций всех контроллеров и интерфейсов связи.  
  * Управление OT-инцидентами должно входить в контур общей системы ИБ.  
  * Российские требования (Приказ ФСТЭК №239) формируют базу для предотвращения подобных событий.  
  * Контроль конфигураций и аудит инженерных систем должны проводиться регулярно и документированно.
</WRAP>

</WRAP>