К вопросу об избыточности мер ИБ в АСУ ТП

Дисклеймер — это ответ к статье https://habr.com/ru/articles/890612/ который не влез в комментарий.

Если коротко — в статье мнение об ИБ из разряда «не читал но осуждаю» с крайне спорным мнением по каждому пункту

Преамбула

Я не специалист в области эксплуатации наложенных средств защиты АСУ ТП но достаточно поездил с обследованиями именно сегментов АСУ ТП и последующей защитой оных. С начала СВО по совершенно непонятной причине возник лавинообразный рост атак (только за 22-23 киберинцидентов в АСУ ТП выросло на 160%) на промышленные объекты РФ и вопрос мер ИБ строго говоря возникать не должен в принципе. У ИБ есть некоторые идейные противоречия с историческими базовыми принципами построения АСУ (доступность превыше всего) но это понемногу преодолевается, в том числе на примерах как не надо делать. Статья выше — это прямо квинтэссенция как делать не надо.

Фабула

1. Ограничения доступа: Бюрократия вместо оперативности

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

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

Во-вторых было бы правильно показать где именно Современные стандарты ИБ требуют именно многоуровневых согласований — ни в 187 ФЗ, ни в 239 приказе ФСТЭК я этого не вижу. Ну так может не сваливать проблему на злобных ИБ а разобраться с организационной проблемой в своей собственной оргструктуре?

2. Запрет Wi-Fi: Удобство vs. Мнимые угрозы

• Для взлома Wi-Fi злоумышленник должен находиться в зоне действия сети, что невозможно на охраняемом объекте.

  Очень наивное предположение. Существуют направленные антенны которые прекрасно действуют в радиусе 15-20 км (если забраться повыше), и если в каком-нибудь Норильске разглядеть антенну направленную в сторону цеха еще можно то обычно с этим большие проблемы. Это далеко не главная проблема беспроводных технологий в АСУ ТП но какой аргумент такой и ответ.

• Даже при успешном перехвате данных программы ПЛК без комментариев и электрических схем бесполезны.

  Если ваша задача поправить за криворукими КПиА — то да. А если задача нарушить ТП — то ничего из этого не требуется. Я просто гарантирую если начать менять все значения уставок на случайные завод встанет куда быстрее чем закончатся уставки.

  Отдельное фи за такой аргумент.

  На алюминиевом заводе в России отсутствие Wi-Fi помешало операторам удалённо контролировать температуру плавильных печей. Перегрев одной из печей вызвал повреждение футеровки ($800 тыс. на ремонт).

  Вот прямо точно что там проблема была из-за того что злые ИБ пришли и выключили рубильник Wi-Fi а АСУ плакали и на коленях умоляли не выключать? Не в том что архитектура просто пролюбила установить туда датчики? Поговаривают что утраченные технологии Древних позволяют удаленно контролировать температуру дешевле, проще и надежнее по проводам, не то что по откровенно плохо работающий в заводских условиях технологии. Сложная помеховая обстановка, CSMA/CA с гигантскими проблемами в условиях большого числа клиентов с регулярным опросом и малыми передаваемыми данными, огромное энергопотребление и дикий оверхед… В конце концов беспроводные технологии не беспроводные, это автора кто-то обманул и прокладывать для них провода нужно. Не понимаю почему прокладывать кабель питания это модно и молодежно а коммуникационный кабель нет. Ну а контроль с датчиков с батарейками это исключительно мат в сторону предложившего.

Удалённый доступ: Запрет, который стоит миллионов

Проблема: Полный запрет удалённого подключения для подрядчиков и вендоров приводит к:

Задержкам в устранении неисправностей.

Невозможности оперативного обучения новых сотрудников.

А при чем тут ИБ? Вот выдержка из 239 приказа

22.2. Меры по обеспечению защиты значимых объектов от атак, направленных на отказ в обслуживании, должны приниматься в отношении значимых объектов, имеющих интерфейсы и сервисы, к которым должен быть обеспечен постоянный доступ из информационно-телекоммуникационной сети "Интернет" (далее – сеть "Интернет"), и должны предусматривать:

Как такового запрета нет в руководящих документах, и полный запрет это не требование ИБ а решение РУКОВОДСТВА ОБЪЕКТА. Если же внезапно отдел АСУ озаботится удобством подрядчиков и убедит руководство то внезапно и меры защиты вроде СКДПУ находятся и внедряются все той же ИБ. У меня кстати был опыт когда ИБшники просили поддержать внедрение системы контроля внешнего доступа но начальник АСУ до смерти боялся руководства завода и не хотел противоречить, а уж тем более требовать удорожания сметы.

Учётные записи операторов: Пароли как угроза

Проблема: Жёсткие требования к аутентификации (смена пароля каждые 30 дней, блокировка после 3 ошибок) создают риски:

Блокировка доступа в аварийной ситуации. На металлургическом комбинате оператор не смог остановить перегрев печи из-за просроченного пароля. Результат — повреждение футеровки и простой на 48 часов ($4.5 млн убытка).

И снова не стоит путать ИБ с человеческим фактором. У меня есть подозрение что оператор знает что у его пароля есть срок истечения и из-за этого он не сможет работать. Это проблема исключительно оператора что у него хватает компетентности. Точно так же если оператор ткнет не в ту кнопку несмотря на три предупреждения то виноват будет оператор а не производитель HMI. Ну и возвращаясь к пп.1 — точно-точно стоит пускать всех подряд к управлению системами которые стоят многие миллионы? Не бывает скажем обидевшегося рабочего который хочет отомстить кому-то?

Передача смены = риск простоя. При смене оператора система требует перелогинивания. В эти минуты оборудование остаётся без контроля.

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

Физические системы безопасности: Непреодолимый барьер

Реле безопасности. Электромеханические устройства, разрывающие цепь при превышении параметров (давление, температура). Их нельзя взломать — только физически отключить.

Не понимаю в чем тут избыточность ИБ. Но я прекрасно помню прекрасную модель насоса (тут кстати без шуток, действительно технически очень классная вещь) которая поддавалась DoS, причем так крепко что управление отказывал до перезагрузки управления по питанию. На нескольких АЭС США они стояли в первом и втором контуре охлаждения водно-водяных реакторов и патч для исправления из-за сертификации готовили емнип полгода. Да, АЗ бы сработала и не допустила расплава активной зоны, но есть маленький нюанс — простой АЭС это просто дикие деньги. То есть еще раз — защита от аварии на физических принципах это НЕОБХОДИМО но НЕДОСТАТОЧНО для нормальной работы объекта.

Финансовые последствия: Скрытые издержки ИБ

• Простои из-за конфликтов ПО. После обновления ПО SCADA на бумажном комбинате система перестала распознавать датчики влажности. Простой — 24 часа ($1.2 млн).

• Снижение гибкости. Запрет на IoT-датчики и цифровые двойники замедляет внедрение инноваций.

• Упущенная маржинальность. Из-за задержек предприятие теряет клиентов, переходящих к конкурентам.

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

Новые проблемы: Что ещё губят избыточные меры ИБ

1. Конфликты между отделами ИБ и инженерами:

• ИБ-специалисты без технического бэкграунда навязывают нереалистичные требования (например, обязательное шифрование данных с датчиков температуры).

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

  Ударим саботажем по тому что сами назначили некомпетентностью. Класс. Маловато контекста, но я могу придумать массу интересных сценариев которые начинаются с «просто чтения из шины». Но звучит так что ИБ сами поставили и обеспечили работу наложенного шифрования на канал связи а АСУ его отключают. Ну и чует мое сердце что в канале связи не только датчики температуры есть. А уж чтобы заспуфить адрес конкретного датчика с температурой выше уставки скажем аварийного сброса хлора — невозможно такое представить…

2. Сложности с обновлением ПО:

• Патчи для ПЛК должны проходить многоступенчатое тестирование, что занимает недели.

• На атомной станции в Канаде обновление ПО заняло 6 месяцев из-за требований ИБ. За это время обнаружились 3 уязвимости.

  Прямо пять с плюсом, давайте лепить на АЭС обновления без тестирования, что же может случится. Остаток комментария исключительно матом с междометиями.

3. Угрозы для инноваций:

• Запрет на облачные технологии и AI-аналитику данных из-за «рисков утечек».

  Облачные технологии и ИИ это не «риски утечек». Это буквально постоянная утечка данных просто из-за принципа работы этих технологий. В MITRE ATT&CK первый этап не просто так называется Reconnaissance.

• Предприятия отстают от конкурентов, внедряющих Industry 4.0.

  Как бы Industry 4.0 без средств ИБ не существует.

Рекомендации: Как внедрять ИБ без вреда

• Сегментация сетей. Отделите ПЛК и датчики от офисных сетей. Используйте фаерволы только для критических узлов.

  Air gap уже давно не работает. Stuxnet тому пример, и кстати как раз был создан для одного промышленного объекта. Не говоря уж о чистом фаерволле, это уже очень давно не сама по себе не защита.

• Белые списки для Wi-Fi. Разрешите подключение только доверенных устройств с предустановленным ПО.

  Да, конечно это обеспечит абсолютную защиту без средств ИБ обеспечивающих подключение только доверенных устройств с другим средством ИБ которое обеспечивает контроль целостности этого ПО. Миг-миг. И ни один злоумышленник в мире никогда не устаивался на работу чтобы получить это легитимное устройство…

• Гибкий удалённый доступ. Используйте облачные платформы с изолированными средами для вендоров.

  Это точно рекомендация по внедрению ИБ или хотелка АСУшника?

• Аварийные учётные записи. Храните пароли в опечатанных конвертах на пульте управления.

  Так пароли же угроза, забыли? И не один злоумышленник никогда не попадет и ничего не может прочитать? Ах да, печать же… Снова много мата.

• Совместное обучение. Инженеры и ИБ-специалисты должны понимать специфику друг друга.

  Единственный здравое указание за всю статью. Правда с учетом статьи похоже что ее надо читать как «ИБ нужно заткнуться и делать как я сказал».