Skip to content

FoxhoundTeam/KasperskyCyberimmunityHack2023

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

37 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

License: MIT GitHub contributors

KasperskyCyberimmunityHack2023

Решение команды Foxhound, хакатон KasperskyCyberimmunityHack2023. Демонстрационный сервер развёрнут на http://158.160.98.150 или http://foxhound-team.pro (ссылка действительна до 30 апреля 2023 г.):

Основные идеи, концепции, отличительные особенности нашей работы

Реализованные или частично реализованные за время хакатона

  • Мажоритарная логика работы ПП: экземпляр ПП представлен тремя независимо разработанными и одновременно работающими модулями, управляющими устройствами через доверенный модуль мажоритарной логики. Снижение влияния отдельных уязвимостей и ошибок на работу системы, снижение вероятности одновременного отказа.
  • Неприрывное развёртывание новых версий: на устройстве одновременно работает предыдущая (в standby-режиме) и новая версии ПО. При установке нового ПП сначала запускается и подключается новая версия, а затем выключается самая устаревшая.
  • Проверка целостности (хеша) экземпляров ПП как до запуска (целостность файла), так и во время работы (периодический дамп виртуальной памяти и проверка хеша сегмента .text)
  • Ошибка в техническом задании. Наша команда нашла и сообщила экспертам об ошибке в ТЗ, нарушающей физическую безопасность предприятия, в сценарии 3 из ТЗ. На закрытом чекпоинте в среду, 19 апреля, мы сообщили экспертам, по этому сценарию устройства, подключенные к ПЛК, нельзя остановить без ключа лицензии. Эксперты согласились, это это нарушало бы физическую безопасность предприятия, и опубликовали в телеграм комментарий для команд по данной особенности.

Требуют реализации

  • Подпись и проверка целостности исполняемых файлов ПП и файлов настроек на основе технологии блокчейн и истории (блоков) прошлых версий ПП
  • Защищённое хранилище ключей подписей сообщений и ключей лицений в Thrusted Execution Enviromnt CPU или отдельном Thrusted Platform Module контроллера. Например, при реализации ПЛК на архитектуре АРМ - в анклаве Thrust Zone (у команды есть опыт работы с аналогичной технологией Intel SGX, фрагмент методического пособия, разработанного капитаном команды: https://docs.google.com/document/d/1wYYU0GhCMVLvojmZo64iaut-POfzbGyXym54-3MeXko/edit?usp=sharing)

Команда Foxhound

  • Змиёв Александр - python-разработка (контроль целостности ПП в виртуальной памяти), оформление документации
  • Недогарок Антон - капитан, разработка архитектуры ПЛК, python-разработка компонентов ПЛК, оформление документации
  • Панин Максим - DevOps, тестирование
  • Петров Антон - DevOps, разработка и реализация монитора безопасности
  • Рябов Константин - разработка архитектуры ПЛК, разработка сценариев и другой документации

Содержание отчёта

Описание компонентов репозитория

  • license_server - сервер лицензирования
  • monitor - монитор безопасности
  • plc - компоненты ПЛК
  • sample_processes - примеры реализации процессов для взаимодействия с монитором
  • scada - компоненты SCADA
  • sensors - компоненты имитации сенсоров
  • storage - версии ПП

Отчёт о выполнении задачи "Создание программы для управления оборудованием на теплоэлектростанции"

Постановка задачи

Необходимо создать прикладную программу (ПП), в которой будут реализованы следующие функции для корректной работы теплоэлектростанции:

  • Получение и обработка данных от полевых устройств:
    • Сигналы, не требующие дополнительной обработки
    • Сигналы, для которых необходима дополнительная логика обработки, чтобы получить итоговое значение
  • Изменение установок ПП с АРМ
  • Обновление ПП ПЛК
  • Выполнение команды диспетчера на остановку оборудования

Известные ограничения и вводные условия

По условиям организаторов должна использоваться:

  • Микросервисная архитектура
  • Шина обмена сообщениями (Apache Kafka) для реализации асинхронной работы сервисов
  • Security Monitor - сервис авторизации запросов все запросы между сервисами проходят через SM, прямой обмен сообщениями между сервисами запрещён по условиям задачи.

Цели и Предположения Безопасности (ЦПБ)

Цели безопасности:

  1. АСУ ТП всегда получает целостные критичные данные от ПЛК
  2. ПЛК выполняет только аутентичное ПП
  3. Конечное оборудование всегда получает аутентичные команды
  4. Только авторизованные пользователи имеют доступ к лицензии ПЛК

Предположения безопасности:

  1. Физическая защита периметра обеспечена
  2. Персонал ТЭЦ благонадежен
  3. Технологическое оборудование (Турбина) исправное
  4. Уровень устройств ввода-вывода - доверенный
  5. Рассматривается экспериментальная ТЭЦ, где оператор имеет только удалённый доступ к системе управления

Архитектура системы

Компоненты

Название Назначение Комментарий
Валидатор
  • контроль целостности файлов ПП и обновлений ПП (реализовано в коде, но не запущено в демо-версии),
  • контроль целостности файлов настроек и обновлений настроек (не реализовано),
  • выдачу на шину подтверждения, что файлы проверены и их можно использовать в работе (не реализовано).
Доверенный компонент. В рамках условности прототипа валидатор и оркестратор объединены в единый модуль
Оркестратор ПП
  • контроль целостности виртуальной памяти запущенных процессов ПП (реализовано в отдельном модуле, но не развёрнуто в демо-версии),
  • контроль собственной целостности в виртуальной памяти и на диске (не реализовано),
  • запуск новых версий прикладного ПО (реализовано) после подтверждения от компонента "Валидатор",
  • организацию пула нескольких одновременно работающих версий ПП (реализовано), каждая из которых представлена тремя различающимися экземплярами для работы по мажоритарной логике (triple voting),
  • "бесшовный" запуск новых версий и останов старых, при котором гарантируется, что в каждый момент времени одновременно работает как минимум 2 версии и по 3 экземпляра ПП (реализовано),
Доверенный компонент. В рамках условности прототипа валидатор и оркестратор объединены в единый модуль
Мажоритарная логика
  • сравнение параметров телеметрии, выдаваемых экземплярами ПП, по мажоритарному принципу, принятие решения о целостности данных и выдача на SCADA или ЧПИ оператора (реализовано, но не запущено в демоверсии),
  • сравнение команд управления устройствами (включая защиту), сформированных экземплярами ПП, принятие решения о целостности данных по мажоритарному принципу и передача на устройство, с подтверждением в SCADA и ЧМИ оператора (реализовано, но не запущено в демоверсии)
Доверенный компонент
Интерфейс датчиков
  • выдача показаний датчиков в SCADA по REST,
  • выдача показаний датчиков в ПП по шине (с соответствующим контролем монитора) (реализовано).
Доверенный компонент
Монитор безопасности
  • Проверка целостности сообщения по дайджесту и ключам компонентов (реализовано),
  • Проверка полтики пересылки (источнику разрешено отправлять что-либо получателю) (реализовано),
  • Проверка по схеме (тип сообщения существует, формата соответствует) (реализовано).
Доверенный компонент
Прикладное ПО
  • регулярный приём показаний датчиков из компонента "Интерфейс датчиков" и автоматическое управление подключенным оборудованием (срабатывание защиты)
  • выдачу по запросу SCADA показаний датчиков, предварительно обротанных по заданному алгоритму (для получения непосредственных показаний без обработки следует общаться со SCADA напрямую к доверенному компоненту "интерфейс датчиков")
Недоверенный компонент по причинам использования сторонних компонентов и библиотек, большого объёма кода, который сложно контролировать, и возможного вовлечения сторонних подрядчиков.

Прикладное ПО. Развёрнутый комментарий

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

Система

Для снижения вероятности одновременного отказа или компрометации, экземпляры ПП должны быть

  • разработаны различными подрядчиками или командами разработчиков,
  • разработаны на различающемся технологическом стеке (разные языки, версии языков, библиотеки),
  • собраны на различных машинах.

Алгоритм работы решения

Получение и обработка данных от полевых устройств не требующие дополнительной обработки

Получение и обработка данных от полевых устройств требующие дополнительной обработки

Изменение установок ПП с АРМ

Обновление ПП ПЛК

Выполнение команды диспетчера на остановку оборудования

Описание Сценариев (последовательности выполнения операций), при которых ЦБ нарушаются

Сценарий 1a. Компрометация мажоритарной логики.

Мажоритарная логика выбирает неверные показания от ПП. Нарушается цель безопасности №3

Сценарий 1b. Компрометация мажоритарной логики.

Мажоритарная логика выбирает неверные команды от ПП. Нарушается цель безопасности №1

Сценарий 2. Компрометация интерфейса датчиков.

Интерфейс датчиков отдаёт неверные значения (или вообще не отдает). Нарушается цель безопасности №1

Сценарий 3. Компрометация оркестратора.

Оркестратор распространяет неаутентичную ПП. Нарушается цель безопасности №2

Сценарий 4. Компрометация валидатора.

Валидатор пропускает модифицированную ПП, как следствие оркестратор распространяет неаутентичную ПП. Нарушается цель безопасности №2

Указание "доверенных компонент" на архитектурной диаграмме.

Обобщённая диаграмма архитектуры

На данном рисунке указаны, ввиду общей сложности, только связи с внешними элементами системы (SCADA, ЧМИ оператора, датчики, исполнительные устройства), а цветами обозначены доверенные и недоверенные компоненты. Более детальную схему, с внутренними связями выделением компонентов, повышающих целостность данных, имеет смысл описывать для различных потоков данных:

Выдача команд исполнительным устройствам с ПП (автоматика) и команд оператора Получение простой информации непосредственно с датчиков в ПП и SCADA
Получение информации с датчиков, требующей обработки на устройстве Обновление ПП и лицензий
Обновление настроек

Политики безопасности

Схема работы монитора безопасности

Описание работы монитора:

Монитору известны публичные ключи всех процессов.

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

Монитор слушает топик monitor, при получении нового сообщения, он отправляет задачу в rabbitmq с этим сообщением. Это необходимо для возможности масштабирования.

Воркеры dramatiq выполняют следующие валидации:

  1. Получили валидный JSON
  2. Источник существует
  3. Тело запроса передано от источника (проверка подписи)
  4. Получатель существует
  5. Разрешена пересылка сообщений от источника к получателю
  6. Тип сообщения существует
  7. Проверка корректности тела сообщения

Если хотя бы одна из этих валидаций не проходит, то воркер пишет warning лог в elk и отклоняет такое сообщение.

Если же все этапы успешно пройдены, то сообщение кладется в топик, который слушает процесс назначения

Код монитора расположен в monitor

Запуск приложения

Развертывание через docker-compose

  1. Установить docker
  2. В папке compose создать файл .env и заполнить его в соответствии с примерами
  3. Запустить команду docker compose up -d с правами суперпользователя
sudo docker compose -f docker-compose-kafka.yml up -d

Описание переменных окружения

KAFKA_SERVER

Файлы: .env, .env.machine1, .env.machine2

Тип: строка

Назначение: адрес сервера кафки

OPENSEARCH_HOST

Файлы: .env

Тип: строка

Назначение: хост елк стека

KAFKA_TOPIC

Файлы: .env, .env.machine1, .env.machine2

Тип: строка

Назначение: топик монитора или подпроцесса

SOURCE_KEY_MAP

Файлы: .env

Тип: словарь, пример {"machine1": "-----BEGIN PUBLIC KEY-----\nMFwwDQYJKoZI..."}

Назначение: словарь публичных ключей процессов

BROKER_USER

Файлы: .env

Тип: строка

Назначение: юзернейм брокера

BROKER_PASS

Файлы: .env

Тип: строка

Назначение: пароль брокера

BROKER_SERVER

Файлы: .env

Тип: строка

Назначение: сервер брокера

POLICIES

Файлы: .env

Тип: список списков, пример [["rest", "machine1"], ["machine1","rest"]]

Назначение: описывает какие процессы могут взаимодействовать

PRIVATE_KEY

Файлы: .env.machine1, .env.machine2

Тип: строка

Назначение: секретный ключ процесса

Генерация ключей компонентов для подписи сообщений Kafka

openssl genrsa -out private.pem 512

openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Тестирование

Алгоритм приведен в документе