Форматы-мероприятий-хакатон.md

---

Обучение кибериммунитету в игровом формате: хакатон

• Обучение кибериммунитету в игровом формате: хакатон
  • Формат
    • Тема: Кибериммунность
    • Идея
    • Условия и инструментарий хакатона
    • Задачи
    • Примерное (рекомендуемое) распределение времени и последовательность работ среднестатистической команды
    • Рекомендумое распределение обязанностей в команде
    • Результат работы команды
      • Вариант “Минимальный”. Проект
      • Вариант “Расширенный”. Реализация-код ПО
    • Оценка работ
      • Этап квалификации
      • Критерии оценки работ на хакатоне
  • Другие форматы

Формат

Тема: Кибериммунность

Как собрать “доверенное” устройство из комбинации доверенных и недоверенных компонент.

Идея

Современные устройства создаются на основе переиспользования кода. Однако это же переиспользование создает риски ИБ, поскольку “чужой код - потемки”.

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

В рамках хакатона команда должна создать:

• прототип популярного устройства/приложения (выбрать из списка задач, предложенных индустриальными партнёрами), с использованием существующих в мире библиотек, компонент, сервисов.
• цели и предположения безопасности (ЦПБ)
• сценарии работы кода, при которых цели безопасности нарушаются
• использовать монитор безопасности, к которому обращаются за проверками «а можно ли сейчас сделать такую операцию», и написать в нем правила безопасности (на любом языке).
• Написать тесты, проверяющие эти негативные сценарии.

Предположения (допущения) безопасности от организаторов:

• монитор безопасности надёжно защищен от любого взлома и его решениям всегда можно доверять
• брокер сообщений также надёжно защищён

Условия и инструментарий хакатона

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

2. В решении должны быть использованы:

   • Message Bus - шина обмена сообщениями
     • Kafka message broker (технически kafka + zookeeper). Kafka используется из докер-образа (версия confluentinc/cp-kafka:7.2.0)
   • Security Monitor (SM) - сервис авторизации запросов все запросы между сервисами проходят через SM, прямой обмен сообщениями между сервисами запрещён по условиям задачи. SM должен содержать в себе описание разрешённых операций и их атрибутов, авторизует или блокирует запрос между сервисами. Данный сервис первым получает все запросы, если проверка безопасности проходит успешно, то монитор извлекает из поля ‘deliver_to’ имя топика сервиса-получателя и отправляет в него сообщение с добавлением поля ‘authorized’ и значением true для него. Правила проверки могут быть построены на анализе отправителя, получателя и любых дополнительных полей или условий, на выбор команды.

3. Сервисы могут быть реализованы на любом языке из списка допустимых в хакатоне.

4. Интеграция сервисов с Message Bus делается в зависимости от языка программирования, на основе публично доступных примеров Kafka (Clients | Confluent Documentation, Consumer · KafkaJS). В примере задачи-решения используется Python + Kafka. Для решения задачи команда может взять код прямо из Примера, или по аналогии написать код для выбранного языка программрования.

5. Безопасность сервисов.

Предполагается, что монитор безопасности надёжно защищен от любого взлома и его решениям всегда можно доверять. Предполагается, что обмен сообщениями через Message Bus надёжно защищен от любого взлома и его решениям всегда можно доверять. Предполагается, что любой сервис представляет собой переиспользованный код 3х сторон, и не имеет никаких гарантий безопасности - как от наличия в коде уязвимостей, так и закладок. Таким образом, по условиям хакатона любой сервис может быть взломан и изменен так, чтобы выполнять код, необходимый злоумышленникам. То есть в начальной постановку задачи все сервисы являются недоверенными. 6. В рамках решения задачи команда может объявить один или несколько сервисов “Доверенными”.

Доверенный - означает сервис, взлом которых приводит к невозможности обеспечить ЦПБ. Таким сервисы приходится считаьт “довернными”, и полностью проверять код на наличие уязвимостей / закладок. Остальные сервисы продолжают оставаться недоверенными - мы не проверяем их на уязвимости, но способны гарантировать выполнение целей безопасности даже при их взломе. Доверенными рекомендуемтся выбирать сервисы, в которых меньше всего кода и меньше всего “ветвлений” - то есть разных веток выполнения кода. Тогда проверки становятся заметно “дешевле”. Чем меньше в решении доверенных компонент, тем лучше. Идеально - когда в системе 0 дополнительных доверенных компонент (а вся безопасность обспечивается только наличием монитора безопасности). Относительное хорошим будет решение с 1-2 доверенным сервисами. 7. Языки программирования: Python, C++, JavaScript, Go.

PS: Подход, используемый в хакатоне (монитор безопасности), является отражением международно признанных подходов к разработке безопасных систем MILS & FLASK. Подробности можно найти в материалах, рекомендованных для подготовки к хакатону (см. список ниже).

Задачи

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

Постановка задачи включает в себя:

• Описание системы и ее минимального функционала

• Типовую архитектуру системы (компоненты и их роли/связи/потоки данных-управления)

• Алгоритм выполнения базового функционала

• Вводные/намеки на ЦПБ (примеры атак и их последствий, или области внимания для ИБ).

Команда НЕ МОЖЕТ уменьшить функционал устройства или изменить основной позитивный алгоритм.

Команда имеет право выбрать те угрозы / цели безопасности, которые может реализовать. Может добавить свои цели и предположения безопасности.

Команда имеет право в рамках решения изменить архитектуру системы (набор сервисов может быть расширен, сокращен, сервисы могут быть объединены или наоборот один сервис может быть разделен на несколько частей).

Задача должна быть решена с соблюдением условий и инструментария хакатона.

Примерное (рекомендуемое) распределение времени и последовательность работ среднестатистической команды

1. Подготовка инфраструктуры, изучение обучающих видео и примеров - 4 часа (на этапе квалификации)
2. Изучение и обсуждение постановки задачи - 1 час
3. Анализ угроз (в т.ч. негативных сценариев), подготовка целей и предположений безопасности - 4 часа
4. Разработка кода - 8 часов
5. Разработка и автоматизация тестов (позитивных и негативных) - 4 часа
6. Подготовка отчёта - 3 часа
7. Суммарный бюджет времени - 20 часов

Рекомендуемая последовательность работы: 1-2-3-4-5-6, причём этап 6 (подготовка отчёта) следует начинать даже раньше и параллельно с 3. - документирование ЦПБ, архитектуры и, особенно, негативных сценариев может занять больше времени, чем кажется.

Неправильная последовательность работы: 1-2-4-1-6-3-4-6 (5 не успели)

Почему эта последовательность неправильная? Объясняем: разработка кода до анализа угроз и формулировки ЦПБ приведёт к осознанию необходимости переделки кода на этапе подготовки отчёта (сроки уже горят), после этого на разработку тестов времени не останется. Жюри не сможет проверить работу проекта команды в условии отсутствия тестов, как результат, команда потеряет до половины очков.

Логика появления артефактов команды на диаграмме ниже

Рекомендумое распределение обязанностей в команде

один человек, который продумывает архитектуру и пишет отчет + желательно, человек, который, работает с диаграммами; один-два человека, которые пишут код (если два человека, то это должны быть очень слаженные программисты, которые понимают друг друга с полуслова, иначе лучше одного) и один человек, который занимается тестами

Результат работы команды

Вариант “Минимальный”. Проект

1. Архитектура решения (DFD - диаграмма)
2. Цели и Предположения Безопасности (ЦПБ)
3. Алгоритм работы решения (sequence diagram)
4. Указание “доверенных компонент” на архитектурной диаграмме с обоснованием выбора.
5. Описание Сценариев (последовательности выполнения операций), при которых ЦБ нарушаются
6. Политики безопасности (список разрешенных-запрещенных операций, блокирующие выполнение негативных сценариев) на языке программирования или псевдокоде.

Вариант “Расширенный”. Реализация-код ПО

1. Прототип решения, написанный в соответствии с условиями хакатона, успешно выполяющийся и демонстрирующий успешное выполнение бизнес-логики решения,
2. Код Политики безопасности (реализованные внутри Монитора безопасности на выбранном языке программрования)
3. Набор тестов, показываемых невозможность реализовать негативные сценарии

Оценка работ

Этап квалификации

1. написать автотест для любого негативного сценария в примере secure update
2. обновить отчёт с описанием негативного теста в виде sequence диаграммы

Как будет проверяться: запуск изменённого кода (код должен быть выложен на github), проверка отчёта.

Критерии оценки работ на хакатоне

1. Наличие документов с описанием ЦПБ, архитектуры решения и кода. При наличии работающего кода, реализующего предложенную архитектуру - описание как запустить и выполнить функциональный тест (если есть тесты безопасности - как выполнить их).
2. Функционал - заявленная в условиях задачи последовательность выполнения функций должна выполняться. Как на уровне sequence diagram, так и на уровне кода.
3. Тесты безопасности (автоматические или ручные), разработанные командой
4. ЦПБ - должны соответствовать бизнес-цели устройства, быть непротиворечивыми, достижимыми и проверяемыми. Анализ угроз и количество качественно отличающихся сценариев в нём.
5. Архитектура решения и выбор доверенных компонент - выбор должнен быть обоcнован, а количество доверенных компонент - минимальным.
6. Тесты безопасности (с использованием расширенного набора сценариев для конкретных задач, находящегося в распоряжении организаторов)

При прочих равных преимущества получат работы, в которых:

• Функциональная сложность выбранного решения (количество и степень проработки компонент на изначальной архитектуре системы из условий задачи) выше.
• Заявлено и достигнуто больше Целей Безопасности (при условии что ЦПБ соответствуют критериям ЦПБ из п.3.).

Другие форматы

• CTF
• Курсовые работы