Безопасность АСУТП практика и примеры
Здесь не будет историй о проникновении кибер террористов на ядерные объекты и массовом применении кибер оружия для уничтожения инфраструктуры неприятеля. А будет несколько обыденных примеров из личной практики, по модному ныне тренду безопасности АСУТП на типичном среднем Российском производстве. Взяться за перо сподвигла следующая статья про безопасность промышленных систем от Позитива.
И последующий за ней гомерический хохот от специалистов АСУ ТП . asutpforum.ru/viewtopic.php?f=11&t=3239
В обсуждении статьи было несколько типичных таких примеров основных проблем: про массовое распространении систем Windows на серверах и АРМ-ах СКАД-а, про отсутствие даже антивирусов на них, про то, что против лома нет приема и спустившись на более низкий уровень контролеров и программируемых датчиков можно и не таких бед натворить. Ну и конечно про злых безопасников, которые только кровь пьют и бессмысленные бумажки сверху спускают :).
Красной линией проходит главная мысль правильного подхода к обеспечению безопасности АСУТП, не защита конфиденциальных данных, а обеспечение непрерывности производственного процесса. Мало кому интересен дамп показаний с датчиков температуры энергоблоков, а вот вывести эти датчики из строя и остановить производство, это более лакомая цель потенциального конкурента.
Направлений к построению политики безопасности может быть много. Я предпочитаю следующие акценты. Первой целью обеспечения информационной безопасности АСУТП является максимальный перевод всех рисков нападения из удалённой программно-сетевой плоскости, на план реального физического присутствия нападающего. Чтобы для потенциального нарушителя, не было разницы разбить молотком этот пресловутый датчик, или подойти к нему с ноутбуком и перепрограммировать его.
Второй целью обеспечения безопасности АСУТП плавно вытекающей из первой, это банальная защита от дурака :).
Далее приведу типичные проблемы, с которыми сталкивался в своей практике при анализе защищенности промышленных сетей.
1. Высокие риски вирусных заражений. Когда после анализа одной АСУТП-шной сетки вскрылась такая банальная ситуация, как отсутствие антивирусной защиты. Ответом на вопрос «Почему?» было дескать, «А зачем? Только компьютеры нагружает, все тормозит». Это благостное состояние продолжалось до появления в сети древнего сетевого p2p червяка, который банально положил все что мог своим бешеным трафиком, и производство перешло на ручной режим управления (благо такой режим был). При этом каждый час простоя мог вылиться в ощутимые денежные потери.
2. Отсутствие блокировки АРМ-ов на физическом уровне. Что такое АРМ, на типичном таком среднем Российском производстве? Это банальный такой персональный компьютер, на котором крутится винда и поверх рабочего стола растянута «картинка» SCADA. Комп при этом беззащитно стоит на столе оператора. На какие только ухищрения не идут операторы, чтобы не скучать в ночную смену. Попытки засунуть завирусованные флешки с игрушками в АРМ-ы, опробование различных комбинаций клавиш для сворачивания интерфейса SCADA (им бы терминалы оплаты ломать!). Операторы АРМ-ов это уже далеко не старички, а все больше и больше «продвинутая» молодежь. Спасает только железный ящик с замком. Почему именно полная блокировка посредством железного ящика? В памяти свежий пример, когда потыкавшись в залитые порты USB, находчивый оператор, просто открутил винтики системника и подключился к внутренним интерфейсам материнской платы. :)
3. Недостаточное разделение между сегментами производственных сетей. Очень часто видел, как в одной сети крутится и офисные задачи и технологические. Тут даже комментировать нечего.
4. Множественные точки входа в сеть АСУТП на программно-сетевом уровне. Это проблема вытекает из двух предыдущих и приводит как правило к вирусным заражениям, а в особо нехороших случая и к легкой реализации злого умысла. Слишком много точек подключения переносных устройств, слишком много точек соприкосновения между сетями. В идеале точка входа в сеть АСУТП, должна быть одна. Выделенная полностью контролируемая машина.
5. Отсутствие парольной политики. В отчете Позитивщиков говорилось о стандартных инженерных паролях. Это еще цветочки. Пароли зачастую просто не ставят — для удобства. Ни на интерфейсы контролеров и схемы SCADA, ни на административные учетные записи АРМ-ов и серверов.
6. Обновление программного обеспечения сети АСУТП Больной вопрос. Сколько раз у вас бывало, что падал сервер в результате криво вставшего обновления? Сколько времени уходило на устранение косяка? И если в случае какого-нибуть интернет-магазина, восстановление сервера после такого сбоя, означает сиюминутное восстановление продаж, то аварийная остановка центрального сервера АСУТП на полчаса, может привести к полному перезапуску производственной линейки, который может продолжатся не один час (новый разогрев котлов, сопутствующие подготовительные работы и тд). Это будут ощутимые денежные потери. Это-же ничем не будет отличатся от самой настоящей диверсии. :)
В результате, ни о каком автоматическом обновлении речи идти не может. Все обновления привязываются только к плановым остановкам производства на ремонт. При этом производится ручной анализ необходимых патчей и распространение их по сети АСУТП через единую точку входа.
Это по правильному, а по неправильному, «Работает и не трогаем, зачем еще что-то обновлять лишние проблемы наживать!» :)
Кстати говоря, в отчете Позитивщиков большой акцент сделан на удалённых атаках на промышленные системы, переполнение буфера и тд. Но это же цветочки по сравнению с дырами в системах windows, на которых крутятся все эти компоненты. Я как то на одном АРМ-е насчитал десяток критических уязвимость позволяющих захватить полный контроль над машиной.
7. Инженерно-техническая защита и охрана. Это уже несколько выходит из темы информационной безопасности, но так как основная идея это снижение всех рисков нападения по удалённой программно-сетевой плоскости, и их вывод на план реального физического присутствия, то несколько недорогих IP-камер на наиболее критичных узлах АСУТП весьма дисциплинирует от поспешных решений. :)
Теперь немного о другой стороне медали — инсайд и закладки.
Всегда существуют риски наличия недокументированных закладок в управляющих программах промышленных контролеров, чуть меньше, возможность инсайда и целенаправленной порчи управляющих программ обслуживающим персоналом. Риски сложно-закрываемые из-за больших затрат на реализацию защиты. Армию надзирателей и аудиторов кормить себе мало кто позволит (да да, за каждым инженером по надзирателю с плеткой и тотальный аудит кода). Однако весьма полезно собирать и анализировать статистику работы узлов АСУТП на предмет сбоев. Может так случится, что вылезут интересные закономерности. Которые затем вскроются интересными последствиями, а именно желанием подзаработать немного денег на «поддержке и восстановлении» недобросовестными вендорами.