Рекомендации ENISA по проведению анализа инцидентов, связанных с АСУ ТП

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

Европейское агентство по сетевой и информационной безопасности (ENISA) разработало брошюру, в которой приведены общие рекомендации по проведению анализа инцидентов информационной безопасности, связанных с АСУ ТП (Industrial Control Systems, ICS) критически важных объектов.

Целевая аудитория: операторы АСУ ТП, инженеры по безопасности.

К известным видам АСУ ТП относятся: системы диспетчерского управления и сбора данных (Supervisory Control and Data Acquisition, SCADA), распределенные системы управления (Distributed Control Systems, DCS), программируемые логические контроллеры (Programmable Logic Controllers, PLC).

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

Вместе с тем системы мониторинга и контроля промышленных систем и критических инфраструктур нередко напоминают обычные «потребительские» компьютеры, в основе которых лежит стандартное коммерческое программное обеспечение, часто не обновляемое и устаревшее.

Инциденты компьютерной безопасности в области промышленных систем управления каждый раз подчеркивают важность надлежащего управления и контроля за SCADA-системами. Решающее значение приобретает реагирование на критические инциденты, а также умение анализировать и извлекать уроки из произошедшего. Развертывание систем обнаружения вторжений и отслеживания трафика становится все более необходимой практикой, особенно для современных промышленных систем управления, имеющих подключение к сети Интернет (IP-enabled).

Анализ инцидента

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

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

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

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

В первую очередь анализ инцидента направлен на:

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

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

Можно выделить 5 последовательных этапов анализа инцидентов:

1. Исследование. На данном этапе необходимо определить все возможные источники доказательств в SCADA-системе, а также во всех связанных с ней системах (терминалы доступа, серверы регистрации, маршрутизаторы).
2. Идентификация доказательств. Данный этап предполагает определение типа и технических характеристик исследуемой системы, типа программируемых логических контроллеров, особенностей построения и реализации сети, изучение человеко-машинного интерфейса.
3. Сбор доказательств. Сбор данных от всех систем и компонентов памяти, которые были определены в предыдущем пункте. А также отслеживание всего сетевого трафика.
4. Анализ доказательств. Включает:
   • Анализ физической среды (жестких дисков, карт памяти, флэш-накопителей). Предполагает перевод всего содержимого памяти к стандартному интерфейсу (IDE или SCSIs).
   • Анализ носителей данных. Предполагает анализ структуры памяти (определение разделов жестких дисков и т. д.).
   • Анализ файловой системы. Предполагает просмотр каталогов и содержимого файлов, включая восстановление удаленных файлов.
   • Прикладной анализ. Просмотр журналов регистрации событий, файлов конфигурации, изображений, документов и файлов обратного проектирования (reverse engineering executable). Поступающие данные, как правило, извлекаются из файловой системы, а прикладные данные, например базы данных, могут быть прочитаны напрямую с диска.
   • Анализ сети (сетевых пакетов, журналов регистрации транзакций, сгенерированных сетевыми службами, межсетевым экраном или веб-сервером).
   • Анализ памяти. Предполагает идентификацию команд, при помощи которых извлекались конфиденциальные данные.
5. Документация процесса и результата. На каждом этапе анализа инцидента необходимо фиксировать состояние и статус системы, дату, время, проводимые операции, ответственное лицо. Это позволит избежать каких-либо вмешательств в аналитический процесс, а в случае будущих инцидентов документация станет основой для их обработки.

Реагирование на инцидент

Процедура анализа произошедшего инцидента обычно начинается после завершения реагирования на инцидент – смягчения негативных последствий инцидента и восстановления системы.

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

Основные компоненты реагирования на компьютерные инциденты:

1. Обнаружение.
2. Организация мероприятий по реагированию.
3. Мероприятия по реагированию на инцидент / Сбор доказательств.
4. Восстановление работоспособности после инцидента / Анализ доказательств.
5. Закрытие инцидента / Составление отчетной документации.

В связи с этим, команда группы реагирования должна включать:

• Руководителя группы управления инцидентами (Control Systems Incident Manager, CSIM) — контролирует операции по реагированию в области систем управления;
• Специалиста по системам управления безопасностью (Control Systems Security Specialist, CSSS) — определяет, на какие критически важные объекты повлиял инцидент;
• Специалиста из технической поддержки систем управления (Control Systems Engineering Support, CSES) — обеспечивает восстановление и обновление системы.

Доказательства, их соразмерность и целостность

Анализ инцидента предполагает сбор следующих показателей:

1. Временные метки. Во многих SCADA-системах характер процессов предполагает выполнение определенных операций и транзакций в течение миллисекунд. Принимая во внимание изменчивость доказательств в системах управления, аналитику необходимо учитывать точные временные метки в ходе проведения анализа.
2. Журналы регистрации операций и транзакций. В зависимости от характера SCADA-системы различные данные могут быть извлечены из различных компонентов.
3. Другие источники данных: различные устройства хранения данных, которые могут быть обнаружены в помещениях центра управления SCADA-системы (съемные носители, например, дискеты, компакт-диски, USB-устройства и др.).
4. Общие сбои в работе системы.
5. Мониторинг работы системы в реальном времени.
6. Контроль целостности устройства.

Проблемы, которые могут возникнуть в ходе анализа пострадавшей SCADA-системы

1. Проблемы сбора данных:
   • неэффективные механизмы регистрации событий в SCADA-системе (ограничивают область реагирования на инциденты, т.к. ориентированы на нарушения в работе систем, а не на угрозы безопасности);
   • изменчивость данных (особенности систем управления связаны с заменой, удалением данных, что затрудняет их протоколирование);
   • проблемы совместимости традиционных инструментов сбора данных (например, «DD» или «Memdump») с настройками SCADA-системы;
   • большие объемы данных и проблемы их хранения;
   • нехватка вычислительных мощностей для записи и анализа данных;

2. Проблемы анализа данных:
   • инструменты анализа данных основываются на предварительно скомпилированных скриптах и ПО, которые должны быть модифицированы в соответствии с техническими требованиями системы управления;
   • необходимость отслеживания корреляций между разрозненными данными, собранными из разных источников для создания целостной картины инцидента.

3. Проблемы эксплуатации:
   • Различия в подходах к ИБ у специалистов в области информационных технологий и персонала, эксплуатирующего системы. Если первые ориентированы на «конфиденциальность, целостность, доступность» информации, то вторые — на «доступность, надежность, безопасность»;
   • Отсутствие специальных научных исследований, посвященных контролю и использованию контрольно-измерительного оборудования, связанного с управлением доступом, шифрованием и регистрацией событий;
   • нехватка квалифицированных кадров для работы с устаревающими системами;
   • разные жизненные циклы компонентов ИТ-инфраструктуры и компонентов SCADA-систем.

Ключевые рекомендации

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

1. Четкое определение области поиска цифровых доказательств инцидентов и действий, которые необходимо предпринять для их сохранения.
2. Защита систем:
   • развертывание эффективных систем контроля и безопасности (межсетевые экраны, системы обнаружения вторжений), способных минимизировать риски, выявлять инциденты и обеспечивать механизмы противодействия;
   • ведение регистрации событий в рамках всей системы;
   • проектирование и настройка системы таким образом, чтобы обеспечить сохранение цифровых доказательств (чтобы злоумышленник не смог удалить следы вторжения).

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

4. Развитие межорганизационного взаимодействия, частно-государственного партнерства и межгосударственного сотрудничества.