Киберзащита АСУ ТП пока остается для безопасников сложной задачкой на логику. С одной стороны, нельзя оставить без ИБ-мониторинга сеть, которая, например, обеспечивает теплом и светом население или перегоняет нефть и газ. С другой, ну, а где гарантия, что все эти СЗИ никак не повлияют на АСУ ТП и что их не взломают те же самые хакеры? В этом посте мы хотели бы порассуждать о том, какие компоненты АСУ ТП все-таки стоит подключить к SOC и что это даст ИБ-специалистам.
Промышленные предприятия все чаще становятся объектами кибератак. При этом техники и инструменты, которые используют злоумышленники только усложняются. По нашим данным, более 90% атак со стороны высокопрофессиональных хакеров приходится именно на объекты КИИ, среди которых чаще всего атакуют энергетику, промышленность, ВПК и госсектор.
По оценке 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 обнаружить атаку и своевременно о ней уведомить соответствующее подразделение компании (обычно это отделы ИБ и АСУ ТП).
Для полноценного мониторинга потребуются события ИБ с хоста и копия трафика.
События ИБ с хоста нужны, так как далеко не все действия killchain могут быть обнаружены в сетевом трафике. Во-первых, он иногда зашифрован. Во-вторых, такие действия как повышение привилегий, дамп учетных записей, изменение конфигурации устройства могут быть определены только на уровне узла. Но в то же время эксплуатация сетевых уязвимостей, отправка нелегитимных команд и т.п. можно определить только на уровне копии трафика.
Значит, сначала нужно внедрить систему мониторинга трафика с поддержкой промышленных протоколов. Сложности с внедрением могут возникнуть на двух этапах:
выбор архитектуры сбора копии трафика (SPAN). Как обеспечить нужную производительность, как доставить копию трафика до IDS, как избежать потери пакетов и как правильно рассчитать нагрузку на IDS – придется решать эти вопросы;
интеграция IDS с самим SOC. Тут могут возникнуть вопросы о том, должна ли это быть отдельная система мониторинга, как ее интегрировать с SIEM, как обеспечить "отсутствие управляющих воздействий" на АСУ ТП.
Сбор событий ИБ потенциально интересен со следующих устройств и компонентов АСУ ТП:
прикладное ПО (SCADA-системы);
ПЛК;
контроллеры ПАЗ;
сетевое оборудование;
АРМ и серверы на уровне операционной системы;
средства защиты информации (антивирусное ПО, межсетевые экраны, системы контроля привилегированных пользователей и т.д.).
Поговорим подробно про каждый из компонентов.
Прикладное ПО
Наверное, сбор информации с прикладного ПО наиболее сложен в реализации. Возможности по логированию в SCADA системах также сильно различается в зависимости от производителя и версии ПО, так как единого стандарта здесь нет. В некоторых системах есть локальный лог, который доступен только через системы с интерфейсом GUI, в других — возможность отправлять данные по syslog, в третьих — локальный и трудночитаемый файл. Интересными событиями, с которых можно начать подключения прикладного ПО, конечно будут события аутентификации, создания или изменения прав пользователей (особенно администраторов), изменение конфигурации системы, остановка функций логирования и остановка самого процесса SCADA. Напомню, что один из типовых векторов атаки — это прямое взаимодействие с ПЛК (без использования прикладного ПО) и одновременная остановка 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 и др.), активация новых сетевых портов и изменение конфигурации. Это связано с тем, что технологические сети обычно достаточно статичны, и любое изменение может сигнализировать об инциденте. Также этим способом можно определять неправомерные подключения к сети роутеров, модемов, ноутбуков и прочих устройств, представляющих угрозу для АСУ ТП.
Как защитить АСУ ТП
В связи с возрастающей геополитической напряженностью, распространением вирусов-шифровальщиков и наличием большого количества уязвимостей в действующих сетях АСУ ТП организациям нужно настроить мониторинг и реагирование на киберинциденты. К сожалению, в АСУ ТП невозможно использовать такие же подходы, как в корпоративных сетях. В промышленном сегменте требуется учитывать специфику подключения и общие принципы по неинвазивности и отсутствию возможности управляющих воздействий.
Поэтому мы рекомендуем как минимум создать совместные рабочие группы между подразделениями АСУ ТП и ИБ. Также можно привлечь подрядчика (сервис-провайдера) для:
проведения аудита;
анализа возможностей по сбору событий ИБ и реализации функции мониторинга в АСУ ТП;
тестирования проектных решений на стенде (цифровом двойнике);
подготовки решения по подключению источников событий к системе мониторинга;
выполнения задачи по выявлению инцидентов в АСУ ТП с помощью временного или постоянного SOC'а провайдера;
обучения и стажировки сотрудников службы реагирования;
проведения периодических киберучений.
Авторы:
Андрей Прошин, руководитель направления АСУ ТП Solar JSOC компании "Ростелеком-Солар"
Игорь Семенчев, пресэйл-аналитик Solar JSOC компании "Ростелеком-Солар"