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

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

Одним из широко используемых стандартов является спецификация OPC, которая была разработана международной некоммерческой организацией OPC Foundation, созданной в 1994 году производителями различных средств промышленной автоматизации. Целью создания этой системы была унификация интерфейсов для управления устройствами.

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

Описание стандарта OPC

OPC (аббр. от англ. Open Platform Communications, ранее англ. OLE for Process Control) – это набор программных технологий, которые предоставляют единый интерфейс для управления различными устройствами и обмена данными. Целью создания OPC было предоставить инженерам универсальный интерфейс для управления различными устройствами. [1]

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

• OPC DA (Data Access) — наиболее распространённый стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.

• OPC HDA (Historical Data Access) — предоставляет доступ к уже сохраненным данным и истории.

• OPC AE (Alarms & Events) — предоставляет функции уведомления по требованию о различных событиях: аварийных ситуациях, действиях оператора, информационных сообщениях и др.

• OPC Batch — предоставляет функции шагового и рецептурного управления технологическим процессом.

• OPC DX (Data eXchange) — предоставляет функции организации обмена данными между OPC-серверами через сеть Ethernet. Основное назначение — создание шлюзов для обмена данными между устройствами и программами разных производителей.

• OPC Security — определяет функции организации прав доступа клиентов к данным OPC-сервера.

• OPC XML-DA (XML-Data Access) — предоставляет гибкий, управляемый правилами формат обмена данными через XML, SOAP и HTTP.

• OPC Complex Data — предоставляет дополнительные спецификации к OPC DA и XML-DA, которые позволяют серверам работать со сложными типами данных, такими как бинарные структуры и XML-документы.

• OPC Commands — набор программных интерфейсов, который позволяет ОРС клиентам и серверам идентифицировать, посылать и контролировать команды, исполняемые в контроллере или модуле ввода-вывода.

• OPC UA (Unified Architecture) — последняя по времени выпуска спецификация, которая основана не на технологии Microsoft COM, что обеспечивает кроссплатформенную совместимость. [2]

Таким образом, стандарт состоит из нескольких частей, самой распространенной является OPC DA. ОРС DA (OPC Data Access) – спецификация для обмена данными между клиентом (например, SCADA) и аппаратурой (контроллерами, модулями ввода-ввода и др.) в реальном времени.

Четыре стандартных режима чтения данных из ОРС сервера:

• Синхронный режим: клиент посылает запрос серверу и ждет от него ответ.

• Асинхронный режим: клиент отправляет запрос и сразу же переходит к выполнению других задач. Сервер после выполнения функции запроса посылает клиенту уведомление и тот забирает предоставленные данные.

• Режим подписки: клиент сообщает серверу список тегов, значения которых сервер должен отправлять клиенту только в случае их изменения. Для того, чтобы шум данных не был принят за их изменение, вводится понятие "мертвой зоны", которая слегка превышает максимально возможный размах помехи.

• Режим обновления данных: клиент вызывает одновременное чтение всех активных тегов. Активными называются все теги, кроме обозначенных как "пассивные". Такое деление тегов уменьшает загрузку процессора обновлением данных, принимаемых из физического устройства.

Формат данных OPC DA

OPC DA сервер обеспечивает обмен данными (запись и чтение) между клиентской программой (обычно SCADA системой) и конечными устройствами.

Сервер OPC DA может предоставлять доступ к текущим значениям регистров ПЛК, точкам данных DCS (Distributed Control System), показаниям из различных источников ввода-вывода или других программных приложений. OPC DA обеспечивает доступ к самому актуальному значению для данной точки данных.

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

Каждый элемент данных называется точкой и имеет три атрибута:

• Значение – фактические данные, которые читаются или записываются.

• Качество – определяет, насколько достоверны данные (хорошие, плохие, неопределенные), и более подробную информацию о состоянии данных, например, на основе ссылки на устройство ввода-вывода.

• Метки времени – в некоторых случаях протокол устройства может предоставлять этот атрибут для каждого значения. В противном случае сервер OPC назначит значение времени на основе своих внутренних часов. [3]

Иные атрибуты точки могут быть рекомендуемыми и пользовательскими.

Дополнительно могут быть указаны необязательные свойства: диапазон изменения значения, единица измерения и другие пользовательские параметры. [4]

Пример коммуникации на основе OPC DA

Начальное соединение OPC DA создается над соединением DCERPC — системой процедур удаленного вызова, используемой в распределенных вычислительных средах, с функциональностью OPC. Соединение начинается, когда клиент инициирует соединение DCOM, затем стороны синхронизируют сопоставленные интерфейсы, что означает, что каждый интерфейс получает уникальный идентификатор. И, наконец, клиент может использовать функции, предоставляемые интерфейсами OPC, например, добавить группу или элемент. [5]

На рисунке 1 показана базовая инициализация соединения DCERPC.

После установления связи TCP-клиент связывается с интерфейсом IOXIDResolver и вызывает метод ServerAlive2. Сервер отвечает ответом ServerAlive2, который содержит строку и атрибуты безопасности (например, разные IP-адреса сервера), клиент выбирает лучшие настройки, совместимые как с клиентом, так и с сервером. Наконец, вызывается RemoteCreateInstance, и соединение переходит на новый порт для дальнейших коммуникаций OPC. Следует отметить, что данный порт не фиксирован, все firewall без DPI не смогут фильтровать данный трафик.

Протокол OPC, как и все протоколы на основе COM, имеет встроенные интерфейсы, описывающие функциональные возможности OPC, которые можно вызывать удаленно. После того, как начальное соединение установлено, клиент сопоставляет эти интерфейсы, которые идентифицируются их UUID, с идентификатором контекста с помощью метода Bind или AlterContext (пример показан на рисунке 2). После того, как сопоставление выполнено, идентификатор контекста используется в качестве идентификатора интерфейса. Это означает, что для того, чтобы знать, какой интерфейс вызывается, необходимо также иметь последовательность пакетов AlterContext, которая сопоставляет UUID с интерфейсом.

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

Элементы – это некоторые данные, которые они представляют. Например, элемент может представлять текущую температуру, полученную от датчика температуры. Клиент может взаимодействовать с элементами, используя дескрипторы элементов, которые представляют соединение с источником данных на сервере и имеют связанные с ними атрибуты Value, Quality и Time Stamp. Дескрипторы элементов получаются путем вызова метода AddItem. Клиент сначала просматривает элементы сервера с помощью метода Browse и получает идентификатор элемента, связанный с каждым элементом. Клиент отправляет команду AddItem вместе с идентификатором запрошенного элемента, и, наконец, сервер возвращает дескриптор этого элемента.

Аспекты безопасности OPC DA

OPC-сервер может реализовывать один из трех уровней безопасности:

• Безопасность отключена – отсутствуют средства обеспечения безопасности. Разрешения на запуск и доступ к OPC-серверу предоставляются всем, права доступа для клиентов установлены для всех. Сервер OPC не контролирует доступ к объектам безопасности.

• Безопасность DCOM – применяется только безопасность NT DCOM. Разрешения на запуск и доступ к OPC-серверу ограничены для выбранных клиентов, как и разрешения на доступ для клиентских приложений. Однако сервер OPC не контролирует доступ к объектам безопасности. Это уровень безопасности по умолчанию обеспечиваемый DCOM.

• Безопасность OPC – сервер OPC также используется для управления доступом к объектам безопасности. Сервер OPC может реализовать безопасность OPC в дополнение к безопасности DCOM или реализовать только безопасность OPC. [6]

Классические спецификации OPC опираются на модель безопасности DCOM, в которой безопасность обеспечивается базовыми механизмами защиты ОС Windows. Брандмауэр Windows закрывает порты DCOM, ограничения DCOM и списки контроля доступа (безопасность компонентов предотвращает доступ отдельных пользователей или групп Windows к компоненту).

У данной модели есть существенные недостатки. Когда клиент имеет необходимый уровень доступа, он может получить доступ ко всем интерфейсам, предоставляемым сервером OPC. OPC Security добавляет еще один уровень, который может сделать безопасность более детальной. Реализуя спецификацию безопасности OPC на сервере OPC, программист может сделать доступ к отдельным объектам и интерфейсам в зависимости от списков контроля доступа. Эти ACL (Access Control List – списки управления доступом) должны быть настроены конечным пользователем.

Для реализации безопасности сервер OPC должен использовать один или два дополнительных интерфейса: IOPCSecurityNT и IOPCSecurityPrivate.

• SecurityNT – управление доступом с использованием учетных данных NT. Интерфейс применяется к пользователю Windows клиента OPC Client. Он может использовать его без собственной реализации спецификации безопасности.

• SecurityPrivate – управление доступом с использованием частных учетных данных. Интерфейс предназначен для пользователей, работающих с ОС, несовместимыми с NT (например, Unix). Он используется там, где безопасность системы необходимо отделить от безопасности домена.

Если оба интерфейса в настоящее время включены, то по умолчанию сервер OPC будет предполагать, что клиент работает с учетными данными NT. И будет продолжать делать это до тех пор, пока клиент явно не вызовет метод IOPCSecurityPrivate::Logon. Как только это произойдет, OPC-сервер будет принимать все решения об авторизации доступа на основе личных учетных данных, пока клиент не вызовет IOPCSecurityPrivate::Logoff.

По возможности сервер OPC, который реализует безопасность OPC, должен принимать решения об авторизации доступа на основе токена доступа NT, связанного с клиентским приложением. Такой подход позволяет обеспечить прозрачность безопасности для клиентских приложений, поскольку нет необходимости предпринимать явные действия для создания дополнительного сертификата доступа. Кроме того, поскольку токен доступа NT не зависит от сервера OPC, этот подход упрощает написание переносимых клиентских приложений.

Однако существуют обстоятельства, которые препятствуют использованию токена доступа NT. Вот некоторые примеры таких ситуаций:

• Сервер OPC работает в операционной системе, отличной от NT, которая поддерживает DCOM, например, Windows CE.

• Клиентские приложения могут работать в операционной системе, которая не поддерживает создание токена доступа NT.

• Сервер OPC и клиентские приложения распространяются на несколько устройств вне контекста домена NT.

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

Серверы OPC, которым необходимо поддерживать клиентские приложения с токенами доступа NT, а также клиенты, не имеющие токенов доступа NT, могут реализовать поддержку обоих типов сертификатов доступа для каждого клиента. Этот подход обеспечивает прозрачную реализацию безопасности для клиентов с токенами доступа NT и обеспечивает безопасность для клиентов без токенов доступа NT.

Правильно реализованная спецификация безопасности также является огромным преимуществом в больших архитектурах OPC (более 20 000 элементов). Это преимущество можно использовать для фильтрации адресного пространства для определенных групп пользователей, чтобы пользователи в этих группах видели только элементы для своих соответствующих групп.

Безопасность доступа к данным OPC

Большинство серверов OPC DA реализуют спецификацию безопасности на основе адресного пространства DA. [7] На сервере OPC настраиваются разрешения, которые позволяют пользователю выполнять действия с узлами иерархии или отдельными элементами. 

Типичные действия:

• Чтение

• Запись

• Обзор/Добавление элементов

На рисунке 3 изображены следующие действия для пользователей:

• Пользователь A может читать только часть адресного пространства

• Пользователь B может читать/записывать

• Пользователь C не может просматривать

Как именно поставщик реализует безопасность OPC внутри своего сервера OPC – не определено. В спецификации определены только необходимые основы для подключения пользователя клиента OPC к серверу OPC при его подключении.

Уязвимости OPC

Были проанализированы известные уязвимости продуктов OPC Foundation, использующих стандарты OPC. Для поиска и анализа была взята база данных уязвимостей cvedetails.com. Всего была найдено 21 уязвимость. Для большинства уязвимостей выпущены исправления. Актуальными можно считать 13 уязвимостей 2021 и 2020 года, которые затрагивают версии продуктов с недавно выпущенными обновлениями.

Основным вектором атак большинства описанных уязвимостей являются специально созданные пакеты. Большая часть данных уязвимостей имеет сетевой доступ. Поэтому межсетевой экран и СОВ являются решением для защиты от большинства уязвимостей при наличии известных сигнатур.

Основные рекомендации:

• Использование межсетевого экрана. Для использования межсетевого экрана необходимо наличие известных сигнатур. Для установки соединения OPC DCOM используется 135 порт, OPC UA использует 4840, 4841 порты (но может быть использован любой порт). Одним из возможных решений является межсетевой экран InfoWatch ARMA Industrial Firewall, который создан с учетом требований для АСУ ТП. Существующая база правил обнаружения вторжений постоянно пополняется, чтобы обнаруживать подозрительный трафик на основе описания новейших уязвимостей.

• Использование встроенных интерфейсов IOPCSecurityNT и IOPCSecurityPrivate.

• Использование белых списков, ограничение действий пользователей.

Важно отметить, что так как соединение OPC DA создается над соединением DCERPC, необходимо учитывать имеющиеся уязвимости RPC. Однако в данной статье уязвимости RPC не приведены, так как выходят за рамки темы исследования.

Заключение

В данном материале был описан набор стандартов OPC, показаны различные модели безопасности для стандарта OPC DA. Представлены сценарии доступа к информации для реализации адресного пространства, проанализированы существующие уязвимости устройств платформы OPC Foundation и приведены основные рекомендации по защите от их эксплуатации.

Автор статьи: Парнева Ксения

1. https://www.bookasutp.ru/chapter9_2.aspx

2. https://asutp.ru/publikacii/2021/04/29/prosto-o-standartah-opc-da-i-opc-ua/

3. OPC Security White Paper #1 Understanding OPC and How it is Deployedюю Digital Bond British Columbia Institute of Technology Byres Research, 2007 https://scadahacker.com/library/Documents/OPC_Security/OPC%20Security%20-%20Understanding%20OPC.pdf

4. https://ipc2u.ru/articles/prostye-resheniya/prosto-o-standartakh-opc-da-i-opc-ua/

5. https://www.claroty.com/wp-content/uploads/2021/02/FINAL_Claroty_OPC_Research_Paper.pdf

6. http://advosol.com/OpcSpecs/OPC%20Security%201.00%20Specification.pdf

7. https://inmation.com/docs/system/1.64/opc-connectivity/opc-security.html