Антифрод-платформа для защиты несовершеннолетних в ВКР: от матрицы MITRE ATT&CK до метрик ISO/IEC 25010
В конце марта 2026 года компания F6 — российский разработчик технологий борьбы с киберугрозами — опубликовала данные о том, что за 2025 год через атаки на детей злоумышленники похитили более 1 млрд рублей. Речь не о классическом «маме, я попал в беду»: схема эволюционировала в сторону игровых платформ, фейковых блогеров и микро-платежей, которые не ловятся банковскими антифродами. Для выпускника направления «Информационная безопасность» или «Прикладная информатика» это не просто новость, а готовое обоснование актуальности: рынок защиты детских цифровых сервисов фактически формируется на глазах, а значит — есть ниша и для дипломного проекта с реальной архитектурой, а не с пересказом учебника.
Четыре темы ВКР, которые вырастают из этого кейса
Тема 1. Проектирование антифрод-платформы для детских аккаунтов на базе SIEM-контура
Актуальность. Классические банковские антифрод-системы рассчитаны на крупные транзакции. Схемы против детей дробятся на десятки мелких списаний внутри игровых экосистем и маркетплейсов — их нужно ловить на уровне поведенческих признаков, а не пороговых сумм.
Цель: разработать архитектуру платформы, которая в реальном времени выявляет аномалии в сессиях несовершеннолетних пользователей.
- проанализировать схемы из отчёта F6 и построить их формализованную таксономию;
- обосновать стек (брокер событий, потоковый обработчик, ML-инференс, хранилище);
- спроектировать пайплайн сбора и обогащения событий;
- провести испытания на синтетическом датасете и рассчитать Precision, Recall, F1, FPR.
Структура. Глава 1 — анализ предметной области, обзор ГОСТ 34.602-89 и MITRE ATT&CK. Глава 2 — архитектура и алгоритмы детекции. Глава 3 — испытания, метрики качества и оценка стоимости внедрения.
Тема 2. Поведенческая биометрия для детских аккаунтов: детекция вовлечения в схему
Актуальность. F6 прямо указывает на сдвиг от кражи аккаунта к вовлечению ребёнка в действие «добровольно». Технически это означает аномалию не разового платежа, а последовательности: новое устройство → подписка на канал → серия мелких переводов.
Цель: разработать алгоритм поведенческой биометрии, устойчивый к «прогреву» жертвы.
- выделить признаки (тайминги, энтропия ввода, паттерн навигации);
- обучить модель и оценить её устойчивость к шуму;
- интегрировать сервис через OpenTelemetry для наблюдаемости;
- сравнить с базовым правиловым детектором и показать прирост метрик.
Тема 3. Приватность-сохраняющая система родительского контроля на федеративном обучении
Актуальность. Обработка данных несовершеннолетних ограничена 152-ФЗ, поэтому централизованный сбор телеметрии — юридически рискованное решение. Кейс с миллиардными потерями делает такие проекты востребованными у операторов и разработчиков игровых сервисов.
Цель: спроектировать платформу, обучающую модель локально на устройствах, без выгрузки персональных данных.
- построить модель угроз и определить границы доверия;
- реализовать цикл федеративного обучения с безопасной агрегацией;
- оценить деградацию качества по сравнению с централизованным обучением;
- описать соответствие ISO/IEC 25010 по характеристикам защищённости.
Тема 4. Матрица социально-инженерных атак на несовершеннолетних и SOAR-плейбуки реагирования
Актуальность. Отчёт фиксирует адаптацию схем, то есть злоумышленники меняют тактики — значит нужна не разовая модель, а воспроизводимая матрица техник и автоматизированные сценарии реагирования.
Цель: разработать методику описания и автоматизации реагирования на такие атаки.
- адаптировать MITRE ATT&CK под детскую аудиторию;
- описать 10–15 техник с индикаторами компрометации;
- спроектировать SOAR-плейбуки и рассчитать RTO/RPO;
- провести настольное учение (tabletop exercise) и зафиксировать MTTD/MTTR.
Аналитическая глава: как встроить кейс F6 в обоснование
Здесь не нужно переписывать новость. Нужно превратить её в таблицу сравнения решений. Покажите, что существующие подходы (правила, сигнатуры, банковский антифрод) не покрывают угрозу, и обоснуйте выбор своего стека через требования.
| Подход | Покрывает схемы против детей? | Плюсы | Ограничения |
|---|---|---|---|
| Правиловые сигнатуры | Частично | Простота, предсказуемость | Обходится сменой схемы |
| Банковский антифрод | Нет | Отлажен, есть исторические данные | Пороговые суммы не работают на микро-платежах |
| ML-классификатор транзакций | Да, при добавлении признаков | Ловит нетипичные паттерны | Требует разметки и мониторинга дрейфа |
| Поведенческая аналитика сессий | Да | Видит вовлечение, а не только платёж | Сложнее в интеграции, чувствительна к шуму |
В подраздел с обоснованием стека вставьте сравнительную таблицу с версиями и лицензиями: это то, что проверяющий оценит как зрелость проектного решения.
Проектная часть: схемы, алгоритмы, точки интеграции
Логичный каркас для второй главы: источник событий → брокер → потоковый обработчик → сервис признаков → модель → хранилище → система реагирования. Каждый переход подкрепляйте обоснованием: почему именно этот транспорт, почему такая гарантия доставки, что происходит при отказе узла.
Для раздела «форматы данных» удобно показать конкретную схему события — это снижает вопросы к проработанности:
{
"event_id": "uuid",
"ts": "2026-03-26T10:15:22Z",
"actor": { "user_id": "hash", "age_bucket": "10-14", "device_hash": "..." },
"session": { "duration_s": 1840, "entropy": 1.7, "new_device": true },
"payment": { "amount": 49, "currency": "RUB", "merchant_category": "game_currency" },
"signal_bundle": { "social_ref": "channel_new", "velocity_5m": 4 }
}Испытания и метрики: третья глава без «воды»
Самая частая слабость диплома — отсутствие измеримых результатов. Соотнесите качества системы с ISO/IEC 25010 и закройте каждое требование конкретной метрикой.
| Что оцениваем | Метрика | Целевое значение |
|---|---|---|
| Качество детекции | Precision / Recall / F1 | ≥ 0,85 / ≥ 0,75 / ≥ 0,8 |
| Ложные тревоги | FPR на 100k событий | ≤ 200 |
| Производительность | Задержка инференса p95 | ≤ 300 мс |
| Отказоустойчивость | RTO / RPO | ≤ 15 мин / ≤ 1 мин |
| Наблюдаемость | MTTD / MTTR | ≤ 5 мин / ≤ 30 мин |
Для нагрузочного тестирования опишите методику: генератор событий, набор сценариев, длительность, точки насыщения. Отдельно зафиксируйте дрейф качества модели на «сдвинутых» данных — это показывает понимание реальной эксплуатации, а не лабораторного идеала.
Что вы реально освоите в процессе
- проектирование отказоустойчивых потоковых архитектур и обоснование выбора компонентов;
- работу с матрицей MITRE ATT&CK как инструментом описания угроз, а не постером на стену;
- построение контуров наблюдаемости через OpenTelemetry и метрики прометеевского типа;
- оформление технической документации по ГОСТ 34.602-89 и ГОСТ 19.201-78;
- экономическое обоснование внедрения: CAPEX/OPEX, срок окупаемости, оценка предотвращённого ущерба.
Типичные ошибки, которые замечают на защите
- Подмена терминов SaaS/PaaS/IaaS без обоснования. Модель развёртывания — это решение с последствиями для ИБ и бюджета. Если пишете «развернём в облаке», объясните, почему не on-premise и как это влияет на обработку данных несовершеннолетних.
- Отсутствие метрик эффективности. Формулировка «система работает быстрее» не защищается. Нужны числа, методика замера и условия, в которых они получены.
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Отсутствие разделов «Требования к системе», «Стадии и этапы» и «Порядок контроля и приёмки» — почти гарантированные замечания нормоконтроля.
- Работа с данными детей без этической рамки. Даже на синтетике стоит указать, какие меры анонимизации применены и почему.
Чему уделить внимание в первую очередь
Чек-лист перед сдачей
- каждая задача из введения имеет отражение в выводах по главам;
- есть ссылка на источник статистики с датой публикации;
- присутствуют минимум три схемы: контекстная, компонентная, диаграмма последовательности;
- все таблицы и рисунки пронумерованы и упомянуты в тексте;
- оформление титула и разделов проверено на соответствие ГОСТ 7.32-2017;
- список литературы содержит актуальные нормативные документы, а не только учебники 2010-х.
Частые вопросы студентов
Насколько сложно реализовать антифрод-платформу в рамках диплома?
Полноценная промышленная платформа — задача на команду. Для ВКР достаточно прототипа: один поток событий, одна модель, один контур реагирования. Сократите объём до демонстрируемого сценария и опишите расширение как направление развития.
Обязательно ли писать код?
Зависит от кафедры. Там, где ВКР считается исследовательской, допускается прототип на Python в несколько сотен строк. Если тема проектная — код нужен, но не весь: достаточно ядра детекции, схемы данных и скриптов испытаний. Помните, что как написать ВКР технического профиля без работоспособного артефакта сложно защитить убедительно.
Где брать тестовые данные, если реальная телеметрия закрыта?
Три пути: публичные наборы по фрод-детекции, генерация синтетических сессий по описанным в отчёте сценариям и ручная разметка небольшой выборки. Обязательно укажите ограничения синтетики и то, как это влияет на достоверность метрик.
Как оформлять UML-диаграммы и архитектурные схемы?
Единого ГОСТ на UML нет, поэтому ориентируйтесь на ГОСТ 19.701-90 для схем алгоритмов и на общепринятую нотацию UML 2.5 для остального. Главное — единообразие: если начали рисовать C4, рисуйте весь проект в C4.
Практический итог
Кейс с миллиардными потерями через атаки на детей даёт три вещи: обоснование актуальности, постановку задачи и понятную целевую аудиторию системы. Дальше всё решает инженерная дисциплина — метрики, схемы, обоснование стека и корректное оформление. Если чувствуете, что проектной части не хватает времени, всегда можно обратиться за помощью с дипломом — но даже в этом случае каркас должен оставаться вашим.
На разработку одной темы у нашей команды уходит в среднем 120 часов: архитектура, прототип, испытания и текстовая часть. Первая консультация — бесплатная: разберём вашу тему, покажем риски и предложим план. Работаем с любыми направлениями — от ИБ до анализа данных. Оставьте заявку, чтобы обсудить детали.
Источник: В 2025 г. мошенники похитили через атаки на детей более 1 млрд рублей (опубликовано 2026-03-26)