Мониторинг и ничего лишнего: какие компоненты АСУ ТП точно стоит подключить к SOC

Авторы:
Андрей Прошин, руководитель направления АСУ ТП Solar JSOC компании "Ростелеком-Солар"
Игорь Семенчев, пресэйл-аналитик Solar JSOC компании "Ростелеком-Солар"

Промышленные предприятия все чаще становятся объектами кибератак. При этом техники и инструменты, которые используют злоумышленники только усложняются. По данным «Ростелеком-Солар», более 90% атак со стороны высокопрофессиональных хакеров приходится именно на объекты КИИ, среди которых чаще всего атакуют энергетику, промышленность, ВПК и госсектор. Схожую динамику угроз озвучили и представители НКЦКИ на SOC-Форуме 2021: основные отрасли, на которые направлены кибератаки, – это госсектор (21%), ТЭК (17%) и промышленность (14%).

По оценке Claroty, только за первое полугодие 2021 года было опубликовано 637 уязвимостей в технологическом оборудовании и ПО 76 производителей. При этом еще полгода назад показатели были следующими: 449 и 59 соответственно. При этом 61% всех уязвимостей связаны с возможностями удаленной эксплуатации, а 65% – с возможностью полной потери доступности (Availability) системы. Данные БДУ ФСТЭК также подтверждают, что большое количество недочетов и ошибок связаны именно с возможностью эксплуатации по сети, что в совокупности со сложностями оперативной установки обновлений и применения workaround делает технологические сети уязвимыми перед атаками продвинутых киберпреступников.

На безопасность АСУТП также влияет активное развитие рынка RaaS (программа-вымогатель как услуга). По данным «Ростелеком-Солар», за 2020 год количество атак с применением шифровальщиков выросло на 30% и тренд продолжается до сих пор. Практически каждую неделю появляются новости о новых инцидентах с вирусами-шифровальщиками в компаниях, имеющих АСУ ТП. Например, в ноябре 2021 года произошли атаки на австралийскую компанию CS Energy и электроэнергетическую компанию Delta-Montrose Electric Association (DMEA). Последняя в результате действий хакеров потеряла все свои данные за последние 25 лет.

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

Описание типовой архитектуры АСУ ТП (модель Purdue)

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

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

Модель Purdue состоит из нескольких уровней, которые отражают состав технологической сети:

• физические устройства (сенсоры, датчики, исполнительные механизмы),
• ПЛК (программируемые логические контроллеры) и SCADA системы для управления большим количество физических устройств;

• DMZ сеть (серверы исторических данных (historian), контроллеры домена, серверы удаленного доступа и т.д.);
• корпоративная сеть (системы управления производством, ERP и вся остальная инфраструктура, включая доступ в сеть Интернет).

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

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

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

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

Какое оборудование стоит подключать к SOC и зачем

Чем больше систем мы подключим к централизованному мониторингу, тем легче будет аналитикам SOC обнаружить атаку и своевременно о ней уведомить соответствующее подразделение компании (обычно это отделы ИБ и АСУ ТП).

Для полноценного мониторинга потребуются события ИБ с хоста и копия трафика.
События ИБ с хоста нужны, так как далеко не все действия killchain могут быть обнаружены в сетевом трафике: во-первых, он иногда зашифрован; во-вторых, такие действия как повышение привилегий, дамп учетных записей, изменение конфигурации устройства могут быть определены только на уровне узла. Но в то же время эксплуатация сетевых уязвимостей, отправка нелегитимных команд и т.п. можно определить только на уровне копии трафика.

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

• выбор архитектуры сбора копии трафика (SPAN). Как обеспечить нужную производительность, как доставить копию трафика до IDS, как избежать потери пакетов и как правильно рассчитать нагрузку на IDS – придется решать эти вопросы;

• интеграция IDS с самим SOC. Тут могут возникнуть вопросы о том, должна ли это быть отдельная система мониторинга, как ее интегрировать с SIEM, как обеспечить “отсутствие управляющих воздействий” на АСУ ТП.

Сбор событий ИБ потенциально интересен со следующих устройств и компонентов АСУ ТП:

• ПЛК;
• контроллеры ПАЗ;
• сетевое оборудование;
• АРМ и серверы на уровне операционной системы;
• средства защиты информации (антивирусное ПО, межсетевые экраны, системы контроля привилегированных пользователей и т.д.);
• прикладное ПО (SCADA-системы);

Поговорим подробно про каждый из компонентов.

ПЛК (программируемые логические контроллеры)

Наравне с прикладным ПО это наиболее сложная часть, так как в технологических сетях встречается множество производителей и версий прошивок. Даже у одного производителя, функциональность ПЛК в части логирования событий ИБ сильно зависит от модели и от прошивки. С ПЛК можно получить следующие типовые события:

• ошибки аутентификации;
• включение/выключение сервисов (HTTP/FTP и т.д.);
• факт загрузки новой конфигурации или проекта;
• изменение состояния ПЛК (run/stop);
• подключение новых устройств.

«Ростелеком-Солар» уже проводил испытания на оборудовании Schneider Electric, также мы подключали ПЛК Siemens и российских производителей ("Энтелс"). Наш опыт показал, что интересные с точки зрения ИБ события могут быть доставлены и нормализованы в SIEM, и на их основе можно создавать корреляционные правила.

АРМ и серверы

Обычно в качестве ОС на рабочих станциях операторов и инженеров, а также на серверах используются ОС семейства Windows, для сбора событий на которых не требуется установка дополнительных программных компонентов. Достаточно стандартных логов Windows и в некоторых случаях расширенного мониторинга с помощью Sysmon. Мы также рекомендуем дополнительно настроить сбор событий о выполняемых командах, сбор событий о запуске Script-Block и Module Logging в Powershell, доступ к файлам, изменение веток реестра.

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

Бояться включения логирования на уровне ОС не стоит, но, конечно, перед конфигурацией решение должно быть протестировано для каждой отдельной установки. По нашему опыту, загрузка CPU для процесса Sysmon составляет менее 1% даже в случае эмуляции атаки, то есть в момент, когда логов генерируется больше.

Средства защиты информации

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

Обычно эти СЗИ поддерживают логирование событий ИБ в полном объеме: это отправка по протоколу syslog сообщений об обнаруженном ВПО, истечении лицензий, остановки агента, заблокированных сетевых соединениях и т.д. Эта информация полезна для выявления вредоносного ПО, обнаружения скрытых каналов связи или управления. Но ее явно недостаточно, поэтому по мере реализации проекта по защите ОКИИ/ЗОКИИ новые средства защиты могут быть подключены к общей системе мониторинга.

Сетевое оборудование

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

Прикладное ПО

Наверное, сбор информации с прикладного ПО наиболее сложен в реализации. Возможности по логированию в SCADA системах также сильно различается в зависимости от производителя и версии ПО, т.к. единого стандарта здесь нет. В некоторых системах есть локальный лог, который доступен только через системы с интерфейсом GUI, в других — возможность отправлять данные по syslog, в третьих — локальный и трудночитаемый файл. Интересными событиями, с которых можно начать подключения прикладного ПО, конечно будут события аутентификации, создания или изменения прав пользователей (особенно администраторов), изменение конфигурации системы, остановка функций логирования и остановка самого процесса SCADA. Напомню, что одним из типовых векторов атаки — это прямое взаимодействие с ПЛК (без использования прикладного ПО) и одновременная остановка SCADA (то есть потеря эксплуатирующим персоналом возможности влиять на ситуацию).

Как защитить АСУ ТП

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

Поэтому мы рекомендуем как минимум создать совместные рабочие группы между подразделениями АСУ ТП и ИБ. Также можно привлечь подрядчика (сервис-провайдера) для выполнения следующих задач:

• проведения аудита;
• анализа возможностей по сбору событий ИБ и реализации функции мониторинга в АСУ ТП;
• тестирования проектных решений на стенде (цифровом двойнике);
• подготовки решения по подключению источников событий к системе мониторинга;
• временном или постоянном использовании SOC'а провайдера для выполнения задачи по выявлению инцидентов в АСУ ТП;
• обучения и стажировки сотрудников службы реагирования;
• проведению периодических киберучений.