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

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

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

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

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

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

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

1. Что такое «останов» на практике. Представим несколько ситуаций: сломался датчик температуры – линия не запускается. Зависла SCADA из-за обновления антивируса – оператор не может управлять установкой. Отключили удаленный доступ – инженер не может провести диагностику. DLP-система блокирует выгрузку логов – непонятно, где искать ошибку. Во всех случаях оборудование стоит, производство не идет, компания терпит прямые убытки. На языке финансов простои – это потерянная прибыль и дополнительные расходы, вне зависимости от того, «кибератака» это или обычная поломка.

2. Поломки ежедневны, а атаки редки. В цехах датчики, клапаны, двигатели выходят из строя постоянно, ежедневно. А вот вирусы, шифровальщики, целевые атаки на SCADA – явление столь редкое, что многие инженеры за всю карьеру ни разу с ними не сталкивались. В 99,999% случаев основные потери на производстве создают именно отказавшие агрегаты и компоненты, банальные поломки «железа». Киберинциденты случаются на порядки реже. (Можно провести опрос в комментариях. Пишите ваш стаж работы если вы работаете инженером на заводе и количество инцидентов, с которыми вы сталкивались.) Таким образом, главный враг безотказной работы – не хакер, а естественный износ и сбои техники.

3. А ИБ… тормозит ремонт. Когда происходит поломка, инженеры знают, что делать: подключиться к контроллеру для диагностики, просмотреть архивы в SCADA, снять тренды датчиков, установить драйверы или перепрошить модуль – то есть, устранить неисправность как можно быстрее. Но что происходит, когда на пути ремонта встают меры ИБ? Антивирус блокирует установку нужного драйвера для контроллера. VPN или сетевой доступ закрыт – инженеру с необходимой квалификацией не подключиться удаленно к системе. Многофакторная аутентификация (MFA) сломалась или глючит – оператор не может войти в HMI/SCADA. Закрылся порт в конфигурируемом свиче, а ИТ специалиста с правами на редактирование параметров в ночную смену нет. В итоге ремонт задерживается, простой длится дольше, убытки растут. Инженерам же поневоле приходится превращаться во взломщиков – искать, как обойти собственные средства безопасности, чтобы запустить оборудование. Иначе говоря, когда чрезмерная ИБ препятствует устранению обычной аварии, предприятие теряет больше денег, чем если бы никакой «защиты» вовсе не было.

4. Если вируса не будет убыток останется. Допустим, SCADA-сервер упал из-за вируса-вымогателя. Придет инженер, заменит диск, зальет резервную копию системы – меньше чем через час работа восстановится. А если SCADA зависла из-за обычного сбоя или поломки – действия те же: замена, бэкап, перезапуск. По времени и потерям ситуация идентична. Получается, даже в теории традиционные средства ИБ не уменьшают убытки от остановов. А на практике зачастую увеличивают, мешая инженерам быстро устранять неполадки. Если из-за политики безопасности инженер вынужден чинить не 2 часа, а 24 часа – убытки растут многократно.

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

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

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

Финансовые потери. Ошибочные меры ИБ влекут прямые финансовые убытки. Как я уже писал, простои оборудования из-за сбоев, вызванных средствами защиты, означают потерю выручки. Для предприятий с непрерывным циклом даже кратковременная остановка – это миллионы рублей убытков, связанных с простоем и повторным запуском процесса. Реальные цифры подтверждают этот порядок: даже одна технологическая линия может терять десятки миллионов рублей в год на простоях. Международные исследования показывают аналогичную картину: средняя стоимость часа простоя для крупных компаний превышает 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 триллиона долларов США».

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

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

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

Риски для безопасности и оборудования. Парадоксально, но неправильные действия службы ИБ могут создать новые риски для самой технологической безопасности. Если средство защиты мешает сработать штатной системе безопасности или искажает критические сигналы, возникают прямые угрозы аварии. Известен случай на АЭС Hatch (США, 2008): установка обновления ПО на одном из компьютеров, связанного с АСУ ТП, сбросила в ноль данные об уровне воды в реакторе – системы безопасности восприняли это как падение уровня и автоматически заглушили реактор. То, что с точки зрения ИТ было «обычным патчем», в технологическом мире стало триггером ложной аварии и остановило блок на 48 часов. В отчёте Industrial Security Incident Database отмечено: внедрение обновлений или антивирусных патчей в среду АСУ ТП вызвало остановку производства. АЭС Browns Ferry (США, 2006) – сбой из-за сетевого трафика. На блоке №3 атомной станции Browns Ferry произошло аварийное отключение реактора вследствие остановки двух насосов циркуляции. Расследование показало, что причиной был “шторм” сетевого трафика на внутренней сети управления – контроллеры насосов перегрузились избыточными данными и зависли. Иными словами, отсутствие должной сегментации и контроля трафика между узлами АСУ ТП привело к тому, что единичная сетевая аномалия вывела из строя критически важные устройства. Кейc показателен тем, что обычные ИТ-практики (как высокая связность сети без изоляции) неприемлемы в АСУ ТП, где устройства не рассчитаны на массовый трафик и могут отказать. С точки зрения ущерба, станция понесла дорогостоящий простой, а инцидент привлёк внимание регуляторов, заставив пересматривать подход к безопасности.

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

Перенос ИТ-логики в производство: эволюция ошибки

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

Сравним приоритеты ИТ и АСУ ТП:

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

• Цикл обновлений: В ИТ – 1–2 года, постоянно ставятся патчи. В промышленности оборудование эксплуатируется 10–30 лет без кардинальных обновлений. При этом оборудование работает на максимальном пике производительности, обусловленном механикой и любые изменения программного обеспечения никаких ускорений ему не придают. 

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

• Методы защиты: В ИТ – регулярные патчи, IDS, антивирусы, сегментация сетей. В АСУ ТП – резервирование компонентов, отказоустойчивые контроллеры и сети, предохранительные устройства (ПАЗ), мониторинг состояния, технологические блокировки, организационные меры (инструктажи, регламенты). Иными словами, производственная-защита интегрирована в саму систему управления (системы резервирования, аварийные защитные механизмы), а не навешана сверху.

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

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

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

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

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

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

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

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

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

Голос стандарта: что говорит NIST SP 800-82

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

• Тестировать каждое изменение. Любой патч, обновление, установка агента безопасности должны проходить стендовую проверку перед разворачиванием в промышленной сети. В продакшен – только после подтверждения совместимости. 

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

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

Несмотря на эти прямые предупреждения, многие корпорации продолжают проводить агрессивные тесты и сканирование на работающем оборудовании без остановов – и получают закономерные сбои. 

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 – и инженеры начали оставлять открытыми модемы. В итоге риск взлома стал выше, а время на ремонт – дольше (ведь без удаленки приходилось ждать прибытия персонала на объект).

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

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

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

1. Удаленного доступа нет – остается бегать по цеху. На многих предприятиях внешним специалистам и даже своим инженерам запрещают любой удаленный доступ к SCADA, контроллерам, инженерным станциям. Результат: при ЧП инженер должен физически бежать к шкафу управления, входить локально на HMI или PLC. Если забыл нужную флешку с ПО или драйвером – возвращается в офис, потом снова бежит. И так по многу раз, пока не устранит проблему. Это не только неудобство, но и потеря драгоценного времени. CISA и ISA прямо говорят: не надо запрещать удаленку совсем – нужно внедрять ее безопасно. Если бы вместо полного бана организовали контролируемый удаленный доступ, инженер решал бы часть задач дистанционно за минуты, а не тратил часы на беготню. Запрет же привел к тому, что специалисты иногда рискуют – открывают теневые каналы или попросту мирятся с более долгим простоем оборудования.

2. Запрет Wi-Fi – инженер в информационном вакууме. На ряде объектов всю беспроводную связь в цехах блокируют «в целях безопасности». В итоге у инженера нет Wi-Fi для ноутбука:

– Нет онлайн-доступа к процессу с удобного места;

– Нет оперативных трендов и телеметрии при ремонте;

– Нет возможности в цеху подключиться к аварийной SCADA или базе знаний.

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

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

• Ericsson — автоматическое распределение баг-репортов

  • Инженерная команда Ericsson разработала внутреннее решение для автоматического назначения баг-отчётов.

  • Результат: около 30% входящих баг-отчётов обрабатываются без ручного вмешательства, среднее время решения сокращается примерно на 21%.  

• Bosch — внутренний проект по улучшению линий сборки

  • Инженеры Bosch (через проект Kaggle) использовали свои данные, разработали алгоритм предсказания отказов на сборочной линии. 

  • Результат: улучшено управление браком и снижены затраты.

– Автоматический стенд для тестирования модулей питания. Инженер небольшой компании самостоятельно собрал испытательный стенд на Python для автоматизации ручной проверки блоков питания. Раньше проверка одного модуля занимала около 4 часов. После внедрения кнопки «Проверить» на стенде 5 модулей тестируются за 75 минут вместо нескольких дней. Выпуск продукции ускорился в разы, операторы избавлены от рутинных операций. Проект реализован одним инженером (включая написание ПО) без внешних подрядчиков – а выхлоп колоссальный по росту производительности.

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

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

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

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

Когда защита опаснее атаки: страх разрушает систему

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

1. Система становится заложником собственных правил. Когда вводят жесткие политики, нередко возникают ситуации, напоминающие самоатаку:

– Файрвол не пускает своего же инженера к SCADA, потому что его IP не в белом списке.

– EDR удаляет драйвер устройства, необходимый для работы, потому что тот не подписан сертификатом.

– Прокси-сервер блокирует сайт с техническим мануалом, потому что домен «не доверенный».

Итог: не атака, не авария, не сбой – система сама себя блокирует. Это уже реальность на некоторых объектах: компания выстроила столько барьеров вокруг, что легитимные действия стали невозможны. С точки зрения злоумышленника можно отдыхать – предприятие само себе  dDoS устранило во имя безопасности.

2. Аварийный доступ отсутствует. В любой АСУ ТП должен быть быстрый способ вмешаться, если что-то пошло не так – иначе мелкий сбой может перерасти в крупную аварию. Но чрезмерная ИБ часто убивает механизмы аварийного реагирования. Например: удаленный доступ отключен вовсе; вход в SCADA требует MFA и VPN; у инженера нет возможности наблюдать процесс удаленно, он боится экспериментировать, потому что не видит, что реально происходит с оборудованием; сертификат для входа истек, и в экстренный момент инженер просто не может войти в систему. В итоге цех встал не потому, что кто-то атаковал, а потому что никто не смог вовремя зайти и поправить ситуацию. Фактически предприятие своими руками создало себе «кибер-ЧС», лишив себя инструментов реагирования.

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

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

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

Что делать: подход к безопасности, который не разрушает

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

1. Не копировать, а адаптировать. ИБ в АСУ ТП – не ИТ. Все политики, процедуры, инструменты должны быть адаптированы под технологический процесс, а не слепо перенесены из офиса. Это главное правило. Если нужен межсетевой экран – ставить только тот, что поддерживает промышленные протоколы и способен работать в реальном времени (иначе лучше вообще без него). MFA? Да, но только если есть механизм аварийного bypass (обхода) на случай сбоя. EDR? Только тщательно протестированный совместно со всем необходимым ПО на отсутствие лагов. Удаленный доступ? Не запрещать, а сделать безопасным (через VPN с контролем, через jump-сервер, с записью операций). Классический пример: на одном объекте долго запрещали Wi-Fi «для безопасности», пока не поняли, что проще сделать защищенную корпоративную Wi-Fi сеть для инженерных нужд (с WPA-Enterprise, VLAN изоляцией), чем смотреть, как специалисты мучаются без связи. А запрет флешек? Если USB – единственный способ переноса, то лучше внедрить USB-сканеры (кибер-гигиенические блоки) на входе, чем пытаться вовсе исключить флешки и получить неконтролируемые обходы. Смысл прост: отходите от догм ИТ-безопасности и ищите компромиссные решения под реалии производства.

2. Тестировать на стенде. Нельзя ставить средства ИБ сразу в рабочий контур без опробования. Только через тестирование – это должно стать железным правилом. У предприятия обязан быть тестовый стенд, максимально приближенный к боевой системе: там проверять обновления, агенты, сканеры, настройки NGFW и прочее. Замерять задержки, смотреть, не появилось ли потерь пакетов, как ведет себя HMI под нагрузкой с агентом. Если стенда нет – его надо создать, иначе любое изменение на живом оборудовании равносильно эксперименту на работающем реакторе. Многие компании говорят «у нас нет времени/ресурсов на стенд» – тогда возникает вопрос: а есть ли у вас время и деньги на простой из-за неоттестированного патча? NIST и здесь четко указывает: «все действия по безопасности должны тестироваться перед внедрением». Стенд – не опция, а обязательный этап. Без него – никак.

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

4. Делать ИБ частью процесса, а не надстройкой. Безопасность должна проектироваться вместе с системой, а не после, «сверху». Если изначально, при модернизации или построении АСУ ТП, закладывать требования безопасности (совместно инженеры и ИБ), то потом не придется ломать через колено. Это и есть принцип «Secure by design». Практически: команда ИБ должна участвовать в проектах модернизации производства наравне с инженерами, чтобы понимать процессы. И наоборот, инженеры должны участвовать в разработке политики ИБ для своего цеха. Нужно добиться общего языка и общих целей: чтобы и те, и другие говорили, например, не «мы закроем 100% портов», а «мы сохраним 100% доступности». Когда все понимают границы – где можно ставить защиту, а где нельзя трогать – получаются сбалансированные решения. Например, если нужно сегментировать сеть – инженеры подскажут, какие узлы критичны и всегда должны общаться напрямую. Если нужно ограничить доступ – инженеры подскажут, какой сервис жизненно важен и должен остаться. Без этого получается, что ИБ “рисует” архитектуру без понятия о технологических связях, а потом удивляется, почему “что-то сломалось”. Хорошая безопасность – та, которая встроена в систему и не мешает работать.

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

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

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

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

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

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

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

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

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

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

Например, рассмотрим программируемые логические контроллеры ведущих марок. Почти все новые модели обладают встроенными механизмами предотвращения несанкционированного доступа, изменения логики и прошивки:

• Siemens SIMATIC S7-1200/1500: поддерживают многоуровневую защиту проекта – пароли на чтение/запись, защиту блоков кода (know-how protection), привязку программы к конкретному CPU (copy protection), контроль целостности прошивки и проекта, управление пользователями и ролями на уровне контроллера, защищенные соединения (PG/OPC UA) по TLS, подписанные обновления прошивки. Эти функции позволяют аутентифицировать сессии между инженерной станцией, HMI и ПЛК, разграничивать права (только просмотр, управление или программирование). Siemens подробно документирует все меры в концепции безопасности.

• Rockwell (Allen-Bradley) ControlLogix 5380/5580: поддерживают стандарт CIP Security для аутентификации узлов и шифрования данных на основе сертификатов или предустановленных ключей. Реализованы физический переключатель Run/Prog для защиты от несанкционированной перепрошивки, функция Trusted Slot (привязка разрешения загрузки программы к определенному слоту в шасси). В старых прошивках Trusted Slot имел уязвимости (отмечено CISA), поэтому производитель выпустил патчи – т.е. надо просто поддерживать актуальные версии, и защита работает.

• Mitsubishi Electric MELSEC iQ-R: имеет расширенные функции безопасности: IP-фильтрация (разрешение соединений только с доверенных IP), парольная защита проектов до 32 символов, блокировка загрузки/исполнения программ без ключа, защита проектных данных (открыть проект можно только с зарегистрированным ключом). То есть контроллер сам умеет ограничивать доступ и код без внешних средств.

• Schneider Electric Modicon M580: как Ethernet-PAC нового поколения содержит встроенные механизмы: подписанные проверяемые обновления прошивок, управление пользователями и паролями на CPU, поддержку IPsec в коммуникационных модулях (режим Authentication Header). IPsec дает аутентификацию, контроль целостности и защиту от spoofing/replay, причем трафик не шифруется (чтобы не было задержек). Также Schneider развивает Secure Modbus (TLS) и CIP Security в новых прошивках, хотя на момент публикации это частично реализовано для отдельных моделей.

Современные SCADA и HMI-платформы также имеют ряд встроенных средств безопасности:

• Аутентификация и разграничение прав: многоуровневая система пользователей (оператор, инженер, администратор и т.д.) с гибкими правами – просмотр экранов, изменение уставок, отправка команд, изменение конфигурации или скриптов. Все крупные SCADA (Siemens WinCC, Aveva/Wonderware, GE iFIX, Schneider EcoStruxure/Citect и др.) это поддерживают.

• Аудит действий: SCADA ведут журналы всех действий пользователей – входы, изменение параметров, квитирование аварий, команд – с сохранением в базах и экспортом в SIEM при желании. Например, опции WinCC Audit, Aveva Historian Audit Trail, GE Alarm DB позволяют отслеживать, кто что сделал.

• Подтверждение критичных операций: на важных действиях (останов технологического процесса, включение опасного механизма) системы требуют дополнительного подтверждения – диалог «Вы уверены?» или даже второй подписи. Это снижает риск ошибочных команд.

• Шифрование и защита соединений: передача данных между серверами и клиентами защищается TLS/SSL. WinCC (Professional/Unified) поддерживает защищенные соединения HMI, OPC UA, веб-доступа; Aveva и iFIX используют TLS 1.2/1.3 для клиентов и веб-порталов; Schneider Citect и EcoStruxure тоже имеют опции шифрования и аутентификации для клиентов. Многие решения позволяют интеграцию с Active Directory для централизованного управления учетками и поддержку 2FA при удаленном доступе (через VPN или веб).

• Безопасность панелей HMI: аппаратные операционные панели (Siemens, Schneider, Mitsubishi и пр.) имеют встроенные функции: пароли на доступ к экранам (оператор/инженер/сервис), авто-выход при бездействии, блокировка несанкционированных изменений конфигурации, возможность загружать только подписанные проекты (предотвращает подмену). Также они поддерживают защищенные протоколы (например, OPC UA с шифрованием и сертификатами вместо старых незащищенных протоколов).

• Встроенные веб-интерфейсы в устройствах (ПЛК, HMI, сетевые коммутаторы) по умолчанию отключены либо работают только через HTTPS с обязательной аутентификацией. Это предотвращает несанкционированный доступ к настройкам оборудования через сеть.

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

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

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

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

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

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

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

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

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

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

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

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