Supply chain атаки в ВКР по кибербезопасности: разбор CanisterWorm и защита облачной инфраструктуры

Статья KrebsOnSecurity рассказала, как группировка TeamPCP использовала цепочку поставок и незащищённые облачные контроль-плоскости: скомпрометировала официальный репозиторий Trivy на GitHub Actions, затем запустила червя CanisterWorm, который стирал данные при обнаружении иранской локали. Для студента ИТ-специальности это не просто новость, а полноценный учебный кейс: здесь есть и supply chain атака, и эксплуатация Docker/Kubernetes, и криминалистический анализ с временными метками. Такой материал позволяет сделать ВКР современной, практической и защищаемой. Ниже — как именно превратить этот инцидент в тему диплома, не скатываясь в пересказ статьи.

ВКР по следам CanisterWorm: три актуальных направления

Выбирать тему стоит не «по красивой картинке», а по возможности провести самостоятельное исследование и получить измеримые результаты. Статья об атаке TeamPCP легко разворачивается в три разные работы. Сведём их в таблицу, чтобы вы могли прикинуть объём и структуру.

Параметр Тема 1. Обнаружение wiper-атак в Kubernetes Тема 2. Защита цепочки поставок ПО Тема 3. Анализ угроз для неструктурированных облачных конфигураций
Актуальность CanisterWorm уничтожает данные на каждом узле кластера. Штатные средства не всегда отличают массовое удаление от штатной очистки. Инцидент с Trivy показал: атакующие внедряют код в официальные артефакты. Нужны методы верификации и контроля целостности. TeamPCP промышленно сканирует Docker API, Redis, Kubernetes. Тема закрывает пробел между найденной уязвимостью и реальной компрометацией.
Цель ВКР Разработать систему раннего детектирования признаков wiper-нагрузки на основе поведения подов. Спроектировать процесс безопасной публикации open-source компонентов с проверкой provenance. Создать инструмент оценки Cloud Security Posture для типовых конфигураций.
Задачи 1) Изучить артефакты CanisterWorm и похожих семейств.
2) Спроектировать механизм сбора событий из Kubernetes API.
3) Реализовать алгоритм аномалий на основе частоты delete-операций.
4) Оценить точность на синтетических нагрузках.
1) Классифицировать атаки на GitHub Actions.
2) Внедрить подпись артефактов cosign.
3) Разработать политику сканирования образов до публикации.
4) Провести ретроспективу инцидента с Trivy.
1) Описать модель нарушителя по MITRE ATT&CK.
2) Собрать датасет небезопасных конфигураций.
3) Разработать правила для OPA/Gatekeeper.
4) Сравнить с OWASP Kubernetes Top 10.
Структура работы Глава 1 — анализ wiper-атак; Глава 2 — проектирование модуля детекта; Глава 3 — эксперимент и метрики. Глава 1 — обзор supply chain инцидентов; Глава 2 — реализация пайплайна с cosign и SLSA; Глава 3 — оценка стоимости внедрения. Глава 1 — теория и стандарты ISO/IEC 25010; Глава 2 — архитектура сканера; Глава 3 — тестирование на стенде.

Обратите внимание: в любой из тем вы не просто «изучаете статью», а опираетесь на фактуру из неё как на один из источников, дополняя её официальными отчётами Flare, Wiz, Aikido и собственными экспериментами.

Глава 1: кладите инцидент в основу аналитики

В первой главе нужно показать, что вы понимаете ландшафт угроз, а не пересказываете Википедию. Возьмите за отправную точку цепочку атаки TeamPCP:

Такая последовательность превращается в формализованную модель нарушителя. Используйте фреймворки ATT&CK и OWASP Application Security Verification Standard — это поднимет уровень работы и покажет навык применения стандартов. Для схемы хорошо подойдёт C4 или обычная UML-диаграмма последовательности. Не рисуйте общую картинку из интернета: постройте свою, с actor’ом “TeamPCP” и компонентами “Docker API”, “Trivy repository”.

Глава 2: проектируйте защиту, а не набор скриптов

Когда дойдёте до проектирования, имейте в виду: одна из причин успеха TeamPCP — автоматизация поиска暴露的控制平面. Значит, ваша работа должна включать компонент постоянного аудита. Если тема связана с Kubernetes, можно предложить набор политик на основе Open Policy Agent. Вот фрагмент правила, которое блокирует контейнер с привилегированным режимом — это прямо относится к защите от компрометации узла.

package kubernetes.admission

deny[msg] {
    input.request.kind.kind == "Pod"
    some c in input.request.object.spec.containers
    c.securityContext.privileged == true
    msg := sprintf("Privileged container '%s' is not allowed", [c.name])
}

deny[msg] {
    input.request.kind.kind == "Pod"
    some c in input.request.object.spec.containers
    c.image starts with "docker.io/library/redis"
    not c.securityContext.readOnlyRootFilesystem
    msg := sprintf("Redis container '%s' must have read-only root filesystem", [c.name])
}

Этот код легко вставить в главу 2 в качестве экспериментальной части реализации. Но обязательно дополните его пояснением: как именно он противодействует технике TeamPCP? Например, запрет privileged-контейнеров снижает риск вертикальной эскалации, а read-only root filesystem мешает перезаписать бинарные файлы.

Глава 3: метрики и воспроизводимый эксперимент

Чтобы защита не была голословной, нужно сравнить «до/после» и посчитать метрики. Для системы детектирования аномалий используйте:

В качестве стенда можно взять Kind или minikube, сгенерировать синтетический «wiper-под», который вызывает RemovePod, RemoveDeployment и удаляет PVC. Замерьте, как быстро ваш модуль среагирует. Затем постройте графики. Такой раздел выглядит сильно на защите, потому что демонстрирует инженерную, а не только литературную работу.

Чему вы научитесь в таком проекте

Работа над ВКР по мотивам CanisterWorm принесёт конкретные навыки, которые потом можно показать на собеседовании:

Частые вопросы перед сдачей

Не слишком ли сложная тема для бакалаврской работы?

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

Где брать данные для анализа?

Используйте публичные отчёты Flare, Wiz, Aikido, дампы IOC от исследователей. Важно сослаться на них, а не переписывать текст. Для эксперимента данные можно сгенерировать самим — это даже плюс: работа становится воспроизводимой.

Как оформить схемы, чтобы не потерять баллы на нормоконтроле?

Делайте схемы в UML и называйте элементы по стандарту. Если в вузе требуют IDEF0 или BPMN — уточните на кафедре, но для ИТ-специальности обычно подходит UML. Подпишите каждую стрелку и движение данных.

Какие стандарты упоминать?

Если это безопасность — корректно ссылаться на ISO/IEC 27001, OWASP ASVS, NIST SP 800-53. Если говорите о качестве архитектуры — ISO/IEC 25010. Не выдумывайте номера и не применяйте стандарты «для красоты»; каждый должен соответствовать цели раздела.

Типичные ошибки студентов

Ошибка 1. Пересказ статьи вместо аналитики. «CanisterWorm распространяется через Docker API, атака началась 19 марта…» — это компиляция, а не исследование. Как избежать: выделите сценарий атаки, постройте свою классификацию, сравните с другими семействами.

Ошибка 2. Отсутствие эксперимента. Работа о защите Kubernetes, но нет ни одного кода, ни одного замера. В результате это реферат. Даже простой скрипт имитации атаки и замер времени реакции добавят практической ценности.

Ошибка 3. Игнорирование поставщика облачной услуги. TeamPCP атаковал Azure и AWS — значит, в работе должны быть учтены native-инструменты: GuardDuty, Defender for Cloud, а также кроссплатформенные решения. Не ограничивайтесь только open-source.

Что проверить перед сдачей

  • Поставлена ли цель, и коррелирует ли она с каждой главой?
  • Закрыты ли все задачи из введения выводами по главам?
  • Есть ли собственная схема архитектуры (UML/C4), а не скриншот из статьи?
  • Соответствуют ли метрики того, что вы обещали измерить?
  • Проверены ли ссылки на источники и по стандарту вашего вуза?
  • Есть ли приложение с листингом кода и результатами тестов?
  • Уникальность текста действительно ваша, а не пересказ аналитики?

История с CanisterWorm — отличный повод показать преподавателю, что вы ориентируетесь в актуальных угрозах, умеете проектировать защитные механизмы и доводите их до измерения. Берите одну из трёх тем или предложите кафедре свою — но обязательно с фокусом на практическую реализацию.

Если вы чувствуете, что не успеваете собрать стенд или оформить главу с метриками, помните: специалисты нашего сервиса помогают с дипломом в сжатые сроки. Мы разбираемся в Kubernetes, облачных провайдерах и стандартах. Первая консультация — бесплатно, а на проработку темы уходит от 120 часов. Напишите нам, чтобы согласовать план работ.

Материал подготовлен экспертами компании «Диплом-ИТ». Мы помогаем студентам с 2010 года: от выбора темы до автоматической проверки на антиплагиат. Если вам нужна помощь в разработке ВКР по кибербезопасности, облачной архитектуре или Data Engineering — наши специалисты готовы подсказать оптимальное решение.

Последнее обновление: 2026-09-05

Источник: ‘CanisterWorm’ Springs Wiper Attack Targeting Iran (опубликовано 2026-03-23)