Дисклеймер

Эта статья — продолжение большой дискуссии, которая началась под моей предыдущей публикацией https://habr.com/ru/articles/971788/ про избыточность мер ИБ в АСУ ТП.

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

Почему это важно?

Потому что:

• в комментариях под первой статьёй поднялись реальные кейсы

• там хорошо видна разница в мировоззрении между ИБ и эксплуатацией

• многие аргументы, которые здесь разбираются, появились именно в дискуссии

• без этого бекграунда часть тезисов будет выглядеть слишком резкой или странной

Эта статья не существует отдельно —она родилась именно как ответ на типовые возражения, которые звучали снова и снова.

Если кратко:

• Первая статья — про то, как некорректно внедрённая ИБ ломает технологические процессы.

• Комментарии — про то, почему ИБ считает, что этого «не может быть», и что «инженеры сами виноваты».

• Эта статья — про то, почему реальность на заводах устроена иначе и почему аргументы ИБ часто не работают в контуре АСУ ТП.

Прочитайте комментарии — и многие вещи ниже станут намного понятнее.

Моя первая статья на тему ИБ в АСУТП https://habr.com/ru/articles/890612/ собрала много эмоциональных комментариев от специалистов по ИБ.

Эта — не «ответ одному человеку», а попытка спокойно развернуть ключевые мысли, которые в комментарии уже не помещаются.

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

1. Кто на самом деле критичен для завода: инженер или ИБ

Давайте честно посмотрим на расстановку сил.

Если инженер сделает ошибку — в большинстве случаев он же её и исправит.

Если инженера убрать с предприятия, завод через несколько часов или дней встанет, потому что некому будет:

• диагностировать оборудование;

• искать причину аварии;

• выполнять обходы и ППР;

• запускать и останавливать агрегаты;

• восстанавливать работоспособность после аварий.

Теперь представим то же самое со средствами ИБ:

• если отключить большинство наложенных мер ИБ — завод продолжит работать, и часто даже более предсказуемо.

Это не значит, что ИБ «не нужна».

Это значит, что:

• инженер — критический элемент технологического контура;

• ИБ — надстройка, которая должна помогать, а не мешать.

Поэтому ошибки инженера и ошибки ИБ несопоставимы по масштабу и последствиям.

Инженер ошибся — пострадал один узел.

ИБ-компонент ошибся — может лечь весь сегмент сети или вся SCADA.

2. «Обычный инженер может завалить всю сеть» — а ИБ не может?

Один часто встречающийся аргумент звучит так:

«Инженер может одним неправильным действием положить сеть и десятки контроллеров». 

Да, такое возможно — если архитектура изначально плохая.

Но если довести аргумент до конца, получается странная картина:

инженер настолько опасен, что его лучше вообще исключить из процесса.

Только вот завод без инженеров работать не будет.

ИБ сама не станет:

• менять датчики и термопары;

• поднимать линии после аварий;

• проводить ПНР;

• оценивать качество программного обеспечения и модернизировать оборудование. 

При этом есть принципиальная разница:

• инженер делает действия осознанно и на месте. И в большинстве случаев он же восстанавливает систему;

• ИБ-инструмент действующий автоматически, сразу по всей сети, и при проблеме далеко не всегда бывает понятно, что именно сработало.

Ошибка инженера, как правило, локальна и обратима.

Ошибка ИБ часто масштабна и непрозрачна.

И это нельзя игнорировать, когда мы обсуждаем влияние ИБ на реальное производство.

3. Законы, КИИ и подход «сначала внедрим — потом разберёмся»

Вот типичный сценарий последних лет:

• Выходит закон, приказ, методические рекомендации.

• Завод автоматом признаёт себя КИИ или попадает в периметр требований.

• ИБ начинает требовать внедрения мер.

• Только потом кто-то задаёт неудобные вопросы:

  • у нас вообще есть стенды для тестирования?

  • есть ли компетенции сопровождать всё это на площадке 24/7?

  • есть ли бюджет не только купить, но и жить с этим 10–15 лет?

  • выдержит ли технологический процесс такие изменения?

  • нужен ли конкретно этому заводу весь перечень мер?

  • что с вендором, если его ПО 10 лет как снято с поддержки?

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

В итоге:

• ИБ требует: «обкатайте на стенде» — стенда нет и не предвидится;

• ИБ требует: «сегментируйте» — эксплуатация не умеет это сопровождать;

• ИБ требует: «обновляйте» — вендор давно не поддерживает эту версию ПО, а новый софт требует полной переделки. 

И при этом ответственность за простой и убытки несут инженеры.

ИБ — это процесс, да.

Но этот процесс не должен превращаться в самоцель, когда ради «галочки» игнорируются:

• физика процесса;

• жизненный цикл оборудования;

• реальный профиль рисков.

Меры должны выбираться по риску и применимости к конкретной технологии, а не просто потому, что «так написано в документе».

4. Алгоритм ПЛК и firewall: кто кому мешает

Да, неверный алгоритм действительно может нарушить ход процесса.

Но алгоритм — это часть технологического контура:

• им управляют инженеры;

• он прозрачен по логике;

• его можно отладить, откатить, задокументировать.

ИБ — это надстройка.

Она должна дополнять существующую систему, а не ухудшать её.

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

• быстро получать доступ к контроллерам;

• оперативно диагностировать причину;

• использовать отлаженные инструменты;

• иметь предсказуемое сетевое поведение;

• минимизировать барьеры в аварийной ситуации.

Когда поверх этого ставят:

• firewall’ы;

• DPI;

• SSL-инспекцию;

• агрессивные политики;

• автоматические обновления,

которые:

• ломают видимость устройств;

• мешают загрузке или чтению логики;

• добавляют задержки;

• периодически отрывают PLC от SCADA,

то проблема уже не в «кривом алгоритме».

Проблема в том, что надстройка начинает ломать базовый слой.

Появляются новые точки отказа, которых раньше не существовало.

Технологический процесс остаётся прежним, а уровень риска увеличивается только потому, что в систему внесли дополнительную сложность.

Завод — не банк и не офис.

Его нельзя «выключить до завтра ради патча».

АСУ ТП должны работать всегда,

а ИБ должна встраиваться так, чтобы не превращать каждое обслуживание ПЛК в сапёрную операцию.

5. Сегментация: идеальная сеть на бумаге vs скорость ремонта в жизни

Сегментация сама по себе — инструмент неплохой.

Но в АСУ ТП главный принцип другой:

Инженеру нужен быстрый, прямой и прозрачный доступ ко всему оборудованию.

Потому что:

• поломка не ждёт согласований;

• производство нельзя просто «поставить на паузу»;

• время реакции = деньги.

Как только между инженером и оборудованием появляется сетевой лабиринт из VLAN, ACL и маршрутов, доступ перестаёт быть прямым.

Это не история про «глупых инженеров, которые не знают VLAN».

Это история про приоритет:

• инженер должен чинить оборудование;

• не тратить время на диагностику сетевой топологии.

Любой сбой сегментации:

• делает причину поломки менее очевидной;

• заставляет идти ножками по шкафам и стойкам;

• замедляет восстановление;

• увеличивает простой.

То есть сегментация в реальности часто увеличивает время ремонта, а не уменьшает риск аварий.

На производстве важнее скорость восстановления, чем красота схемы сети в Visio.

ИБ должна это учитывать, а не ломать.

6. NGFW, DPI и маркетинг: завод — это не презентация 

Сегодня почти все крупные вендоры продают «промышленные межсетевые экраны»:

• Siemens, Schneider, Rockwell;

• Palo Alto, Fortinet;

• Kaspersky и другие.

Они умеют:

• DPI по S7, Modbus, OPC;

• инспекцию команд start/stop/read/write;

• красивые отчёты и дашборды.

Но сам по себе факт наличия фичи в продукте ещё не означает, что она безопасна для любого процесса и любой площадки.

Он означает только то, что на рынке есть спрос, и его монетизировали.

Кибербезопасность в промышленности сегодня — это отличный рынок и хайп.

Если рынок хочет «DPI по S7» — его сделают, сертифицируют, красиво упакуют.

Но завод — это не PowerPoint.

Промышленное ПО часто самописное или сильно кастомизированное вендором под конкретный объект.

То, что отлично работает с одной системой, может полностью положить другую.

При этом вендоры в документации честно пишут:

• «Use only in validated architectures»

• «Do not apply DPI inline without testing on your specific setup»

• «Timing-sensitive environments require careful evaluation»

То есть:

• функционал продаётся;

• ответственность за последствия — на заказчике.

DPI и SSL-инспекция:

• добавляют задержки;

• ломают multicast;

• требуют распаковки и анализа трафика;

• нарушают детерминизм протоколов.

EtherCAT, Profinet IRT и другие протоколы реального времени очень плохо переносят даже небольшие отклонения по времени, потому что АСУ ТП управляет реальными объектами. И если контроллер в течении определенного времени не получит обратную связь от какого-либо устройства, то он будет считать, что какая-то «огромная железяка» стала неконтролируемой и примет меры для того чтобы перевести её в безопасный режим. 

Да, задержка может быть и от кривого патчкорда.

Но:

• патчкорд меняется за минуту;

• неправильно настроенный DPI чинится часами или днями;

• и ломает он десятки устройств сразу.

Каждый вендор продаёт продукты ИБ,

но никто не гарантирует компенсацию простоя конкретного завода.

На реальном производстве есть один простой критерий:

Помогает ли это работать или мешает?

Если мешает — внедрено неправильно, кто бы ни выдал сертификат.

7. Флешки и фильмы: симптом, а не причина

Разговоры про «оператора, который приносит кино на флешке» — это уход от сути.

Если оператору на смене нечем заняться — это уже проблема организации работы, а не ИБ.

Нормальное производство не должно превращаться в длинную ночную смену без задач.

Но флешка появляется не только из-за фильмов.

Она появляется там, где:

• интернет закрыт наглухо;

• перенос технических файлов запрещён;

• доступ к документации затруднён;

• легальных способов передать логи, отчёты, конфиги нет;

• смена долгая, а инструментов минимум. 

В таких условиях люди неизбежно ищут обходные пути.

Флешка — это просто удобный носитель.

Если цель — убрать флешки, нужно:

• дать нормальный доступ к документации и знаниям;

• предусмотреть безопасный и удобный канал обмена файлами;

• прописать понятные правила.

В 2025 году фильм на телефон скачивается быстрее, чем ищется флешка.

Проблема не в носителе и не в «кино» как таковом.

Проблема в том, что когда ИБ вводит запреты без альтернатив, появляются обходы.

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

8. «Надо работать вместе» — но кто принесёт реальные решения?

Ещё одна популярная мысль:

«АСУ и ИБ должны работать вместе, обмениваться знаниями». 

Звучит правильно.

Но на практике часто выглядит так:

• ИБ инициирует изменения;

• ИБ не даёт стендов и ресурсов;

• ИБ не приносит готовых регламентов и сценариев;

• ИБ не берёт на себя ответственность за простои;

• но ожидает, что эксплуатация сама всё «додумает и сделает».

Нормальная практика во всех областях:

• проектировщик закладывает ресурсы на ПНР;

• технолог закладывает режим отладки;

• метролог — эталоны и поверку;

Только ИБ часто считает, что её изменения должны происходить «сами собой»,

без тестовой инфраструктуры и дополнительных затрат.

Если ИБ требует:

• сегментацию;

• DPI, IDS/IPS;

• обновления ОС;

• Zero Trust;

• усложнение аутентификации,

ИБ и должна предоставить:

• проработанные сценарии внедрения;

• понятные схемы тестирования;

• заранее подготовленные варианты отката;

• согласованный регламент действий;

• прозрачное распределение ответственности;

• финансовое обеспечение необходимых работ и инфраструктуры.

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

И тогда «работать вместе» действительно получится.

Пока этого нет — это не взаимодействие, а сдвиг рисков с ИБ на эксплуатацию.

9. Доступ в аварии и человеческий фактор

Сравнение «забыл пропуск — не зайдёшь на завод» хорошо выглядит на бумаге, но плохо — в цеху.

Пропуск — фильтр для входа на территорию. Его можно забыть где угодно:

в столовой, в раздевалке, в шкафчике.

Для технологического процесса всё гораздо жёстче.

Очень много аварийных ситуаций можно не доводить до ПАЗ, если оператор или инженер вовремя вмешается:

• остановит насос до опасного давления;

• снизит нагрузку;

• включит дополнительное охлаждение;

• выведет контур в ручной режим;

• изменит уставку в нужный момент.

Когда человек на месте видит проблему в реальном времени,

у него есть шанс предотвратить серьёзный ущерб.

Но если в этот момент:

• MFA не проходит;

• токен заблокирован;

• пароль истёк или три раза введён неверно;

• учётка заблокировалась «по требованиям ИБ»;

• это был сарказм про смс;)

человек превращается во вынужденного наблюдателя.

А авария развивается дальше.

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

А теперь представьте оператора, который под давлением времени и страха должен:

• вспомнить сложный пароль;

• не ошибиться три раза;

• ждать таймауты блокировок;

• искать администратора, который перегенерирует токен.

В результате:

• срабатывает ПАЗ;

• продукт улетает в брак;

• оборудованию нужна чистка;

• требуется повторный прогрев и вывод на режим;

• простой длится часы или сутки.

Там, где человек мог обойтись без потерь,

избыточная ИБ делает ПАЗ единственным сценарием.

ПАЗ — это страховка, а не нормальный режим.

ИБ, не учитывающая этот факт, искусственно ухудшает ситуацию.

10. Зачем вообще всё это

Эта статья — не про «firewall плохой, давайте его выкинем».

Она про другое:

• ИБ в АСУ ТП должна быть реалистичной;

• меры должны быть применимы к конкретной технологии;

• и главное — они не должны ломать базовые процессы эксплуатации и ремонта.

АСУ ТП живёт в других временных масштабах:

• оборудование служит по 20–30 лет;

• ОС и ПО снимаются с поддержки задолго до физического износа;

• реинжиниринг стоит как новый цех;

• вендор может просто исчезнуть с рынка.

Перед предприятием в реальности часто стоит простой выбор:

• либо дорогой, долгий и рискованный реинжиниринг;

• либо осторожная, осознанная эксплуатация того, что уже стабильно работает.

Требования ИБ часто подразумевают первый вариант,

не предлагая ресурсов и инструментов под него.

Поэтому главный тезис такой:

ИБ в АСУ ТП должна защищать производство, а не мешать ему работать.

Инженеры — не враги ИБ, а ключевые партнёры.

Но пока диалог строится в формате «мы решили — вы сделайте»,

заводы будут платить за это своими простоями.