Самая неприятная кибератака в промышленности редко выглядит как “взлом” с красным черепом на экране. Чаще она маскируется под привычную технику: то связь “капризничает”, то уставка вдруг не такая, то архив показывает одно, а оператор уверен, что видел другое. И первое желание абсолютно правильное – проверить питание, клеммы, экраны, землю, помехи. Проблема в том, что сегодня рядом с обычной физикой все чаще живет еще один источник странностей: вмешательство в систему управления, сделанное так, чтобы его приняли за обычный отказ.
Безопасность ПЛК – это не про “добавим антивирус и успокоимся”. Это про контроль над тем, кто и откуда может менять логику, параметры и конфигурацию, и про способность быстро доказать, что система работает в ожидаемом состоянии. В промышленности это особенно важно, потому что последствия измеряются не “потерей файла”, а изменением режима, качеством продукта, простоем или риском для безопасности процесса. NIST в актуальном руководстве по защите ICS подчеркивает именно этот разрыв между IT и OT: OT связано с физическим миром и требованиями по доступности и безопасности технологического процесса.
Почему контроллеры стали интересны атакующим
Если говорить честно, ПЛК интересны не из-за “крутости”, а из-за эффекта. Контроллер управляет реальными исполнительными механизмами. Получив возможность менять программу или критические параметры, злоумышленник может сделать то, что в IT обычно невозможно: воздействовать на физику. А еще промышленная автоматика живет долго. Десять, пятнадцать, двадцать лет – нормальный срок. За это время меняются сети, люди, подходы к безопасности, а устройство и протоколы остаются с логикой эпохи доверия внутренней сети.
Отсюда типовая картина: где-то есть старые протоколы без шифрования, где-то инженерные станции живут “как получится”, где-то удаленный доступ включали на шеф-наладку и забыли выключить. И даже если ПЛК не “смотрит” в интернет напрямую, цепочка атаки почти никогда не требует прямого выхода контроллера наружу. Она идет через более удобные ступени: офис, инженерные ПК, сервера верхнего уровня, удаленку. NIST отдельно акцентирует, что связи между сетями и интеграция OT с другими сегментами резко увеличивают поверхность атаки и требуют специализированных мер.
Мировые кейсы, которые стоит помнить инженеру
Чтобы разговор не был теоретическим, полезно держать в голове несколько реальных историй. Они разные, но каждая подсвечивает типовую слабость.
Oldsmar: водоснабжение и “обычный” удаленный доступ
В 2021 году в городе Олдсмар (Флорида) злоумышленник получил несанкционированный доступ к SCADA-окружению и попытался изменить дозировку химиката в воде. Страшно здесь не то, что атака была сверхсложной. Страшно то, что путь оказался бытовым: доступ к операторскому уровню и возможность тронуть параметры. CISA публиковала рекомендацию по безопасности к этому инциденту и описывала сценарий вмешательства в управление.
Инженерный вывод простой: даже без перепрошивки ПЛК можно нанести вред, если атакующий попадает в точку, где регулируются уставки и режимы.
Triton/Trisis: попытка залезть в SIS, то есть в “последнюю линию защиты”
История Triton стала маркером зрелости атак: злоумышленники нацелились не на “обычный” контур управления, а на контроллеры системы безопасности (SIS) Triconex. То есть на тот слой, который должен уводить установку в безопасное состояние при аварии. Британский NCSC публиковал материалы о Triton как о вредоносе, нацеленном на контроллеры безопасности.
Почему это важно: если safety воспринимается как “особый мир, куда редко заходят”, он легко превращается в привлекательную цель. А последствия там потенциально тяжелее, чем в стандартном контуре регулирования.
Энергетика Украины и Industroyer: когда OT-протоколы становятся оружием
Атаки на энергетику Украины показали, что злоумышленники способны доводить кибервоздействие до физического результата – отключений и нарушений работы инфраструктуры. ICS-CERT/CISA выпускали материалы по инцидентам и механикам воздействия на энергосистему.
Позже появились инструменты вроде Industroyer2, ориентированные на взаимодействие с промышленной средой. В 2022 году ESET вместе с CERT-UA описывали Industroyer2 как активность, направленную на энергокомпанию и включающую ICS-специфическую логику.
Главный вывод: атаки на OT сегодня могут быть “проектными”. Это не всегда хаотичный шум. Иногда это аккуратная работа людей, которые понимают, как устроены уровни и протоколы.
Norsk Hydro: “просто ransomware (программы-вымогатели)” и эффект на реальное производство
Полезный контрпример для тех, кто считает, что “если ПЛК не трогали, то OT в порядке”. В 2019 Hydro подробно рассказывала о последствиях ransomware-атаки: часть процессов переводилась на ручное управление, восстановление требовало времени и дисциплины.
Это показывает, что иногда достаточно ударить по IT-уровню, чтобы производство потеряло удобство управления, доступ к данным и координацию – и начало деградировать даже без прямого вмешательства в логику контроллера.
Где находится реальный “ключ” к изменению ПЛК
В практике чаще всего критической точкой оказывается не сам контроллер, а инженерная станция. Тот компьютер, где лежат проекты, средства программирования, конфигурации, драйверы, документация и доступы. Если атакующий закрепился на инженерном ПК, он может изменить логику штатными инструментами и это будет выглядеть “как работа инженера”.
Поэтому инженерные станции в OT – это актив уровня “ключи от цеха”. У них должны быть отдельные правила: минимизация лишнего софта, жесткое управление учетными записями, запрет “общих паролей”, контроль носителей, резервные копии и, главное, контроль версий проектов. NIST в контексте ICS описывает важность защиты инженерных и управляющих компонентов, потому что через них возможен прямой контроль физического процесса.
Защита по-взрослому: зоны, каналы и контролируемые пути
Одна из самых практичных рамок – подход ISA/IEC 62443 с “zones & conduits”. Смысл не в покупке конкретного железа, а в том, чтобы формально определить, где заканчивается доверие и какие связи допустимы. В обзорных материалах по 62443 эту идею часто объясняют как метод системной сегментации OT.
В реальном объекте обычно получается несколько зон: IT, DMZ, верхний уровень OT (SCADA/история), инженерные станции, зона контроллеров, иногда отдельно «безопсность». Между ними – контролируемые каналы, где задаются правила: какие протоколы разрешены, в каких направлениях, какие источники.
Практическая цель проста: если злоумышленник попал в офис, он не должен “по умолчанию” видеть инженерные станции и сеть ПЛК. Если он попал на инженерную станцию, ему должно быть сложно и заметно добраться до контроллеров. А если он оказался в сети контроллеров, возможность изменения логики должна быть максимально ограничена и фиксируема.
Удаленный доступ: нужен, но должен быть единственным и наблюдаемым
Удаленка в промышленности реальна и нужна – сервис, наладка, поддержка. Проблема в том, что именно удаленный доступ часто становится тем самым “временным решением навсегда”.
В зрелой схеме удаленный доступ идет через одну точку входа (bastion/jump host), с многофакторной аутентификацией там, где это возможно, и с обязательной фиксацией действий. CISA в рекомендациях по инцидентам и защите ICS последовательно подчеркивает важность MFA и контроля удаленного доступа.
Инженерная логика здесь такая: доступ выдаем под задачу и на окно работ, не оставляем “постоянные туннели”, логируем подключения и, по возможности, пишем сессии. Тогда при разборе инцидента у вас есть факты, а не догадки.
Патчи и уязвимости: почему “не трогаем, работает” перестало быть достаточным
OT не живет по правилам IT. В OT обновления часто болезненны: мало окон, много зависимостей, старое ПО, риски совместимости. Поэтому реальная стратегия обычно риск-ориентированная: что уязвимо, как достижимо, какой ущерб, какие компенсирующие меры.
Если патч сейчас невозможен, это не повод ничего не делать. Это повод усиливать архитектуру: сегментацию, ограничения маршрутов, белые списки соединений, изоляцию инженерных станций и мониторинг аномалий. NIST как раз подчеркивает необходимость мер, учитывающих специфику OT, а не слепого переноса IT-подходов.
Мониторинг OT: искать признаки влияния на процесс, а не “все подряд”
В офисной безопасности полезно ловить множество типов событий. В OT полезнее ловить то, что меняет управление: попытки записи в контроллер, неожиданные соединения к инженерным сервисам, появление неизвестных устройств, нетипичные протоколы, изменение профиля опроса.
Здесь помогает систематизация техник атакующих. MITRE ATT&CK дает общий словарь подходов злоумышленников и помогает формировать списки детектов и расследований.
Ключевой нюанс для OT – осторожность с активными сканами в полевых сегментах. Лучше пассивно наблюдать, чем случайно “потрогать” сеть так, что сама диагностика станет источником проблем.
Как понять, что защита реально работает
Киберзащита ПЛК становится зрелой не тогда, когда в сети стало “тихо”, а когда у вас появились ответы на простые вопросы.
Кто может менять программу и параметры, и через какие точки? Есть ли эталонные версии проектов и процедура сверки с тем, что реально в контроллере? Видите ли вы удаленные подключения и можете ли их отключить без паники? Есть ли резервные копии и проверено ли восстановление? Понимаете ли вы реальные связи IT и OT, а не “как должно быть на бумаге”?
Если ответы есть – вы уже сильно усложнили жизнь атакующему и сильно упростили жизнь себе в инциденте.
Итог: безопасность ПЛК строится вокруг контроля изменений и границ доверия
Мировые примеры показывают несколько повторяющихся сюжетов. Иногда злоумышленнику хватает доступа к операторскому уровню, как в кейсах водоснабжения. Иногда атака целится в SIS, что уже про безопасность процесса, как Triton. Иногда атакующие работают через OT-протоколы и инфраструктуру, как в энергетических историях и Industroyer2. А иногда достаточно выбить IT, чтобы производство ощутимо пострадало, как у Hydro.
Отсюда инженерный вывод: защита ПЛК – это не один продукт и не один “лайфхак”. Это система, в которой сеть разделена на зоны, каналы контролируемы, удаленный доступ централизован и наблюдаем, инженерные станции защищены как ключевой актив, изменения программ фиксируются и проверяются, а мониторинг ловит признаки вмешательства до того, как они станут аварией. И если опираться на признанные рамки вроде IEC 62443 и NIST 800-82, это превращается не в набор разрозненных запретов, а в управляемую практику, которую можно поддерживать годами.
Автор: Дмитрий Стабур, инженер АСУ ТП