Ущерб от бездумного внедрения ИБ в АСУ ТП: когда «защита» становится угрозой

ИБ в промышленности – новая угроза?

В мире промышленных предприятий информационная безопасность становится новой религией. На совещаниях все чаще звучат слова «угроза», «комплаенс», «SOC» и «Zero Trust», вместо привычных «доступность», «надежность» или «MTBF». Инженерная дисциплина, закаленная реальными авариями, постепенно вытесняется бюрократией аудита и отчетами в PowerPoint. Однако у станков, турбин и реакторов нет терпения к «лучшим практикам» на бумаге. Они работают по законам физики, а не по политике безопасности. Когда «офисная» ИБ вторгается в цех без понимания контекста, она перестает быть защитой и превращается в угрозу. В ИТ-мире потеря пакета – статистическая мелочь, в АСУ ТП потерянный сигнал может сорвать регуляцию давления или вызвать срабатывание ложной ошибки. То, что в офисе грозит лишь замедлением сети, на производстве способно остановить технологический процесс.

Каждый инженер, который видел, как после обновления антивируса перестает отвечать инженерное ПО, как межсетевой экран режет пакеты промышленного протокола, или как оператор теряет доступ к SCADA из-за необходимости смены пароля, понимает: главная угроза для завода – не хакеры, а неумелое внедрение «защиты» . Поэтому эта статья – не про вирусы или киберпреступников. Она о человеческой глупости, технологическом высокомерии и управленческом непонимании, что такое безопасность в мире реальных машин. Неправильное внедрение ИБ стало новой формой промышленного риска – о ней почти не говорят, потому что источник проблемы находится внутри структуры управления предприятием. Решения по безопасности принимаются без участия инженеров; риск рассматривается только через призму уязвимостей, а не вероятности остановки производства и потерях, в результате чего завод оказывается заложником бумажной отчетности.

Правильная ИБ в промышленности должна защищать процессы, а не мешать им. Любая мера безопасности, которая снижает доступность, надежность или возможность людей управлять системой – на самом деле не безопасность, а управленческая халатность. 

 «Деньги делает то, что работает»

Каждая промышленная компания зарабатывает только тогда, когда ее оборудование работает. Станок режет металл – идет выпуск продукции. Печь греет – плавится сырье. Насос качает – идет добыча. Как только оборудование останавливается, завод несет убытки. Причины остановки с точки зрения экономики роли не играют: сгорел датчик или SCADA упала из-за ИБ-системы – результат один, простой производства. В глазах директора сорванный заказ из-за киберинцидента и из-за поломки датчика не отличаются – в обоих случаях предприятие теряет деньги.

Завод зарабатывает, только когда работает. Любая система безопасности, которая этому мешает, играет против завода. Оборудование неизбежно ломается, но инженеры умеют его чинить. Главное – не мешать им работать. 

Виды ущерба от ошибочных мер безопасности

Внедрение киберзащиты в промышленную среду без учета ее специфики может обернуться разнообразными видами ущерба для предприятия. Вот основные возможные потери.

Финансовые потери. Ошибочные меры ИБ влекут прямые финансовые убытки. Как я уже писал, простои оборудования из-за сбоев, вызванных средствами защиты, означают потерю выручки. Для предприятий с непрерывным циклом даже кратковременная остановка – это миллионы рублей убытков, связанных с простоем и повторным запуском процесса. Реальные цифры подтверждают этот порядок: даже одна технологическая линия может терять десятки миллионов рублей в год на простоях. Международные исследования показывают аналогичную картину: средняя стоимость частого простоя для крупных компаний превышает 100 000 долларов, а у 40% предприятий убытки достигают 1–5 млн долларов за час. В промышленности это неудивительно – останов агрегата бьет не только по объему выпуска, но и приводит к затратам на повторный разогрев печей, переработку брака и т.д. Помимо упущенной выгоды, финансовый ущерб включает расходы на устранение сбоев и внеплановый ремонт оборудования после инцидентов, а также стоимость самих неэффективно внедренных средств ИБ (которые, по сути, работают вхолостую или во вред).

• Фармацевтическая отрасль: Согласно исследованию от 2025 года, недельный простой упаковочной линии на фармацевтическом производстве может привести к упущенной прибыли в размере около 130 миллионов рублей. В пересчете на час простоя (при 24/7 работе) это составляет более 750 000 рублей. Статья также указывает, что наибольшую долю в общем времени простоев (35-40%) занимают незапланированные поломки.

• Более 98% крупных предприятий с численностью сотрудников более 1000 человек утверждают, что в среднем один час простоя в год обходится их компании более чем в 100 000 долларов США.

• Отчёт Siemens «Истинная стоимость простоя в 2024 году»: «Крупные автопроизводители сейчас теряют 2,3 миллиона долларов США за каждый час простоя».

• Общая цифра потерь: «Незапланированные простои обходятся компаниям из списка Fortune Global 500 в 11% годового оборота, что составляет почти 1,5 триллиона долларов США».

Производственные сбои и потеря выпуска. Неверно внедренная ИБ способна напрямую нарушить ход технологического процесса. Результат – остановки линий, отказ оборудования или снижение производительности из-за вмешательства средств защиты. Например, блокировка легитимного трафика между компонентами АСУ ТП, сетевым экраном или системой обнаружения атак приведет к рассинхронизации управляющих сигналов и сбою взаимодействия узлов. Известны случаи, когда интенсивное сетевое сканирование или избыточный трафик вызывали зависания контроллеров: многие ПЛК чувствительны к сетевому трафику и могут выйти из строя от сетевого шторма, что немедленно ведет к остановке связанных с ними узлов. В результате предприятие теряет выпуск продукции, получает брак (если сбой случился в середине цикла) или даже сталкивается с аварийной остановкой дорогостоящего оборудования.

Репутационный ущерб. Если из-за внутренних мер «безопасности» предприятие терпит аварийный простой или сбой, это подрывает доверие к его надежности. Заказчики и партнеры могут усомниться в стабильности поставок. На критически важных объектах подобные инциденты привлекают внимание регуляторов и общественности. В стандартах промышленной кибербезопасности прямо указано: компрометация системы (в нашем случае сбой из-за неверно внедренных средств) ведет к потере общественного доверия и нарушению требований регулирующих органов. Например, вынужденная остановка химического или энергетического производства из-за сбоя, спровоцированного ИБ-средствами, может повлечь разбирательства с надзорными органами, штрафы, а публично – удар по деловой репутации компании. В экстремальных случаях, когда сбой влияет на безопасность людей или окружающей среды, репутационный ущерб многократно возрастает и может оказаться невосполнимым.

В ИТ-мире всему голова – данные. Главные ценности: целостность, конфиденциальность и доступность информации. Незначительная задержка отклика, потеря пакета или перезагрузка сервера – рядовое событие. В промышленности все наоборот: данные вторичны, а первичны время и устойчивость процесса. Там, где администратор может позволить «подвисание» приложения на пару секунд, технологический процесс не терпит ни мгновения. Если цикл опроса датчика сбился по времени, получаем риск аварии, ложную тревогу или незапланированный останов линии.

Ошибка, которую совершают почти все крупные компании, внедряя кибербезопасность в производство, проста: они переносят ИТ-правила в мир, где правят законы физики. Без адаптации. Администраторы разворачивают централизованные антивирусы и EDR-агенты на операторских станциях, внедряют строгие доменные политики, шифрование всего подряд – не понимая, что каждый н��вый контроль добавляет задержки и нагрузку на CPU, неприемлемые для систем реального времени. Так запускается цепная реакция: межсетевой экран с глубокой инспекцией создает задержки в доставке пакетов – ПЛК теряет синхронизацию с SCADA. Агент безопасности на сервере SCADA съедает ресурсы процессора – оператор видит «зависающий» экран. Скрипт автопроверки обновлений перегружает сетевой интерфейс инженерной станции – связь с контроллерами обрывается. Все работает «по правилам безопасности», но завод… останавливается.

Проблема не только техническая, но и организационная. ИТ-специалисты, привыкшие к циклу «обнови–перезагрузи», не осознают, что в АСУ ТП любое изменение требует стендовой валидации и подготовки полной документации. Промышленные системы проектируются на десятилетия, а не на срок жизни антивирусной сигнатуры. Тем не менее каждая новая ИБ-программа приносит старую мантру: «надо просто включить защиту». Никто не задается вопросом: выдержит ли ее контроллер или привод? 

В этом и корень катастрофы – перенос ИТ-логики в производство без адаптации. Когда меры безопасности начинают мешать управлению, надежность системы падает быстрее, чем растет защищенность. В конечном счете завод становится «безопасным» только в одном смысле – безопасным от самого себя (то есть просто стоит без движения). Итог прост: ИТ-методы нельзя переносить в цех без адаптации к реальному времени. Там, где в офисе безопасность означает «защиту данных», в производстве она должна означать «сохранение управления процессом».

Корни конфликта: ИБ и АСУ ТП говорят на разных языках

Технические ошибки – лишь вершина айсберга. Настоящая причина ущерба от неумелого внедрения ИБ лежит глубже, в организационном устройстве предприятий. ИТ и АСУ ТП живут в разных культурах. Первые меряют успех количеством закрытых уязвимостей и пройденных аудитов, вторые – количеством часов без остановки оборудования. Эти показатели никогда не совпадали и не совпадут. Возникает конфликт целей: ИБ-служба видит в инженерах источник риска («они запускают старое ПО, не обновляют ОС, оставляют открытые порты»). Инженеры же видят в ИБ-сотрудниках угрозу процессу («они блокируют доступ, мешают калибровке, лезут в сеть без тестов»). Конфликт рождается не из злого умысла, а из разных представлений о реальности.

В офисной ИТ-среде можно перезагрузить сервер днем, закрыть порт, обновить драйвер – это не приведет к немедленной аварии. В цеху так делать нельзя: каждое действие может повлиять на давление, температуру, движение сырья. Когда ИБ-службы начинают применять корпоративные политики без учета технологического цикла, они фактически вмешиваются в управление оборудованием, не имея на то компетенций. Эта коллизия усугубляется управленческой асимметрией: у ИБ есть право «вето» – без их согласования нельзя подключать, обновлять, тестировать. У производственников же есть обязанность обеспечить выпуск продукции, но нет права заблокировать решения ИБ. В итоге ответственность распределяется абсурдно: за последствия остановки отвечает производство, а за ее причину – формально никто.

Отраслевые рекомендации (NIST, CISA, ISA/IEC 62443) подчеркивают: управление безопасностью в АСУ ТП должно быть совместным, с участием как ИБ-специалистов, так и инженеров. Однако на большинстве предприятий такие советы существуют лишь на бумаге. Реально решения принимаются в ИТ-блоке, а инженер узнает о них постфактум – когда линия уже стоит после внедрения. Еще одна причина – кадровый вакуум: людей, одинаково разбирающихся и в технологии, и в кибербезопасности, единицы или вообще нет. Чаще всего изменения в системе внедряют люди, никогда не стоявшие у шкафа управления, не видевшие ПЛК в аварии и не понимающие, почему нельзя «просто поставить агент». Именно поэтому большинство инцидентов, описанных в отчетах CISA и ENISA, происходят не из-за атак, а из-за человеческих ошибок при внедрении ИБ .

Организационный конфликт между ИБ и АСУ ТП стал хроническим. Каждая сторона считает себя правой, но обе проигрывают: инженеры теряют контроль над средой, ИБ – доверие и поддержку цеха. Пока эти два мира не начнут говорить на одном языке и сотрудничать, любая мера защиты будет иметь побочный эффект – деградацию надежности. ИБ и АСУ ТП – два мира с разными целями. Без совместного управления изменениями любая мера безопасности становится фактором риска.

NIST дает простой рецепт, который кажется очевидным, но почти нигде не выполняется:

«Перед развертыванием все действия по обеспечению безопасности следует оценить на предмет их потенциального влияния на доступность процесса».

Иными словами, любое действие, ухудшающее управляемость системы, должно считаться угрозой, неважно из каких благих побуждений оно сделано. Проблема в том, что для большинства компаний NIST – формальность. Его читают, чтобы вставить галочку в отчете о соответствии, а не чтобы изменить подход. Поэтому каждое новое внедрение «соответствующих стандартам» ИБ-решений только увеличивает вероятность, что завод станет следующим кейсом для разбора инцидентов регуляторами.

NIST SP 800-82 – это не о том, как защитить АСУ ТП от хакеров. Это о том, как защитить завод от собственной службы безопасности.

Как «защита» рушит производство: механизмы ущерба

Ошибочная информационная безопасность не просто снижает эффективность – она вмешивается в саму физику процесса. Ниже перечислены документированные механизмы, через которые стандартные ИБ-инструменты (созданные для ИТ) наносят ущерб системам АСУ ТП. Каждому пункту соответствуют рекомендации NIST и CISA, которые, к сожалению, часто игнорируются:

1. NGFW / DPI / SSL-инспекция – нарушают синхронность работы устройств. Межсетевые экраны с глубокой инспекцией пакетов, а также средства перехвата и расшифровки трафика часто некорректно обрабатывают или задерживают трафик промышленных протоколов (Modbus, Profinet, OPC UA и др.), вызывая сбои связи между контроллерами или SCADA. NIST SP 800-82 прямо предупреждает: «Добавление задержек или джиттера в АСУ ТП может привести к небезопасным условиям». Аналогичную позицию занимает CISA (рекомендации «Defense-in-Depth Strategies», 2016) – они фиксировали случаи, когда чрезмерная фильтрация трафика вызывала нарушения в работе контроллеров. То есть сетевой экран, идеально защищающий офисную сеть, в цеху способен разрушить тайминг обмена и заставить оборудование сработать неправильно или перестать работать совсем.

2. Активные сканеры уязвимостей – DoS по ошибке. Использование сканеров уязвимостей в производственной сети может привести к неожиданному отказу оборудования. Интенсивное сканирование перегружает сетевые адаптеры устройств, вызывает зависания PLC, HMI или серверов SCADA. Снова обратимся к NIST SP 800-82 Rev.2: «Активное сканирование может вызвать отказ устройств. Применять только после тестов вне производственной среды». CISA также в своих лучших практиках для АСУТП подчеркивает: любые сканы должны проводиться осторожно, предпочтительно в окно простоя или на изолированном сегменте. Нарушение этой рекомендации уже приводило к реальным простоям (как на Browns Ferry – там сетевой трафик вывел из строя контроллеры насосов).

3. Хост-агенты безопасности тормозят HMI/SCADA. Антивирусы и EDR-агенты требуют ресурсов CPU и памяти. На инженерных рабочих станциях или серверах HMI/SCADA, где ресурсы ограничены, это вызывает фризы интерфейса, падения приложений или ложные срабатывания систем контроля целостности. NIST SP 800-82 Rev.2, §5.4.4 подчеркивает: «Хостовые средства безопасности следует тестировать на влияние производительности перед развертыванием на системах реального времени». CISA в списке рекомендованных практик АСУТП приводит специальный документ «Updating Antivirus in an Industrial Control System», где описаны случаи, когда некорректное обновление антивируса приводило к останову SCADA. Проще говоря, любой «охранный» софт на ключевом узле АСУ ТП – большой риск без тщательных тестов с участием поставщика АСУТП.

4. Агрессивный патч-менеджмент – внедрение риска вместо снижения. Установка обновлений ПО и ОС без полноценного тестирования в АСУ ТП часто приводит к несовместимости драйверов, отказам SCADA-систем и потере связи с контроллерами. NIST SP 800-82 Rev.2 (стр. 6-2) гласит: «Изменения в сети АСУ ТП должны быть оценены на влияние на управляемость процесса перед внедрением». CISA в своих гайдлайнах по АСУТП также рекомендует выстраивать строгий процесс управления патчами: использовать тестовый стенд, привлекать инженеров процесса, планировать обновления на время остановов и т.д. Игнорирование этих принципов оборачивается тем, что «заплатка безопасности» может вызвать сбой работы установки.

5. Многофакторная аутентификация и строгие политики учётных записей в классической АСУТП в ряде случаев вообще не могут быть внедрены, поскольку напрямую противоречат требованиям промышленной безопасности.

В отличие от офисных ИТ-систем, где MFA повышает защиту, в оперативных диспетчерских системах SCADA/HMI такой механизм способен блокировать аварийный доступ, что делает его небезопасным по определению. В условиях аварии оператор или инженер должны получить доступ немедленно, без ожидания SMS-кода, подтверждения через приложение или аутентификации внешнего провайдера. Любая задержка — даже 30–60 секунд — нарушает принцип оперативного управления технологическим процессом и может привести к задержке остановки, неактивированию защиты, потере контроля и росту ущерба.

Именно поэтому CISA в своих Cross-Sector Cybersecurity Performance Goals прямо указывает: в промышленных системах контроль доступа должен быть сбалансирован, а MFA допускается только с гарантированным аварийным обходом. Другими словами, в АСУТП обязаны существовать резервные аварийные учётные записи или механизмы входа, которые не зависят от внешних сервисов, токенов или смартфонов.

При отсутствии такого обхода внедрение MFA недопустимо, поскольку увеличивает риск простоя, усложняет реакцию персонала и создаёт реальную угрозу безопасности технологического процесса и жизни людей — например, если инженер не смог вовремя получить доступ для перевода установки в безопасный режим.

6. Полный запрет удаленного доступа – удар по надежности. После известных инцидентов вроде взлома через TeamViewer, на многих предприятиях полностью отключили удаленный доступ к АСУ ТП. Казалось бы, безопасность возросла. Но реальность такова: инженерам и подрядчикам все равно нужен доступ для диагностики – и они найдут обходной путь. Обычно это теневые решения: подключают собственные 4G-модемы, пробивают дырки через смежные сети, используют неучтенные VPN. Эти каналы еще менее контролируемые и безопасные. CISA в своих материалах по безопасности АСУ ТП подчеркивает: «запрет удаленки должен быть заменен на безопасную реализацию удаленного доступа (ограниченный VPN, запись сессий, доступ по запросу и т.д.)». Канадский центр кибербезопасности в руководстве по АСУТП также говорит: нужно не отключать доступ совсем, а обеспечить управляемый удаленный доступ, иначе компания рискует получить «дыры» еще хуже. Пример: предприятие вырубило штатный VPN – и инженеры начали оставлять открытыми модемы. В итоге риск взлома стал выше, а время на ремонт – дольше (ведь без удаленки приходилось ждать прибытия персонала на объект).

Подведем итог: если мера ИБ ухудшает контролируемость процесса, снижает доступ или увеличивает задержки – это уже не защита, а риск для производства. В системах АСУ ТП главным критерием надежности является устойчивость непрерывной работы, а не количество «закрытых уязвимостей» в отчете.

Ущерб для инженерии и инноваций: безопасность мешает работать

3. Софт не установить, а что установлено не работает. Типовая картина на инженерной станции: у специалиста нет прав администратора – он не может установить нужное ПО. Ему запрещено запускать скрипты, менять настройки, обновлять драйверы – политика ИБ не позволяет. Более того, при запуске узкоспециализированных программ (например, для калибровки датчиков) антивирус блокирует их как «неподписанные». В результате, чтобы поставить нужный софт, инженер пишет заявку в ИТ, ждет день, получает отказ («программы нет в белом списке»). Если просит поставить ИТ-шников – те не знают, что это за ПО, и тоже отказывают. 

Кто защищает – тот и ломает: системные изъяны организации

Когда завод внедряет «информационную безопасность» в АСУ ТП чисто по корпоративным стандартам, ответственность за последствия размывается. Производство думает: «этим занимается ИБ». ИБ говорит: «мы только защищаем, за остановки не отвечаем». В итоге, если конвейер встал из-за неправильно настроенного DPI-фильтра, виноватых нет или виноваты все сразу. Но на практике руководство будет спрашивать с производственников, у которых формально «не хватило экспертизы предотвратить сбой». Рассмотрим ключевые организационные проблемы, усугубляющие положение:

1. ИБ работает по чек-листу. На многих предприятиях команда кибербезопасности действует по типовой схеме: включить многофакторную аутентификацию, запретить USB, внедрить антивирусную защиту и обнаружение и реагирование на конечных точках, отключить удаленку, включить мониторинг аномалий. Откуда этот список? Чаще всего это просто копия политик корпоративной ИТ-сети или модные рекомендации из последних стандартов. Но в АСУ ТП все эти пункты имеют и оборотную сторону:

– многофакторную аутентификацию может тормозить аварийный вход в SCADA;

– USB-порты зачастую единственный способ перенести данные между изолированными контурами (инженерным ноутбуком и АРМ ПЛК);

– антивирус может блокировать процессы SCADA;

– удаленный доступ критичен для диагностики и обслуживания;

– «мониторинг» (непрошенные сканы, сбор телеметрии) может создавать ложные аварии и отвлекать операторов.

ИБ при этом не занимается моделированием рисков, не реализует полноценный проект – оно просто «внедряет политику» и затем «мониторит аномалии». А аномалиями в такой ситуации становится нормальная работа системы. Иными словами, чек-лист, скопированный бездумно, ломает отлаженный процесс, хотя на бумаге все пункты «закрыты».

2. Производство боится сказать «нет». Служба эксплуатации часто понимает: если ИБ ставит свой агент на сервер SCADA – будет хуже (SCADA начнет тормозить, возможно собьется тайминг). Но отказать открыто не может – ИБ в приоритете по распоряжению сверху. Значит, будут молча терпеть: интерфейсы виснут, контроллеры лагируют, операторы ругаются, но никто не осмелится снять навязанный агент. Инженеры боятся спорить, потому что: «так приказало начальство», «иначе нас сделают виноватыми при инциденте», «вдруг отключат удаленку совсем, если будем возражать». Формируется культура покорности вместо диалога. Это опасно: скрытые проблемы копятся, о них молчат до последнего, ситуация ухудшается без обратной связи.

3. Ответственность не назначена. ИБ «защищает», производство «эксплуатирует». А когда SCADA зависла – кто виноват? ИБ скажет: «мы ничего не ломали, это техника подвела». Производство ответит: «мы не просили никаких изменений, это они поставили обновление». В результате возникают организационные противоречия – никто конкретно не отвечает за системные сбои, случившиеся из-за ИБ-изменений. Инцидент разбирают как «технический», хотя истинная причина – управленческая. Без четкого распределения ответственности ситуация повторится снова.

4. Интегратор: «гарантия до дверей». Часто внедрение ИБ-средств в АСУ ТП отдают на аутсорс: приглашенная фирма ставит межсетевые экраны, системы обнаружения вторжений, шлюзы, настраивает SOC-коннекторы, пишет отчет – и исчезает. Дальше завод остается один на один с этой «черной коробкой безопасности». Но никто на месте не знает, как тонко настроен DPI-фильтр (и не режет ли он нужные пакеты); никто не умеет толком читать алерты SIEM; никто не уверен, к��к правильно выключить/отключить EDR в аварийной ситуации. Система вроде бы есть, но ее боятся трогать. В лучшем случае просто игнорируют (не реагируют на алерты), в худшем – отключают вовсе. То есть деньги потрачены, галочки проставлены, а пользы нет или даже вред. Интеграторы не несут ответственности спустя год, они уже на другом проекте. А у завода – чужеродная система без поддержки. Правильный подход – развивать внутренние компетенции и владеть ситуацией, но это требует времени и инвестиций, на которые часто идут неохотно.

5. Культура страха наказания вместо культуры безопасности. Вместо того чтобы вместе с инженерами обсуждать риски и проектировать разумную защиту, ИБ-служба нередко выступает как карательный орган. Их задача – «найти виноватого» после инцидента, а не предотвратить его вместе. Это разрушает доверие: инженеры скрывают, что у них «горит» – боятся, что случай классифицируют как инцидент и накажут. Не просят помощи у ИБ – боятся, что вместо помощи просто заблокируют работу. Прячут логи, отключают мониторинг, маскируют баги, лишь бы не привлекать внимания службы безопасности. В такой атмосфере никакой реальной безопасности не получается – напротив, риски замалчиваются и накапливаются. Культура страха рождает отчетность ради отчета, а не реальную надежность. ИБ думает, что все под контролем (инцидентов ведь нет на бумаге), а на самом деле люди просто боятся сообщать о проблемах. Такая культура не защищает. Она ломает.

В итоге, пока в АСУ ТП нет общей ответственности, пока ИБ действует шаблонно, а инженеры работают под страхом наказания, система не будет надежной. Безопасность – это не свод правил, а совместная инженерия с доверием, контекстом и пониманием процесса. Если этого нет, формально «защищенное» предприятие на самом деле уязвимо изнутри.

Кадровая ловушка: нет людей – нет квалификации – нет понимания

Одна из самых опасных угроз для АСУ ТП сегодня – вовсе не хакеры и вирусы, а кадровая деградация. Когда безопасность проектируют те, кто не понимает основ автоматизации. Когда решения внедряют люди, никогда не державшие в руках осциллограф. Когда оценку риска пишут сотрудники, ни разу не видевшие ПЛК в работе. Разберем эту проблему:

1. Люди из ИТ не понимают АСУ ТП. Большая часть специалистов по ИБ в промышленности приходит из классического ИТ. Они хорошие сетевики или админы, но не знают, что SCADA и HMI не терпят задержек отклика; не понимают, что контроллер – не сервер и не может быть просто перезагружен; не осознают, что цикл опроса датчиков должен быть строго детерминированным и любая переменная задержка критична. В итоге они переносят ИТ-подход в производство как будто это тот же офис, только с «железками». ENISA отмечает, что одной из причин уязвимости промышленных систем является недостаточное понимание инженерных процессов специалистами по ИБ. Другими словами, защищать АСУ ТП пытаются люди, которые не до конца понимают, что именно защищают и, сами того не желая, создают новые проблемы.

2. У инженеров нет языка, чтобы объяснить. Инженеры эксплуатации обычно прекрасно видят, что EDR мешает работе, что сканеры вызывают сбои, что без удаленки невозможно нормально обслуживать систему. Но они не могут доказать это на языке ИБ. Нет общей терминологии, нет культуры общения между цехом и ИБ. Инженер скажет: «ваш агент грузит ПЛК, все лагает» – ИБ-шник в ответ потребует формальных метрик и обоснований, которых у инженера нет. Таким образом, даже понимая риски, инженеры не в состоянии их корректно донести до службы безопасности. Отсутствие общего языка приводит к тому, что каждый остается при своем мнении, а проблемы не решаются.

3. Курсы не спасают. В последние годы многие ИБ-специалисты прошли курсы по «Безопасности АСУТП» и получили сертификаты. Казалось бы, вот оно решение – обучить ИТ-кадры особенностям производства. Но этого недостаточно. Пройти курс – не значит понять инженерию. Без практики, без погружения в физику процессов, без живого опыта – такие «защитники» опаснее хакера. Они знают термины (SCADA, PLC, HMI), но не чувствуют, как эти системы реально живут. Как шутят сами инженеры, “сертифицированный специалист по АСУТП-безопасности, ни разу не державший мультиметр – это как пилот, изучивший теорию, но ни разу не севший за штурвал”. Dragos в своем отчете за 2023 год отмечает, что большая часть инцидентов происходит не из-за внешних атак, а из-за ошибок при интеграции ИБ-решений (то есть ошибок людей со стороны безопасности). Это подтверждает, что поверхностное обучение не решает проблему, нужны глубокие междисциплинарные специалисты.

4. Без доверия и знаний ИБ превращается во вред. Если инженеру не верят, он перестает проявлять инициативу. Если ИБ действует без знания процесса – это не защита, а новый риск. Без общего языка, без общих целей и понимания специфики, ИБ в АСУ ТП работает во вред. В итоге мы получаем двойной провал: никто не понимает, что делает, и никто не может это исправить. Инженеры отстраняются от вопросов безопасности (“все равно не слушают”), ИБ-шники действуют в вакууме. Это тупик.

Вывод прост: ИБ в АСУ ТП должна строиться инженерами или хотя бы вместе с ними. Без инженерной экспертизы любая политика безопасности теряет связь с реальностью. А без доверия к инженерам безопасность превращается в тормоз. Необходимо выращивать кадры, которые понимают оба мира, и формировать команды смешанного типа. Это долгий путь, но альтернативы нет – иначе разрыв будет только расти.

Пример незрелости – DMZ и документация. Типичная ситуация: компания поспешила внедрить DMZ между офисной и технологической сетью (выполнив, казалось бы, требование стандарта). Снаружи красиво: интернет перекрыт, прокси фильтрует трафик. Но внутри: инженер подключен к ПЛК на технологической сети, и не может скачать документацию или прошивку, потому что сайты вендоров заблокированы, FTP и HTTPS запрещены политикой, Wi-Fi на ноутбуке отключен. Стоя у станка, специалист не может устранить неисправность, т.к. не имеет доступа даже к мануалу. Чтобы обойти это, он идет на офисный компьютер вне DMZ, скачивает файл на флешку, несет обратно – теряя часы времени. Производство стоит, но политика безопасности «работает». Это классический пример внедрения защиты в неподготовленную инфраструктуру: вместо пользы – вред и неэффективность.

Решение: повышать зрелость – обеспечивать удобные безопасные инструменты. На зрелом предприятии ту же задачу решают иначе: DMZ остается, но внутри нее создается локальный репозиторий документации, драйверов и прошивок – зеркала сайтов производителей, архив инженерных библиотек. Система автоматически синхронизируется с интернетом через шлюз с антивирусной проверкой, а инженер получает все необходимое локально. Без прямого доступа наружу, без флешек и без задержек ремонта. Это пример зрелого решения: безопасность реализована так, что не мешает, а помогает (защита от внешних угроз есть, а время ремонта не увеличилось ни на минуту).

Уровни зрелости для ИБ. Условно можно выделить три уровня зрелости АСУ ТП с точки зрения внедрения безопасности:

– Низкий: Архитектуры нет, инженерные станции не учтены, документация устарела – любая ИБ-мера вызывает сбои (вначале нужно структурировать систему).

– Средний: Есть карта сети, базовая сегментация, но нет внутренних инструментов поддержки (тестового стенда, локальных репозиториев) – прямое внедрение рискованно, требуется адаптация (стенд, дополнительные сервисы).

– Высокий: Внедрены DMZ, есть тестовый стенд, локальные сервисы для инженеров (обновления, документация), доверенные инженерные ПК – ИБ внедряется без ущерба доступности.

Главный показатель зрелости: ИБ не замедляет реакцию инженера. Если после внедрения всех мер инженер все так же быстро может восстановить работу, как и до них, – система зрелая. Если нет – значит, ее еще нельзя «нагружать» безопасностью, надо сперва повысить ее определенность и управляемость. В противном случае киберзащита, установленная на сырой фундамент, сделает только хуже. Правило: если инженер не может восстановить работу так же быстро, как раньше – внедрение ИБ должно быть приостановлено до наведения порядка. И наведение порядка это не только для внедрения ИБ, а инвестиция в стабильную работу предприятия. 

6. Давать системе защищаться самой. Наконец, нельзя забывать, что АСУ ТП может защищать себя сама многими способами, и их надо использовать прежде, чем вносить внешние надстройки. Современные промышленные устройства – контроллеры, SCADA, даже привода – имеют встроенные функции безопасности (concept security by design), которые часто отключены или игнорируются. Надо не плодить костыли, а включить то, что уже предусмотрено производителем оборудования.

Политики ИБ пишутся людьми, не знающими архитектуру ПЛК, – им проще запретить все внешне, чем разобраться во встроенных функциях. Потому что «в методичке не прописано». Потому что ИБ действует сверху вниз, не слушая инженеров. А ведь если дать системе защищаться самой, можно повысить безопасность кратно, без лишних надстроек и без вреда для процесса.

Пример: вместо того чтобы ставить дополнительный шлюз с контролем доступа между HMI и PLC, можно включить на самом контроллере аутентификацию с ролями и шифрование связи (как в S7-1500 с защитой по ролям и TLS). Тогда даже если злоумышленник попадет в сеть, он не сможет командовать ПЛК без ключа. И при этом нет ни задержек, ни конфликтов с процессом – контроллер изначально на это рассчитан. Таких примеров много. АСУ ТП может быть защищенной, надежной и удобной для работы – но только если безопасность спроектирована с учетом логики системы, а не в отрыве от нее. Хорошая безопасность – та, которую проектируют инженеры, которая встроена и не мешает работать.

Если не поменять подход – будет хуже

ИБ в АСУ ТП сегодня во многом напоминает лекарство без дозировки. Его дают «на всякий случай», по ИТ-рецепту, без диагностики, без учета противопоказаний, без понимания, как оно взаимодействует с «телом» производства. Как любое лекарство, примененное неправильно, оно превращается в яд. Эта статья не про отказ от безопасности, а про то, что безопасность без инженерии – не защита, а риск. Что защита без доверия – это саботаж. Что политика без понимания – это угроза.

На заводе должен действовать принцип врача: «не навреди». Если безопасность мешает реагировать – она опасна. Если инженеры не могут работать – это риск. Если системы «защищены» так, что их нельзя обслужить – это не ИБ, а уязвимость.

Что нужно менять:

• Процесс: внедрение ИБ должно происходить через инженеров, с их участием, на их тестовых стендах, с их согласованиями на каждом шаге.

• Культуру: перестать считать инженеров врагами. Начать слушать тех, кто знает, как работает завод. Объединять ИБ и производственныне-команды, устраивать совместные учения, создавать роли «инженер по кибербезопасности» из числа опытных инженеров.

• Ответственность: ИБ должна отвечать и за последствия (остановки), а производство – участвовать в обеспечении безопасности. Вместе, без перекладывания, на равных.

• Архитектуру: проектировать ИБ как часть системы, а не как внешнюю «коробку», надетую поверх.

И самое главное:

АСУ ТП умеет защищаться сама – нужно просто не мешать ей. Доверие, инженерный подход, понимание процесса – и только потом технологии. Вот тогда защита будет работать не во вред, а во благо.