Дисклеймер
Эта статья — продолжение большой дискуссии, которая началась под моей предыдущей публикацией 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 лет;
ОС и ПО снимаются с поддержки задолго до физического износа;
реинжиниринг стоит как новый цех;
вендор может просто исчезнуть с рынка.
Перед предприятием в реальности часто стоит простой выбор:
либо дорогой, долгий и рискованный реинжиниринг;
либо осторожная, осознанная эксплуатация того, что уже стабильно работает.
Требования ИБ часто подразумевают первый вариант, не предлагая ресурсов и инструментов под него.
Поэтому главный тезис такой:
ИБ в АСУ ТП должна защищать производство, а не мешать ему работать.
Инженеры — не враги ИБ, а ключевые партнёры.
Но пока диалог строится в формате «мы решили — вы сделайте», заводы будут платить за это своими простоями.