Различия

Показаны различия между двумя версиями страницы.

--- topics:20:incidents [2025/11/15 18:13] – создано admin
+++ topics:20:incidents [2025/11/15 18:16] (текущий) – admin
@@ Строка 3: / Строка 3: @@
 ====== Реальные инциденты и уроки из практики ======
 <WRAP box round>
-Раздел рассматривает реальные примеры киберинцидентов, связанных с операционными (OT) системами в ЦОД. Анализируются технические причины, уязвимости инженерных протоколов и ошибки эксплуатации, которые приводили к длительным простоям и финансовым потерям.
+Раздел рассматривает реальные примеры киберинцидентов, связанных с операционными системами в ЦОД. Анализируются технические причины, уязвимости инженерных протоколов и ошибки эксплуатации, приводившие к простоям и финансовым потерям.
 </WRAP>
 ===== Определение киберинцидента =====
 <WRAP info>
-Согласно определению Национального института стандартов и технологий США (NIST), **киберинцидент** — это событие, которое фактически или потенциально ставит под угрозу конфиденциальность, целостность или доступность информационной системы, либо нарушает установленные политики безопасности.
+Согласно определению Национального института стандартов и технологий США (NIST), киберинцидент — это событие, которое фактически или потенциально ставит под угрозу конфиденциальность, целостность или доступность информационной системы либо нарушает установленные политики безопасности.
 </WRAP>
 Киберинцидент может быть:
-  * **непреднамеренным** (ошибка конфигурации, сбой системы);
+  * непреднамеренным (ошибка конфигурации, сбой системы);
-  * **умышленным** (целевая атака или эксплуатация уязвимости).
+  * умышленным (целевая атака или эксплуатация уязвимости).
 <WRAP important>
-Не каждое нарушение работы — атака. Если невозможно однозначно определить злонамеренность действий, инцидент всё равно классифицируется как киберинцидент.
+Не каждое нарушение работы является атакой. Если невозможно определить злонамеренность действий, событие всё равно классифицируется как киберинцидент.
 </WRAP>
 ===== Пример: авария в ЦОД British Airways (Великобритания, 2017) =====
 <WRAP info>
-мая 2017 года в двух британских ЦОД компании **British Airways** (Boadicea House и Comet House) произошли масштабные отключения электропитания. Инцидент привёл к остановке авиасистем на несколько часов и финансовым потерям в десятки миллионов фунтов.
+мая 2017 года в двух британских ЦОД компании British Airways (Boadicea House и Comet House) произошли масштабные отключения электропитания. Инцидент привёл к остановке авиасистем на несколько часов и значительным финансовым потерям.
 </WRAP>
 Хронология и причины:
-  * в ЦОД произошёл кратковременный импульс напряжения, после чего ИБП (UPS) не перешли на батареи, а **самостоятельно выключились**;
+  * в ЦОД произошёл кратковременный импульс напряжения, после чего источники бесперебойного питания (UPS) не перешли на батареи, а самостоятельно выключились;
   * генераторы не запустились, так как UPS находились в линии с общей системой питания;
-  * расследование показало, что сбой не был связан с поставщиком электроэнергии — **проблема возникла внутри инфраструктуры ЦОД**;
+  * поставщик электроэнергии подтвердил отсутствие внешних сбоев — проблема возникла внутри инфраструктуры ЦОД;
-  * система управления UPS содержала SNMP-карту, на которой были активированы устаревшие функции «graceful shutdown» — автоматического выключения при аномалии;
+  * система управления UPS содержала SNMP-карты с активированными устаревшими функциями «graceful shutdown»;
-  * эти настройки привели к немедленному завершению работы UPS при обнаружении ложного сигнала о сбое.
+  * настройки привели к немедленному завершению работы UPS при ложном сигнале о сбое.
 <WRAP important>
-Суть проблемы заключалась не в хакерской атаке, а в **уязвимости конфигурации SNMP-карты**: параметры отключения могли быть изменены дистанционно или остались в заводских настройках.
+Проблема не была связана с атакой, а представляла собой уязвимость конфигурации SNMP-карт. Параметры отключения могли быть изменены дистанционно или остались в заводских настройках. Даже при наличии резервирования ошибка одного узла привела к полной потере питания в двух дата-центрах.
-Даже при наличии резервирования и дублирования систем, ошибка в настройке одного узла привела к полной потере питания в двух дата-центрах.
 </WRAP>
 ===== Технический разбор уязвимости =====
 Типичные опасные параметры SNMP-карт UPS, оставшиеся со времён 1990-х:
-  * установка таймера **в 0 секунд** для работы от батареи;
+  * установка таймера в 0 секунд для работы от батареи;
-  * установка порога отключения при **100 % заряде батареи**;
+  * установка порога отключения при 100 процентах заряда батареи;
-  * активация опции **shutdown on transfer to battery** (отключение при любом переходе на батарею).
+  * активация опции shutdown on transfer to battery (отключение при любом переходе на батарею).
 <WRAP info>
-Эти функции изначально предназначались для старых систем, где один UPS обслуживал отдельный сервер, который корректно завершал работу перед выключением ИБП.
+Эти функции предназначались для старых систем, где один UPS обслуживал отдельный сервер, который завершал работу перед отключением питания. Современные ЦОД работают по противоположному принципу — серверы не должны выключаться при переходе на батареи. Многие производители не удалили эти опции из прошивок SNMP-карт.
-Современные ЦОД работают по противоположному принципу — **сервер нельзя выключать при переходе на батареи**, но многие производители не удалили устаревшие опции из прошивок SNMP-карт.
 </WRAP>
 <WRAP center>
-**Вывод расследования British Airways:**
+Вывод расследования British Airways: не была реализована политика контроля конфигурации SNMP-устройств, а функции автоматического отключения остались активными по умолчанию.
-не была реализована политика контроля конфигурации SNMP-устройств, а функции автоматического отключения остались активными по умолчанию.
 </WRAP>
 ===== Уроки для инженерных систем ЦОД =====
-  * SNMP-карты и аналогичные устройства должны рассматриваться как **элементы повышенного риска**.
+  * SNMP-карты и аналогичные устройства следует рассматривать как элементы повышенного риска.
-  * Все функции, связанные с удалённым или автоматическим выключением, подлежат **отключению или ограничению доступа**.
+  * Все функции, связанные с автоматическим выключением, должны быть отключены или ограничены по доступу.
-  * Требуется централизованный аудит всех конфигураций OT-устройств (UPS, PDU, CRAC, насосные станции и т.д.).
+  * Требуется централизованный аудит конфигураций инженерных устройств (UPS, PDU, системы охлаждения и т.д.).
-  * SNMP-доступ следует ограничивать отдельным VLAN, применяя SNMPv3 с authPriv.
+  * SNMP-доступ должен быть изолирован отдельным VLAN с применением версии SNMPv3 с аутентификацией и шифрованием.
-  * Запрещено использовать устаревшие «graceful shutdown» функции и серверное ПО старого поколения.
+  * Необходимо исключить использование устаревших graceful shutdown функций и серверного ПО старых поколений.
 <WRAP important>
-Даже при наличии резервных вводов и генераторов, **ошибочная логика или несанкционированная настройка** в одной SNMP-карте может обнулить все уровни отказоустойчивости.
+Даже при наличии резервных источников питания и генераторов, ошибочная логика или несогласованная настройка в одной SNMP-карте может полностью нарушить отказоустойчивость системы.
 </WRAP>
 ===== Российская практика =====
 <WRAP info>
-В России инциденты подобного масштаба в ЦОД не публикуются открыто, однако подход к управлению уязвимостями в инженерных системах закреплён нормативно.
+В России подобные инциденты в ЦОД не становятся публичными, однако подход к управлению уязвимостями в инженерных системах закреплён нормативно.
-**Приказ ФСТЭК №239** обязывает владельцев значимых объектов КИИ выявлять, устранять и документировать уязвимости технических средств, включая контроллеры и коммуникационные интерфейсы OT.
+Приказ ФСТЭК России №239 обязывает владельцев значимых объектов КИИ выявлять, устранять и документировать уязвимости технических средств, включая контроллеры и коммуникационные интерфейсы.
 </WRAP>
-Меры, принятые в отечественной практике:
+Принятые меры в отечественной практике:
-  * аудит конфигураций SNMP/Modbus/BACnet при вводе и в ходе эксплуатации ЦОД;
+  * аудит конфигураций SNMP, Modbus, BACnet при вводе и эксплуатации ЦОД;
-  * применение шлюзов с фильтрацией команд управления;
+  * использование шлюзов с фильтрацией команд управления;
-  * жёсткое разграничение ответственности между подрядчиками (ИТ, инженерка, ИБ);
+  * чёткое разграничение ответственности между подрядчиками по направлениям IT, инженерные системы, информационная безопасность;
-  * обязательное журналирование событий в SIEM/OT-SIEM;
+  * журналирование событий в системах SIEM и OT-SIEM;
-  * отключение всех опций «автоматического выключения» на уровне оборудования.
+  * отключение всех функций автоматического выключения на уровне оборудования.
-===== Основные выводы =====
+===== Ключевые выводы =====
 <WRAP tip>
-  * Даже тривиальная настройка SNMP может привести к катастрофическим последствиям, если не контролируется политикой ИБ.
+  * Логические уязвимости и ошибки конфигурации представляют не меньшую угрозу, чем сетевые атаки.
-  * Логические уязвимости часто опаснее сетевых атак: они находятся внутри протоколов управления.
+  * Необходимо вести учёт и контроль конфигураций всех контроллеров и интерфейсов связи.
-  * Для ЦОД критически важно вести учёт конфигураций всех контроллеров и карт связи.
+  * Управление OT-инцидентами должно входить в контур общей системы ИБ.
-  * Управление OT-инцидентами должно быть включено в систему ИБ как часть непрерывного мониторинга.
+  * Российские требования (Приказ ФСТЭК №239) формируют базу для предотвращения подобных событий.
-  * Российская практика (ФСТЭК №239) требует внедрения процессов управления уязвимостями, что напрямую предотвращает повторение подобных аварий.
+  * Контроль конфигураций и аудит инженерных систем должны проводиться регулярно и документированно.
 </WRAP>
 </WRAP>