Задания для производственной практики - sergey-sobolev/cyberimmune-systems GitHub Wiki

Общая информация

Производственная практика в АО "Лаборатория Касперского" (ЛК) может проводиться в удалённом формате, по направлению кибериммунного подхода к разработке практикант выбирает тему ниже и сообщает об этом письмом на адрес [email protected] и/или своему куратору в ЛК, если такой уже есть.

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

Рекомендуем предварительно изучить учебные материалы по теме (см. страницу Кибериммунитет) и подписаться на наш телеграм-канал https://t.me/learning_cyberimmunity.

Темы для практики

Разработка автотестов безопасности для учебного проекта "Кибериммунное устройство мониторинга оборудования" (КУМО)

Задача: 0. подготовить локальную инфраструктуру для разработки (в качестве инструкции можно воспользоваться курсом https://stepik.org/course/133991/info

  1. сделать fork репозитория (все ветки) https://github.com/sergey-sobolev/secure-update, далее работать со своим репозиторием
  2. взять код из ветки feature/security-events-log
  3. с учётом целей безопасности для КУМО продумать и описать негативные сценарии - те, при которых нарушаются цели безопасности. Описать сценарии нужно в формате диаграмм последовательности, аналогично тем, что есть для примера "безопасное обновление", обновить отчёт
  4. используя код сервиса-имитатора (fake service) и примеры тестов в файле tests/e2e/negative_scenarios/test_ns_dp.py написать новые тесты, проверяющие блокировку негативных сценариев из п. 3.

Примечание: для контроля событий безопасности можно использовать функционал журнала событий безопасности (см. папку security_events_logger) - при обнаружении нарушения политик безопасности монитор безопасности отправляет событие в топик security_events_logger (см. monitor/consumer.py), в коде теста можно подписаться на этот топик и также получать события безопасности от монитора.

  1. Все негативные сценарии должны отрабатывать автоматически без ошибок при выполнении команды make test

  2. Обновить отчёт, добавив описание негативных сценариев и скриншот с результатами тестирования.

  3. Код выложить в свой репозиторий на github, прислать ссылку на него на общий email [email protected] с темой "результаты производственной практики" или своему куратору в телеграм.

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

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

Альтернатива - тестирование политик безопасности в отрыве от остальных сущностей. По сути, это юнит-тестирование, только для тестов выбираются отдельные политики.

Задача для этой производственной практики - для политик безопасности примера КУМО разработать инфраструктуру и автотесты, в рамках которых монитор безопасности будет получать различные события, а его реакция будет проверяться сценарием теста.

Следует также использовать журнал событий безопасности.

Описание технических шагов можно взять из предыдущей задачи (взять репозиторий, выбрать ветку, описать сценарии тестирования, написать код тестов, добавить отчёт о тестировании в report.md, выложить результаты на github, прислать куратору).

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

Создание программы для обнаружения повышенного радиационного фона в трубах с паром на атомной электростанции (трек 1)

https://docs.google.com/document/d/1jGcTPig1JxLI4-1-imdwceAAB6g8KdGHe0woxc3i-PI/edit?usp=sharing

Создание программы для управления оборудованием на теплоэлектростанции (трек 2)

https://docs.google.com/document/d/1vCJ7SYEE_RtH5yRu8uCPyVw7u2rM1DoqlUKOkmXxuQI/edit?usp=sharing

Что требуется для зачёта

Публичный репозиторий на github, в котором должны быть:

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