Безопасность АСУТП практика и примеры

Здесь не будет историй о проникновении кибер террористов на ядерные объекты и массовом применении кибер оружия для уничтожения инфраструктуры неприятеля. А будет несколько обыденных примеров из личной практики, по модному ныне тренду безопасности АСУТП на типичном среднем Российском производстве.

Взяться за перо сподвигла следующая статья про безопасность промышленных систем от Позитива.

www.ptsecurity.ru/download/SCADA_analytics_russian.pdf

И последующий за ней гомерический хохот от специалистов АСУ ТП
.
asutpforum.ru/viewtopic.php?f=11&t=3239

В обсуждении статьи было несколько типичных таких примеров основных проблем: про массовое распространении систем Windows на серверах и АРМ-ах СКАД-а, про отсутствие даже антивирусов на них, про то, что против лома нет приема и спустившись на более низкий уровень контролеров и программируемых датчиков можно и не таких бед натворить. Ну и конечно про злых безопасников, которые только кровь пьют и бессмысленные бумажки сверху спускают :).

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

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

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

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

1. Высокие риски вирусных заражений.

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

2. Отсутствие блокировки АРМ-ов на физическом уровне.

Что такое АРМ, на типичном таком среднем Российском производстве? Это банальный такой персональный компьютер, на котором крутится винда и поверх рабочего стола растянута «картинка» SCADA. Комп при этом беззащитно стоит на столе оператора.
На какие только ухищрения не идут операторы, чтобы не скучать в ночную смену. Попытки засунуть завирусованные флешки с игрушками в АРМ-ы, опробование различных комбинаций клавиш для сворачивания интерфейса SCADA (им бы терминалы оплаты ломать!). Операторы АРМ-ов это уже далеко не старички, а все больше и больше «продвинутая» молодежь.
Спасает только железный ящик с замком. Почему именно полная блокировка посредством железного ящика? В памяти свежий пример, когда потыкавшись в залитые порты USB, находчивый оператор, просто открутил винтики системника и подключился к внутренним интерфейсам материнской платы. 🙂

3. Недостаточное разделение между сегментами производственных сетей.
Очень часто видел, как в одной сети крутится и офисные задачи и технологические. Тут даже комментировать нечего.

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

5. Отсутствие парольной политики.
В отчете Позитивщиков говорилось о стандартных инженерных паролях. Это еще цветочки. Пароли зачастую просто не ставят — для удобства. Ни на интерфейсы контролеров и схемы SCADA, ни на административные учетные записи АРМ-ов и серверов.

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

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

Это по правильному, а по неправильному, «Работает и не трогаем, зачем еще что-то обновлять лишние проблемы наживать!» 🙂

Кстати говоря, в отчете Позитивщиков большой акцент сделан на удалённых атаках на промышленные системы, переполнение буфера и тд. Но это же цветочки по сравнению с дырами в системах windows, на которых крутятся все эти компоненты. Я как то на одном АРМ-е насчитал десяток критических уязвимость позволяющих захватить полный контроль над машиной.

7. Инженерно-техническая защита и охрана.
Это уже несколько выходит из темы информационной безопасности, но так как основная идея это снижение всех рисков нападения по удалённой программно-сетевой плоскости, и их вывод на план реального физического присутствия, то несколько недорогих IP-камер на наиболее критичных узлах АСУТП весьма дисциплинирует от поспешных решений. 🙂

Теперь немного о другой стороне медали — инсайд и закладки.

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

Не могу не привести пример статьи, когда через закрытую микропрограмму контролера производство хотели поставить «на бабки».
Хитрая подпрограмма отсчитывала временной интервал и стопорила станочек.
plc4good.org.ua/view_post.php?id=107
копия
www.sendspace.com/file/h4681k

Цитата

Присутствует код таймера на 360 рабочих смен по 8 часов. Таймер считает только тогда, когда включен какой-то выход, типа включения гидронасоса усилителя давления, то есть когда станок работает. Когда таймер досчитывает до конца, устанавливается флаг с адресом M13.0 :), типа, все ребята, платите денежки! Что это, как не вымогательство!

Судя по комментариям, случаи далеко не единичны.