Информационная безопасность промышленных контроллеров

Программируемый логический контроллер (ПЛК) (или PLC – Programmable Logic Controller) - устройство используемое для автоматизации технологических процессов. В отличии от встраиваемых систем и микроконтроллеров, ПЛК изготавливается как самостоятельное изделие, отдельно от управляемого при его помощи оборудования. В системах управления технологическими процессами ПЛК взаимодействуют с различными компонентами систем человекомашинного интерфейса (например операторскими панелями) или рабочими местами операторов на базе ПК. Датчики и исполнительные устройства подключаются непосредственно к самой ПЛК или к дополнительным модулям входов/выходов.

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

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

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

• системах диспетчерского управления и сбора данных (SCADA)
• элементах телеметрической подсистемы и телемеханики
• прикладных приложениях для анализа производственных и технологических данных
• системах управления производством

Существует несколько мифов об АСУ ТП.

Миф 1. ПО АСУ ТП обладает большей надежностью и меньшим количеством ошибок

На самом деле количество ошибок в ПО напрямую зависит лишь от его сложности. По некоторым данным, в 2008-2010 годах было обнаружено не менее 17 уязвимостей в ПО компонентов АСУ ТП. Цифра не очень большая, но сюда надо добавить сотни и тысячи уязвимостей, унаследованных от ИТ-технологий вместе с теми техническими решениями, которые используются на предприятиях. Хотя они и не являются направленными, тем не менее, представляют конкретную угрозу.

Миф 2. Сеть АСУ ТП полностью изолирована и состоит всего из нескольких компьютеров

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

Миф 3. Использование средств безопасности на периметре сегмента АСУ ТП достаточно

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

Миф 4. Исправления ПО, сделанные его производителем, помогут исправить уязвимость и остановить угрозу

Это утверждение верно лишь частично, так как практически всегда существует задержка между публичным анонсом об обнаружении уязвимости и появлением исправлений от производителя. Задержка может составлять от нескольких недель до года, как в случае с ПО для АСУ ТП, так и в отношении ИТ-продуктов. Это означает, что в течение всего этого времени АСУ ТП будет уязвимой! Примером может быть одна из уязвимостей в ОС Windows, используемая червем Stuxnet для эскалации привилегий, которая по прошествии нескольких месяцев по-прежнему остается неустраненной.

Промышленный вирус Stuxnet

Речь идет о чрезвычайно высокотехнологичном вредоносном ПО во всех его проявлениях. Данный червь использует четыре ранее неизвестные уязвимости системы Microsoft Windows, одна из которых направлена на распространение при помощи USB-flash накопителей. Причем данная уязвимость выявлена во всех версиях Windows, включая XP, CE, Vista, 7, Windows Server 2003, 2008 и 2008R2, как в 32 разрядных, так и в 64 разрядных. Уязвимость заключается в выполнении кода при попытке системы отобразить иконку c накопителя, например, при просмотре в проводнике. Исполнение кода происходит даже при полностью отключенном автозапуске для всех носителей. Кроме этого в коде зловреда реализована и возможность заражения по сети. Но, тем не менее, на большинство промышленных объектов червь попал именно через внешние носители.

Кроме распространения посредством внешних носителей червь также успешно заражает компьютеры посредством соединения через локальную сеть. То есть оказавшись на компьютере вне промышленной сети, он анализирует все активные сетевые соединения и «пробивается» к промышленной сети всеми возможными способами. После внедрения в систему вредоносное ПО ищет в ней присутствие SCADA-системы фирмы Siemens. Причем им атакуются только системы SCADA WinCC/PCS7. Данных о заражении другой SCADA-системы от Siemens – Desigo Insight, которая широко используется для автоматизации зданий и жилых комплексов, аэропортов и т.д., у нас нет. Это говорит о «заточенности» червя на крупные промышленные и стратегические объекты.

Когда червь «понимает», что оказался на машине с WinCC, он заходит в систему, используя стандартные учётные записи. Стоит заметить, что официальный Siemens не рекомендует менять стандартные пароли на своих системах, так как «это может повлиять на работоспособность системы», и использование червем стандартных паролей гарантирует почти 100% успешной авторизации. Итак, вирус соединяется с WinCC и таким образом получает доступ к технологическому процессу. Но и это еще не все… Он «осматривается» в локальной сети АРМа. Найдя в ней другие АРМы, червь заражает и их, используя 0day уязвимости в службе печати Windows. Также червь видит в сети и контроллеры. Тут мы дошли, пожалуй, до самого главного и опасного его функционала: да, Stuxnet умеет перепрограммировать PLC, естественно не все, а только Simatic фирмы Siemens. И это не так мало, если учесть, что на этих контроллерах построен технологический процесс на огромном количестве объектов, в том числе стратегических и военных.

Например, атомная станция в Иране (Бушер), которую многие эксперты считают «целью» этого кибероружия, конечно, не использует контроллеры Siemens для управления самим реактором, но использует их в большом количестве для управления вспомогательным оборудованием. А этого вполне достаточно чтобы червь мог парализовать работу атомной станции. Причем сам процесс «парализации» проходит очень интересно. Троян не записывает в контроллеры мусор и не выводит их из строя. «Живя» в системе достаточно долгое время, он накапливает информацию о технологическом процессе, о режимах работы оборудования. Пример: допустим, аварийная уставка по температуре охлаждающей жидкости в установке равна 75°С. Нормальная температура работы – 40-45°С. Изменение значения аварийной остановки в контроллере с 75 до 40’ приведёт к тому, что контроллер будет инициировать остановку агрегата по аварии в тот момент, когда он достигает своей нормальной рабочей температуры. Или ещё хуже – уставка меняется в другую сторону, и агрегат продолжает работать после перегрева до полного самоуничтожения. При этом на экране SCADA-системы оператор продолжает видеть нормальные значения и уставки, которые троян подменяет в реальном времени. И если это, например, установка, перекачивающая газ, управляемая САУ турбоагрегатами «последнего» поколения, то изменение уставок может привести к исчезновению с карты всей компрессорной станции вместе с прилегающими к ней районами.

Типичные угрозы

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

1) Исполнительные устройства и подсистема телеметрирования

Очень часто электронная компонентная база используемых устройств не позволяет внедрить туда столь популярные технологии как IPSec, SSL, организовать VPN. Тем не менее, доступ к этим устройствам нужен всегда. Более того, некоторые из этих устройств выступают в качестве устройств сбора информации (телеметрии) о показателях выполнения технологического процесса с датчиков и так далее. В них же могут накапливаться сообщения о тревогах и авариях, что весьма критично. В этой связи очень важно назначать им публично доступный IP-адрес, что, к сожалению, встречается сплошь и рядом. В некоторых ситуациях избежать этого невозможно при допущениях ошибок проектировки сети.

Например, современные промышленные контроллеры могут быть соединены напрямую или через модем. При подключении через модем их часто объединяют с GPRS/GSM-модемами, что по умолчанию наделяет устройство IP-адресом мобильного оператора. При такой конфигурации они очень уязвимы для атак извне. Специализированными утилитами и методами злоумышленник может выявить подобные устройства. Сами исполнительные устройства, как правило, подключаются по последовательному интерфейсу (RS-232 / RS-485) к MODBUS-серверу, а непосредственно MODBUS-сервер имеет управление по TCP/IP через канал Ethernet / Industrial Ethernet с операторами.

2) Парк операторов

Первая проблема – операторы находятся в самом сложном положении, потому что вопросы режима среди них зачастую не соблюдаются. Вторая проблема – к ним часто допускают иностранных специалистов, которые могут иметь не совсем благие намерения. Как показала практика внедрения червя Stuxnet на атомной станции в Бушере (Иран), инженером инсайдером обслуживающего подразделения была внедрена вредоносная программа с USB-носителя.

Операторы имеют возможность подключаться к системе SCADA, как правило, с разным уровнем привилегий, планировать и внедрять новые проекты, изменять существующие. Несмотря на множество уязвимостей в ПО систем диспетчеризации, основной угрозой по-прежнему остается инсайд.

3) Корпоративная зона (зона BAN – Business Area Network)

В корпоративной зоне находятся люди, которые, как правило, являются организацией-владельцем всего того, о чем мы говорили. В секторе энергетических или нефтетранспортирующих организаций это особенно очевидно – все их хозяйство может находится на самых различных континентах. BAN непосредственно озабочена извлечением прибыли, почему большую часть времени они посвящают изучению финансово-экономических вопросов своего бизнеса.

Отдельной угрозой, частично использующей штатные методы для исполнения, является распространение злонамеренного кода для кражи критически важных данных о проектах технологических процессов и нарушения их корректной работы, подтверждение чему является факт распространения вредоносного кода «Rootkit.TmpHider» и «Scope.Rookit.TmpHider.2». Многие популярные системы диспетчеризации (SCADA) базируются на платформе ОС Microsoft Windows, поэтому данный факт указывает на необходимость обеспечения информационной безопасности операционной системы, на которую устанавливается прикладное программное обеспечение.

Существующие уязвимости

1) Переполнение буфера в RealWin

RealWin - SCADA-сервер приложение специально разработанное компанией RealFlex Tecnologies Ltd для средних и малых проектов, предназначенных для контроля и мониторинга объектов в реальном времени. RealWin приложение работает как служба HMI (Human Machine Interface – человекомашинный интерфейс) на порту 912 TCP протокола. Эта служба уязвима к двум видам переполнения буфера.

Воздействие:
Злоумышленник может вызвать отказ в обслуживании или теоретически выполнить произвольный код с привилегиями сервисной учетной записи на целевой машине. Если сервисная учетная запись имеет административные привилегии, злоумышленник может захватить полный контроль над уязвимой системой.

2) Переполнение буфера в InduSoft NTWebServer

InduSoft Web Studio это мощный пакет программного обеспечения для разработки HMI, SCADA-систем, основанная на WEB-технологии и имеющая встроенную поддержку многих популярных контроллеров от разных производителей. InduSoft NTWebServer использует тестовую веб службу на порту 80 TCP протокола. Данная служба NTWebServer-а подвержена уязвимости переполнения буфера, что вызывает повреждение памяти.

Воздействие:
Злоумышленник может привести службу к сбою и получить возможность выполнить произвольный код.

3) Уязвимость в Invensys Wonderware InBatch

Wonderware InBatch - программный пакет, предназначенный для автоматизации процессов дозирования и смешивания. InBatch использует службу «менеджер блокировок базы данных» (lm_tcp), которая прослушивает порт 9001 (вручную или автоматически во время запуска среды). Foxboro I/A Series так же включает в себя приложение, использующее данную службу. Служба lm_tcp обоих продуктов уязвима к переполнению буфера.

Воздействие:
Злоумышленник может привести к сбою устройства и получить возможность выполнить произвольный код.

4) Переполнение буфера в элементе ActiveX в Open Automation Software.

Open Automation Software – пакет различных продуктов начиная от управления SCADA и HMI, заканчивая решениями для бизнеса. Уязвимость позволяет привести систему к сбою и выполнить произвольный код. Эксплоит находится в свободном доступе.

5) Уязвимости в WAGO 750-841 and 758-874

WAGO IO SYSTEM – одна из важнейших модульных систем для промышленности, производства и автоматизации. Имеют множество уязвимостей.

• Можно сменить пароль, заставив администратора перейти по вредоносной ссылке. Ссылка для смены пароля включает в себя три параметра, которые позволяют при переходе изменить пароль администратора.
• Некоторую информацию можно просмотреть через веб-интерфейс программируемого контроллера без авторизации.
• Через веб-интерфейс программируемого контроллера можно скачать прошивку без авторизации. Возможно скачать прошивку используя HTTP запрос.
• Используются пароли по умолчанию.

Обеспечение безопасности

Какой инструментарий потребуется для анализа безопасности АСУ ТП, учитывая, что дело придется иметь с системами управления и диспетчеризации технологическими процессами? Здесь придется работать на стыке известных технологий и отдельных специальных решений, потому что большая часть известных АСУ ТП и систем SCADA развертывается на традиционных платформах (Windows, Linux).

На сегодняшний день известно не так много узкоспециализированных программных средств анализа защищенности АСУ ТП / SCADA:

• ПК «SCADA-Аудитор» (отечественный сканер анализа защищенности технологических сетей, АСУ ТП / SCADA);
• Teenable Nessus (содержит несколько модулей проверок систем SCADA и ряда программируемых логических контроллеров в коммерческой версии);
• Rapid7 Metasploit Project (фреймворк для общей оценки безопасности системы). Естественно, помимо специализированного софта, в ход идет и традиционный инструментарий, — например, сетевые сканеры.

Рассмотрим несколько способов для обеспечения безопасности промышленной сети:

1) Анализ рисков

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

В процессе анализа рисков, специалистом выявляются «узкие» места в архитектуре АСУ ТП, определяются угрозы и уязвимости АСУ ТП и оценивается текущий уровень защищенности активов.

Степень сложности анализа рисков определяется организацией. Это может быть как экспертный, так и качественный или количественный анализ.

2) Убрать все лишнее

Ненужные сервисы — это возможные уязвимости. На данном шаге мы, по возможности, убираем следующее:

• лишние подключения к промышленной сети;
• неиспользуемые сервисы (сетевые протоколы, неиспользуемые возможности программных продуктов и т.д.)
• излишние права пользователей, например права администратора. Если есть возможность, то желательно использовать бездисковые рабочие станции и удаленный доступ.

Необходимо оставить только то, что необходимо для функционирования АСУ ТП.

3) Настроить средства защиты

Внедрить технические и физические меры защиты. На данном шаге мы защищаем все что осталось, а именно:

• Определяем политику безопасности АСУ ТП;
• Настраиваем имеющиеся средства защиты, согласно требованиям по безопасности;

При необходимости, внедряем новые защитные меры (Система контроля и управления доступом, видеонаблюдение, антивирусные средства, межсетевой экран и т.д.).

4) Внедрить процессы обеспечения информационной безопасностью

Внедрить следующие процессы обеспечения информационной безопасности:

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

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

- Обслуживание технических средств
Все оборудование АСУ ТП должно проходить техническое обслуживание. Должны быть установлены нормативы замены устаревшего оборудования. Например, согласно паспорту устройства, после 5 лет эксплуатации датчика вероятность его выхода из строя, может составлять 35%. Довольно часто такая вероятность считается недопустимой для определенный процессов.

- Управление инцидентами информационной безопасности
Данная процедура должны быть установлена для эффективного реагирования на любые атаки, а также для последующего анализа причин их возникновения и последующего анализа динамики инцидентов.

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

5) Обучить пользователей

Все предыдущее теряет смысл без участия пользователей. Люди могут быть слабой точкой в хорошо защищенной сети. Необходимо проведение тренингов и курсов повышения осведомленности, для того чтобы персонал оставался бдительным в ситуациях касающихся информационной безопасности.

Наиболее интересные инциденты

Русская компания НТЦ «Станкоинформзащита», занимающаяся безопасностью АСУ ТП, опубликовала аналитический отчет с анализом инцидентов информационной безопасности АСУ ТП зарубежных государств за 2008-2010 годы. Наиболее интересные из них:

7 марта 2008 года, Блок 2 ядерной станции «Hatch» (штат Джорджиа, США), внештатное аварийное выключение на 48 часов после установки обновления программного обеспечения (похожий инцидент случился в 2006 году на ядерной станции «Browns Ferry» из-за нештатного сбоя программируемого логического контроллера при получении аномального выходного сетевого трафика из производственной сети);

Май 2008 года, Корпорация Tennessee Valley Authority (TVA) (в ведомости данной энергетической корпорации находятся 11 угольных станций, 8 ТЭС, 3 ядерных станции, 29 ГЭС США), проверка регуляторов (GAO, HHS) выявила порядка 2000 уязвимостей разной степени критичности. Среди брешей в безопасности были выявлены сегменты производственной сети, подключенные к интернету, множественные уязвимости прикладного ПО, отсутствие обновлений безопасности, ошибки в проектировании архитектуры сети и каналов обмена данными.

Вывод

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

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

Список использованной литературы

1. “Безопасность SCADA: Stuxnet – что это такое и как с ним бороться?” (Павел Волобуев, 2010 год, Digital Security)
2. “Особенности обеспечения информационной безопасности систем SCADA” (Гарбук С.В., Комаров А.А., РусКрипто'2010).
3. “Насколько «дыра» широка?” (С.Гордейчик, Positive Technologies, «Открытые системы», 2006 год);
4. Материалы SANS Process Control; SCADA Security Summit 2010;
5. “SCADA под прицелом: Анализ защищенности АСУ ТП” (Юрий Каминков, НТЦ «Станкоинформзащита»)
6. Международный стандарт МЭК 61131 о языках программирования для ПЛК Уязвимости SCADA и PLC в исправительных учреждениях (Teague Newman, Tiffany Rad, John Strauchs)