Эта статья — продолжение большой дискуссии, которая началась под моей предыдущей публикацией https://habr.com/ru/articles/971788/ про избыточность мер ИБ в АСУ ТП.
Чтобы не вырывать мысли из контекста, я настоятельно рекомендую сначала прочитать предыдущую статью и хотя бы часть комментариев к ней — особенно комментарии специалистов по ИБ.
Почему это важно?
Потому что:
- в комментариях под первой статьёй поднялись реальные кейсы
- там хорошо видна разница в мировоззрении между ИБ и эксплуатацией
- многие аргументы, которые здесь разбираются, появились именно в дискуссии
- без этого бекграунда часть тезисов будет выглядеть слишком резкой или странной
Эта статья не существует отдельно —она родилась именно как ответ на типовые возражения, которые звучали снова и снова.
Если кратко:
- Первая статья — про то, как некорректно внедрённая ИБ ломает технологические процессы.
- Комментарии — про то, почему ИБ считает, что этого «не может быть», и что «инженеры сами виноваты».
- Эта статья — про то, почему реальность на заводах устроена иначе и почему аргументы ИБ часто не работают в контуре АСУ ТП.
Прочитайте комментарии — и многие вещи ниже станут намного понятнее.
Моя первая статья на тему ИБ в АСУТП https://habr.com/ru/articles/890612/ собрала много эмоциональных комментариев от специалистов по ИБ.
Эта — не «ответ одному человеку», а попытка спокойно развернуть ключевые мысли, которые в комментарии уже не помещаются.
Статья написана с позиции эксплуатации и инженерных служб, которые отвечают за то, чтобы завод работал, а не просто соответствовал требованиям.
- Кто на самом деле критичен для завода: инженер или ИБ
Давайте честно посмотрим на расстановку сил.
Если инженер сделает ошибку — в большинстве случаев он же её и исправит.
Если инженера убрать с предприятия, завод через несколько часов или дней встанет, потому что некому будет:
- диагностировать оборудование;
- искать причину аварии;
- выполнять обходы и ППР;
- запускать и останавливать агрегаты;
- восстанавливать работоспособность после аварий.
Теперь представим то же самое со средствами ИБ:
- если отключить большинство наложенных мер ИБ — завод продолжит работать, и часто даже более предсказуемо.
Это не значит, что ИБ «не нужна».
Это значит, что:
- инженер — критический элемент технологического контура;
- ИБ — надстройка, которая должна помогать, а не мешать.
Поэтому ошибки инженера и ошибки ИБ несопоставимы по масштабу и последствиям.
Инженер ошибся — пострадал один узел.
ИБ-компонент ошибся — может лечь весь сегмент сети или вся SCADA.
- «Обычный инженер может завалить всю сеть» — а ИБ не может?
Один часто встречающийся аргумент звучит так:
«Инженер может одним неправильным действием положить сеть и десятки контроллеров».
Да, такое возможно — если архитектура изначально плохая.
Но если довести аргумент до конца, получается странная картина:
инженер настолько опасен, что его лучше вообще исключить из процесса.
Только вот завод без инженеров работать не будет.
ИБ сама не станет:
- менять датчики и термопары;
- поднимать линии после аварий;
- проводить ПНР;
- оценивать качество программного обеспечения и модернизировать оборудование.
При этом есть принципиальная разница:
- инженер делает действия осознанно и на месте. И в большинстве случаев он же восстанавливает систему;
- ИБ-инструмент действующий автоматически, сразу по всей сети, и при проблеме далеко не всегда бывает понятно, что именно сработало.
Ошибка инженера, как правило, локальна и обратима.
Ошибка ИБ часто масштабна и непрозрачна.
И это нельзя игнорировать, когда мы обсуждаем влияние ИБ на реальное производство.
- Законы, КИИ и подход «сначала внедрим — потом разберёмся»
Вот типичный сценарий последних лет:
- Выходит закон, приказ, методические рекомендации.
- Завод автоматом признаёт себя КИИ или попадает в периметр требований.
- ИБ начинает требовать внедрения мер.
- Только потом кто-то задаёт неудобные вопросы:
- у нас вообще есть стенды для тестирования?
- есть ли компетенции сопровождать всё это на площадке 24/7?
- есть ли бюджет не только купить, но и жить с этим 10–15 лет?
- выдержит ли технологический процесс такие изменения?
- нужен ли конкретно этому заводу весь перечень мер?
- что с вендором, если его ПО 10 лет как снято с поддержки?
Решения принимаются сверху вниз, без анализа реальных ограничений площадки.
В итоге:
- ИБ требует: «обкатайте на стенде» — стенда нет и не предвидится;
- ИБ требует: «сегментируйте» — эксплуатация не умеет это сопровождать;
- ИБ требует: «обновляйте» — вендор давно не поддерживает эту версию ПО, а новый софт требует полной переделки.
И при этом ответственность за простой и убытки несут инженеры.
ИБ — это процесс, да.
Но этот процесс не должен превращаться в самоцель, когда ради «галочки» игнорируются:
- физика процесса;
- жизненный цикл оборудования;
- реальный профиль рисков.
Меры должны выбираться по риску и применимости к конкретной технологии, а не просто потому, что «так написано в документе».
- Алгоритм ПЛК и firewall: кто кому мешает
Да, неверный алгоритм действительно может нарушить ход процесса.
Но алгоритм — это часть технологического контура:
- им управляют инженеры;
- он прозрачен по логике;
- его можно отладить, откатить, задокументировать.
ИБ — это надстройка.
Она должна дополнять существующую систему, а не ухудшать её.
За годы и десятилетия инженеры выстраивали процессы аварийного ремонта так, чтобы:
- быстро получать доступ к контроллерам;
- оперативно диагностировать причину;
- использовать отлаженные инструменты;
- иметь предсказуемое сетевое поведение;
- минимизировать барьеры в аварийной ситуации.
Когда поверх этого ставят:
- firewall’ы;
- DPI;
- SSL-инспекцию;
- агрессивные политики;
- автоматические обновления,
которые:
- ломают видимость устройств;
- мешают загрузке или чтению логики;
- добавляют задержки;
- периодически отрывают PLC от SCADA,
то проблема уже не в «кривом алгоритме».
Проблема в том, что надстройка начинает ломать базовый слой.
Появляются новые точки отказа, которых раньше не существовало.
Технологический процесс остаётся прежним, а уровень риска увеличивается только потому, что в систему внесли дополнительную сложность.
Завод — не банк и не офис.
Его нельзя «выключить до завтра ради патча».
АСУ ТП должны работать всегда,
а ИБ должна встраиваться так, чтобы не превращать каждое обслуживание ПЛК в сапёрную операцию.
- Сегментация: идеальная сеть на бумаге vs скорость ремонта в жизни
Сегментация сама по себе — инструмент неплохой.
Но в АСУ ТП главный принцип другой:
Инженеру нужен быстрый, прямой и прозрачный доступ ко всему оборудованию.
Потому что:
- поломка не ждёт согласований;
- производство нельзя просто «поставить на паузу»;
- время реакции = деньги.
Как только между инженером и оборудованием появляется сетевой лабиринт из VLAN, ACL и маршрутов, доступ перестаёт быть прямым.
Это не история про «глупых инженеров, которые не знают VLAN».
Это история про приоритет:
- инженер должен чинить оборудование;
- не тратить время на диагностику сетевой топологии.
Любой сбой сегментации:
- делает причину поломки менее очевидной;
- заставляет идти ножками по шкафам и стойкам;
- замедляет восстановление;
- увеличивает простой.
То есть сегментация в реальности часто увеличивает время ремонта, а не уменьшает риск аварий.
На производстве важнее скорость восстановления, чем красота схемы сети в Visio.
ИБ должна это учитывать, а не ломать.
- 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 чинится часами или днями;
- и ломает он десятки устройств сразу.
Каждый вендор продаёт продукты ИБ,
но никто не гарантирует компенсацию простоя конкретного завода.
На реальном производстве есть один простой критерий:
Помогает ли это работать или мешает?
Если мешает — внедрено неправильно, кто бы ни выдал сертификат.
- Флешки и фильмы: симптом, а не причина
Разговоры про «оператора, который приносит кино на флешке» — это уход от сути.
Если оператору на смене нечем заняться — это уже проблема организации работы, а не ИБ.
Нормальное производство не должно превращаться в длинную ночную смену без задач.
Но флешка появляется не только из-за фильмов.
Она появляется там, где:
- интернет закрыт наглухо;
- перенос технических файлов запрещён;
- доступ к документации затруднён;
- легальных способов передать логи, отчёты, конфиги нет;
- смена долгая, а инструментов минимум.
В таких условиях люди неизбежно ищут обходные пути.
Флешка — это просто удобный носитель.
Если цель — убрать флешки, нужно:
- дать нормальный доступ к документации и знаниям;
- предусмотреть безопасный и удобный канал обмена файлами;
- прописать понятные правила.
В 2025 году фильм на телефон скачивается быстрее, чем ищется флешка.
Проблема не в носителе и не в «кино» как таковом.
Проблема в том, что когда ИБ вводит запреты без альтернатив, появляются обходы.
ИБ должна улучшать процессы, а не превращать сотрудников в изобретателей обходных схем.
- «Надо работать вместе» — но кто принесёт реальные решения?
Ещё одна популярная мысль:
«АСУ и ИБ должны работать вместе, обмениваться знаниями».
Звучит правильно.
Но на практике часто выглядит так:
- ИБ инициирует изменения;
- ИБ не даёт стендов и ресурсов;
- ИБ не приносит готовых регламентов и сценариев;
- ИБ не берёт на себя ответственность за простои;
- но ожидает, что эксплуатация сама всё «додумает и сделает».
Нормальная практика во всех областях:
- проектировщик закладывает ресурсы на ПНР;
- технолог закладывает режим отладки;
- метролог — эталоны и поверку;
Только ИБ часто считает, что её изменения должны происходить «сами собой»,
без тестовой инфраструктуры и дополнительных затрат.
Если ИБ требует:
- сегментацию;
- DPI, IDS/IPS;
- обновления ОС;
- Zero Trust;
- усложнение аутентификации,
ИБ и должна предоставить:
- проработанные сценарии внедрения;
- понятные схемы тестирования;
- заранее подготовленные варианты отката;
- согласованный регламент действий;
- прозрачное распределение ответственности;
- финансовое обеспечение необходимых работ и инфраструктуры.
Далее эти предложения обсуждаются со службой эксплуатации, чтобы выработать решение, которое будет технически реализуемым, безопасным для технологического процесса и приемлемым для обеих сторон.
И тогда «работать вместе» действительно получится.
Пока этого нет — это не взаимодействие, а сдвиг рисков с ИБ на эксплуатацию.
- Доступ в аварии и человеческий фактор
Сравнение «забыл пропуск — не зайдёшь на завод» хорошо выглядит на бумаге, но плохо — в цеху.
Пропуск — фильтр для входа на территорию. Его можно забыть где угодно:
в столовой, в раздевалке, в шкафчике.
Для технологического процесса всё гораздо жёстче.
Очень много аварийных ситуаций можно не доводить до ПАЗ, если оператор или инженер вовремя вмешается:
- остановит насос до опасного давления;
- снизит нагрузку;
- включит дополнительное охлаждение;
- выведет контур в ручной режим;
- изменит уставку в нужный момент.
Когда человек на месте видит проблему в реальном времени,
у него есть шанс предотвратить серьёзный ущерб.
Но если в этот момент:
- MFA не проходит;
- токен заблокирован;
- пароль истёк или три раза введён неверно;
- учётка заблокировалась «по требованиям ИБ»;
- это был сарказм про смс;)
человек превращается во вынужденного наблюдателя.
А авария развивается дальше.
В стрессовой ситуации даже нажать одну большую красную кнопку бывает тяжело.
А теперь представьте оператора, который под давлением времени и страха должен:
- вспомнить сложный пароль;
- не ошибиться три раза;
- ждать таймауты блокировок;
- искать администратора, который перегенерирует токен.
В результате:
- срабатывает ПАЗ;
- продукт улетает в брак;
- оборудованию нужна чистка;
- требуется повторный прогрев и вывод на режим;
- простой длится часы или сутки.
Там, где человек мог обойтись без потерь,
избыточная ИБ делает ПАЗ единственным сценарием.
ПАЗ — это страховка, а не нормальный режим.
ИБ, не учитывающая этот факт, искусственно ухудшает ситуацию.
- Зачем вообще всё это
Эта статья — не про «firewall плохой, давайте его выкинем».
Она про другое:
- ИБ в АСУ ТП должна быть реалистичной;
- меры должны быть применимы к конкретной технологии;
- и главное — они не должны ломать базовые процессы эксплуатации и ремонта.
АСУ ТП живёт в других временных масштабах:
- оборудование служит по 20–30 лет;
- ОС и ПО снимаются с поддержки задолго до физического износа;
- реинжиниринг стоит как новый цех;
- вендор может просто исчезнуть с рынка.
Перед предприятием в реальности часто стоит простой выбор:
- либо дорогой, долгий и рискованный реинжиниринг;
- либо осторожная, осознанная эксплуатация того, что уже стабильно работает.
Требования ИБ часто подразумевают первый вариант, не предлагая ресурсов и инструментов под него.
Поэтому главный тезис такой:
ИБ в АСУ ТП должна защищать производство, а не мешать ему работать.
Инженеры — не враги ИБ, а ключевые партнёры.
Но пока диалог строится в формате «мы решили — вы сделайте», заводы будут платить за это своими простоями.
Источник: https://habr.com/ru/articles/974084/
🔗 Теневая сторона ИБ в промышленности: расследование влияния на АСУ ТП