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