Решение команды Foxhound, хакатон KasperskyCyberimmunityHack2023. Демонстрационный сервер развёрнут на http://158.160.98.150 или http://foxhound-team.pro (ссылка действительна до 30 апреля 2023 г.):
- Графический интерфейс Broker UI: http://158.160.98.150:8080/ или или http://foxhound-team.pro:8080/,
- ELK dashboard для просмотра инцидентов: http://158.160.98.150:5601/app/discover/ или http://foxhound-team.pro:5601/app/discover/ (пароль
admin
, логинadmin
, развёрнут для просмотра логов/инцидентов), - Apache Kafka: 158.160.98.150:9092 или http://foxhound-team.pro:9092.
- Мажоритарная логика работы ПП: экземпляр ПП представлен тремя независимо разработанными и одновременно работающими модулями, управляющими устройствами через доверенный модуль мажоритарной логики. Снижение влияния отдельных уязвимостей и ошибок на работу системы, снижение вероятности одновременного отказа.
- Неприрывное развёртывание новых версий: на устройстве одновременно работает предыдущая (в 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)
- Змиёв Александр - python-разработка (контроль целостности ПП в виртуальной памяти), оформление документации
- Недогарок Антон - капитан, разработка архитектуры ПЛК, python-разработка компонентов ПЛК, оформление документации
- Панин Максим - DevOps, тестирование
- Петров Антон - DevOps, разработка и реализация монитора безопасности
- Рябов Константин - разработка архитектуры ПЛК, разработка сценариев и другой документации
- KasperskyCyberimmuneHack2023
- Описание компонентов репозитория
- Отчёт о выполнении задачи "Создание программы для управления оборудованием на теплоэлектростанции"
- Описание переменных окружения
- Генерация ключей компонентов для подписи сообщений Kafka
- Тестирование
license_server
- сервер лицензированияmonitor
- монитор безопасностиplc
- компоненты ПЛКsample_processes
- примеры реализации процессов для взаимодействия с мониторомscada
- компоненты SCADAsensors
- компоненты имитации сенсоровstorage
- версии ПП
Необходимо создать прикладную программу (ПП), в которой будут реализованы следующие функции для корректной работы теплоэлектростанции:
- Получение и обработка данных от полевых устройств:
- Сигналы, не требующие дополнительной обработки
- Сигналы, для которых необходима дополнительная логика обработки, чтобы получить итоговое значение
- Изменение установок ПП с АРМ
- Обновление ПП ПЛК
- Выполнение команды диспетчера на остановку оборудования
По условиям организаторов должна использоваться:
- Микросервисная архитектура
- Шина обмена сообщениями (Apache Kafka) для реализации асинхронной работы сервисов
- Security Monitor - сервис авторизации запросов все запросы между сервисами проходят через SM, прямой обмен сообщениями между сервисами запрещён по условиям задачи.
Цели безопасности:
- АСУ ТП всегда получает целостные критичные данные от ПЛК
- ПЛК выполняет только аутентичное ПП
- Конечное оборудование всегда получает аутентичные команды
- Только авторизованные пользователи имеют доступ к лицензии ПЛК
Предположения безопасности:
- Физическая защита периметра обеспечена
- Персонал ТЭЦ благонадежен
- Технологическое оборудование (Турбина) исправное
- Уровень устройств ввода-вывода - доверенный
- Рассматривается экспериментальная ТЭЦ, где оператор имеет только удалённый доступ к системе управления
Название | Назначение | Комментарий |
---|---|---|
Валидатор |
|
Доверенный компонент. В рамках условности прототипа валидатор и оркестратор объединены в единый модуль |
Оркестратор ПП |
|
Доверенный компонент. В рамках условности прототипа валидатор и оркестратор объединены в единый модуль |
Мажоритарная логика |
|
Доверенный компонент |
Интерфейс датчиков |
|
Доверенный компонент |
Монитор безопасности |
|
Доверенный компонент |
Прикладное ПО |
|
Недоверенный компонент по причинам использования сторонних компонентов и библиотек, большого объёма кода, который сложно контролировать, и возможного вовлечения сторонних подрядчиков. |
Каждый экземпляр прикладного ПО представлен набором из как минимум трёх одновременно работающих модулей. Каждый модуль реализует один и тот же функционал и одни и те же алгоритмы управления и обработки показаний датчиков. Выходные сигналы от каждого экземпляра обрабатываются доверенным компонентом "Мажоритарная логика".
Для снижения вероятности одновременного отказа или компрометации, экземпляры ПП должны быть
- разработаны различными подрядчиками или командами разработчиков,
- разработаны на различающемся технологическом стеке (разные языки, версии языков, библиотеки),
- собраны на различных машинах.
Мажоритарная логика выбирает неверные показания от ПП. Нарушается цель безопасности №3
Мажоритарная логика выбирает неверные команды от ПП. Нарушается цель безопасности №1
Интерфейс датчиков отдаёт неверные значения (или вообще не отдает). Нарушается цель безопасности №1
Оркестратор распространяет неаутентичную ПП. Нарушается цель безопасности №2
Валидатор пропускает модифицированную ПП, как следствие оркестратор распространяет неаутентичную ПП. Нарушается цель безопасности №2
Обобщённая диаграмма архитектуры
На данном рисунке указаны, ввиду общей сложности, только связи с внешними элементами системы (SCADA, ЧМИ оператора, датчики, исполнительные устройства), а цветами обозначены доверенные и недоверенные компоненты. Более детальную схему, с внутренними связями выделением компонентов, повышающих целостность данных, имеет смысл описывать для различных потоков данных:
Схема работы монитора безопасности
Описание работы монитора:
Монитору известны публичные ключи всех процессов.
Когда процесс хочет обратиться к другому процессу, он записывает сообщение в формате JSON в топик monitor. При этом он обязательно подписывает его своим приватным ключом.
Монитор слушает топик monitor, при получении нового сообщения, он отправляет задачу в rabbitmq с этим сообщением. Это необходимо для возможности масштабирования.
Воркеры dramatiq выполняют следующие валидации:
- Получили валидный JSON
- Источник существует
- Тело запроса передано от источника (проверка подписи)
- Получатель существует
- Разрешена пересылка сообщений от источника к получателю
- Тип сообщения существует
- Проверка корректности тела сообщения
Если хотя бы одна из этих валидаций не проходит, то воркер пишет warning лог в elk и отклоняет такое сообщение.
Если же все этапы успешно пройдены, то сообщение кладется в топик, который слушает процесс назначения
Код монитора расположен в monitor
- Установить docker
- В папке compose создать файл .env и заполнить его в соответствии с примерами
- Запустить команду docker compose up -d с правами суперпользователя
sudo docker compose -f docker-compose-kafka.yml up -d
Файлы: .env, .env.machine1, .env.machine2
Тип: строка
Назначение: адрес сервера кафки
Файлы: .env
Тип: строка
Назначение: хост елк стека
Файлы: .env, .env.machine1, .env.machine2
Тип: строка
Назначение: топик монитора или подпроцесса
Файлы: .env
Тип: словарь, пример {"machine1": "-----BEGIN PUBLIC KEY-----\nMFwwDQYJKoZI..."}
Назначение: словарь публичных ключей процессов
Файлы: .env
Тип: строка
Назначение: юзернейм брокера
Файлы: .env
Тип: строка
Назначение: пароль брокера
Файлы: .env
Тип: строка
Назначение: сервер брокера
Файлы: .env
Тип: список списков, пример [["rest", "machine1"], ["machine1","rest"]]
Назначение: описывает какие процессы могут взаимодействовать
Файлы: .env.machine1, .env.machine2
Тип: строка
Назначение: секретный ключ процесса
openssl genrsa -out private.pem 512
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
Алгоритм приведен в документе