Учебный пример и настройка окружения.md

Учебный пример и настройка окружения

Учебный пример и настройка окружения
- Безопасное обновление
  - Задача
Решение
- Настройка рабочего окружения для запуска примера
- Отчёт и код
  - Тесты

Безопасное обновление

Задача

Задача заключается в обновлении прошивки устройства, при условии, что прошивка авторизована - то есть соответствует версии прошивки, полученной из доверенного источника (от поставщика прошивки).

Давайте посмотрим на предполагаемую архитектуру и выделенные сущности простого и достаточно типичного примера реализации системы обновления:

Downloader скачивает данные из сетей общего пользования
Manager оркестрирует весь процесс обновления
Verifier проверят корректность скачанной прошивки
Storage – промежуточное хранилище скачанной прошивки
Updater непосредственно применяет обновление.

Для примера ниже показана диаграмма потока данных процесса верификации в нашей системе обновлений: Manager запрашивает Verifier проверку обновления, Verifier читает данные из - Storage и при позитивном вердикте, изменяет состояние системы, чтобы указать, что в Storage находится правильное обновление.

Монитор безопасности - системный сервис - проверяет весь обмен сообщениями между сущностями на соответствие политикам безопасности.

SUHLA

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

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

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

Например, обновляемое приложение может состоять из нескольких строк кода, нам важно только понимать, что оно работает и как-то понимать, что обновление произошло (или нет).

#!/usr/bin/env python
 
from flask import Flask          
app = Flask(__name__)             # create an app instance
 
APP_VERSION = "1.0.3u"
 
@app.route("/")                   # at the end point /
def hello():                     
    return f"Hello World! Application version {APP_VERSION}"        
 
if __name__ == "__main__":        # on running python app.py
    app.run(host="0.0.0.0")

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

В данном случае правильный – это некий набор проверок, который мы определили как достаточный.

Далее, для простоты примера, мы сразу же оставим за скобками проблемы доставки обновления на устройство и возможные атаки на доставку. И наконец, мы не будем рассматривать вопросы физической безопасности устройства.

Давайте посмотрим пример процедуры обновления на сиквенс диаграмме.

SUSD

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

В общем случае, компонент Manager может быть недоверенным, результаты проверки могут быть игнорированы или данные могут изменены после проверки.

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

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

Первая значимая команда в диаграмме – это запрос на проверку и первая возможная проблема, компонент Manager «забыл» отправить запрос на проверку, и таким образом в результате на обновление отправится непроверенная версия.

Следующая значимая команда – запрос на обновление и следующая возможная проблема, это то, что результат проверки может быть проигнорирован и запрос на обновление может отправиться неверная версия прошивки.

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

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

«забыли» отправить запрос на проверку обновления;
результат проверки проигнорировали;
данные обновления изменили после проверки.

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

Ниже представлены три выбранные сценария компрометации целей безопасности на диаграмме процесса обновления:

SUSD

Решение

Настройка рабочего окружения для запуска примера

Windows
- виртуальная машина с Linux (например, Ubuntu 20.04) или
- WSL (Linux subsystem for Windows) с Linux (например, Ubuntu 20.04), важно использовать версию WSL 2 или выше (иначе не будет работать docker) или
- Docker desktop (лицензия!)
Linux код примера тестировался с Ubuntu 20.04, но почти наверное будет работать и в других дистрибутивах при условии работающего docker-compose

Установленные пакеты

docker-compose
python3-pip
pipenv (командой sudo pip install pipenv)
pytest (командой sudo pip install pytest)

Видео-инструкция по настройке окружения

https://rutube.ru/video/private/b0dee7982b13382d2f6d0eb5d615355d/?p=MEK8DdzhOmF1y421noxJ-Q

Отчёт и код

описания решения доступно по ссылке: https://github.com/sergey-sobolev/secure-update/blob/main/docs/report/report.md
там же можно найти и исходный код: https://github.com/sergey-sobolev/secure-update

Тесты

Видео-инструкция по запуску тестов https://rutube.ru/video/private/3acada5b89bc18d76ab2f93d576df4c6/?p=oyPqAgHHtuOH98KPD5W6PQ