Угрозы коммерческого шпионского ПО в ВКР по кибербезопасности: от MITRE ATT&CK до защиты мобильных ОС
25 марта 2026 года TechCrunch опубликовал материал, в котором основатель компании Intellexa фактически подтвердил: десятки телефонов греческих министров, военных, журналистов и лидеров оппозиции были взломаны при участии государственных структур. Это не абстрактный сюжет из «шпионских фильмов», а публичное признание участника рынка коммерческой слежки — рынка, который работает как легальный B2G-бизнес. Для выпускника ИТ-направления это конкретный технический сигнал: классические модели угроз «снаружи периметра» устарели. Атакующий может быть не хакером из подвала, а поставщиком «законного» решения с эксплойтом нулевого дня. Разберём, как этот кейс превратить в защищаемую ВКР — с архитектурой, метриками и обоснованием стека.
Три темы ВКР, которые «вырастают» из этой новости
Тема 1. Моделирование угроз мобильных ОС на основе MITRE ATT&CK Mobile
Актуальность: кейс Intellexa показывает, что поставщик spyware действует в серой зоне: формально легально, фактически — как APT-группа. Студент получает редкую возможность анализировать реальный, публично подтверждённый вектор.
Цель: разработать матрицу техник атак на Android/iOS и предложить архитектуру детектирования для корпоративного MDM.
Задачи:
- составить карту соответствия техник ATT&CK Mobile и сигнатур известных spyware-семейств;
- спроектировать модуль поведенческого анализа на стороне устройства;
- провести нагрузочное тестирование и оценить FPR/FNR;
- рассчитать трудозатраты и TCO внедрения.
Структура: Глава 1 — анализ рынка коммерческой слежки и модели угроз; Глава 2 — архитектура решения (схемы в нотации UML и C4); Глава 3 — эксперименты, метрики, экономика внедрения.
Тема 2. SIEM-система для детектирования аномалий в мобильном трафике
Актуальность: взлом телефонов высокопоставленных лиц означает, что традиционный perimetr-based SIEM не видит угрозу — нужен мониторинг на уровне endpoint и DNS.
Цель: спроектировать SIEM-контур для мобильных устройств и оценить его по ISO/IEC 25010.
Задачи: разработать правила корреляции; собрать телеметрию через OpenTelemetry; развернуть стенд в Kubernetes; измерить RTO/RPO.
Структура: Глава 1 — обзор SIEM-решений и требований ФСТЭК; Глава 2 — проектирование пайплайна данных; Глава 3 — тестирование и оценка качества.
Тема 3. Архитектура защищённого канала управления MDM-агентом
Актуальность: spyware часто внедряется через легитимные механизмы обновления. Значит, аутентификация агента — критическая точка.
Цель: реализовать схему mTLS + аттестация устройства для MDM-агента и обосновать её устойчивость.
Задачи: сравнить mTLS, JWT и SPIFFE; спроектировать протокол; реализовать прототип; провести fuzzing-тестирование.
Структура: Глава 1 — стандарты и ГОСТ 34.602-89 (ТЗ); Глава 2 — архитектура и интеграция; Глава 3 — тесты и безопасность.
| Тема ВКР | Стек | Ключевые метрики | Норматив |
|---|---|---|---|
| ATT&CK Mobile-модель | Python, Elastic, Suricata | FPR, FNR, охват техник | ГОСТ Р 59548-2022 |
| SIEM для мобильных | Kafka, OpenSearch, Kubernetes | RTO, RPO, MTTD, MTTR | ISO/IEC 25010 |
| mTLS-канал MDM | Go, SPIFFE, OpenTelemetry | Latency p95,成功率 аутентификации | NIST SP 800-53 |
Аналитическая глава: как использовать материал статьи
Не пересказывайте новость — это ошибка №1. В первой главе нужен сравнительный анализ. Возьмите три-четыре коммерческих spyware-платформы (Pegasus, Predator, Intellexa-семейство) и сведите в таблицу: вектор доставки, использование нулевых дней, наличие публичных индикаторов компрометации. Опирайтесь на отчёты Threat Intelligence и на текст TechCrunch как первоисточник факта о госконтракте.
Обоснование выбора стека
Рекомендую в подразделе «Обоснование технологий» явно разделять уровни: сбора телеметрии (OpenTelemetry), транспорта (mTLS, Kafka), хранения (OpenSearch), оркестрации (Kubernetes). Каждое решение — минимум один источник или стандарт: ГОСТ, RFC, ISO. Иначе комиссия спросит: «почему не обратный подход?» — а ответа не будет.
Проектная часть: схемы и интеграция
На этапе проектирования обязательно приложите три диаграммы: контекстную (C4 Level 1), диаграмму компонентов и диаграмму последовательности аутентификации MDM-агента. UML-диаграммы оформите по правилам, а «шапку» ТЗ — строго по ГОСТ 34.602-89. В тексте главы покажите, как принятая архитектура мешает конкретной технике из кейса Intellexa (например, перехвату push-сообщений).
// пример проверки аттестации устройства (псевдокод)
if (!attestation.verify(agent.hardwareKey)) {
audit.log("suspicious_agent", agent.id);
return deny();
}
Тестирование, метрики и мониторинг
Здесь статья работает как «поставщик» реалистичных угроз. Смоделируйте сценарий: скомпрометированный агент пытается установить канал управления. Замерьте:
- MTTD — среднее время обнаружения (цель: < 5 мин);
- FPR/FNR — ложноположительные/ложноотрицательные срабатывания;
- RTO/RPO — восстановление после сбоя SIEM-контура;
- Latency p95 — для канала mTLS.
Метрики сравнивайте с целевыми из ТЗ — это закрывает вопрос «а вы вообще измеряли?»
Чему вы научитесь на такой работе
- Строить модель угроз на реальных инцидентах, а не на учебных примерах;
- Обосновывать стек ссылками на стандарты, а не «потому что модно»;
- Проектировать отказоустойчивую архитектуру с метриками RTO/RPO;
- Оформлять ТЗ, UML и схемы в соответствии с ГОСТ и ISO/IEC 25010;
- Защищать решения перед комиссией на языке инженерных компромиссов.
- Подмена SaaS/PaaS/IaaS без обоснования. Комиссия ловит моментально. Пишите, что именно вы разворачиваете и почему.
- Отсутствие метрик эффективности. «Система работает» — не аргумент. Нужны MTTD, FPR, RTO/RPO.
- Игнорирование ГОСТ 34.602-89. ТЗ без структурных разделов — половина оценки минус.
Частые вопросы студентов
Обязательно ли писать код в ВКР по кибербезопасности?
Нет, но прототип усиливает защиту. Достаточно рабочего демо на стенде — даже частичного. Полностью «теоретические» работы защищать сложнее, особенно если тема связана с архитектурой.
Где взять данные для экспериментов?
Используйте публичные датасеты (CIC-IDS, AndroZoo), логи собственного стенда, синтетические данные через MITRE Caldera или Atomic Red Team. Кейс Intellexa даёт готовый сценарий угрозы — не нужен доступ к реальному spyware.
Как оформлять UML и C4-диаграммы?
UML — по ISO/IEC 19505, «шапка» ТЗ — по ГОСТ 34.602-89. C4 — как дополнительная нотация, обязательно с легендой и обозначением границ доверия.
Насколько глубоко нужно знать Kubernetes, если тема не про него?
Достаточно уровня «развернул стенд, описал манифесты, обосновал выбор». Диплом — не курс по K8s, но архитектурная грамотность приветствуется.
- Ссылка на оригинал TechCrunch указана и корректно оформлена;
- Задачи соответствуют выводам — проверьте попунктно;
- Есть UML-схемы, C4, диаграммы последовательности;
- ТЗ оформлено по ГОСТ 34.602-89;
- Метрики (RTO/RPO, MTTD, FPR) сведены в таблицу с целевыми значениями;
- Список литературы включает ГОСТ, ISO/IEC 25010, MITRE ATT&CK.
Источник: Convicted spyware chief hints that Greece’s government was behind dozens of phone hacks (опубликовано 2026-03-25)
```