Анализ закрытия хак-форума LeakBase для ВКР по ИБ: от модели угроз до правил в SIEM
В марте 2026 года российские правоохранители задержали 33-летнего жителя Таганрога, которого считают администратором хак-форума LeakBase. Ресурс был закрыт в ходе международной операции. Для выпускника направления «Информационная безопасность» это не просто новость: это готовый сценарий для постановки задач в дипломной работе, где теория встречается с реальной инфраструктурой киберпреступности.
Почему это важно именно сейчас? Потому что комиссии надоели абстрактные работы про «защиту информации на предприятии». А вот исследование, в котором вы моделируете угрозы по MITRE ATT&CK, описываете архитектуру теневого маркетплейса утечек и предлагаете конкретные правила детектирования — это уже разговор уровня собеседования на позицию в SOC.
Как превратить новость в три защищаемые темы ВКР
Разберём три направления, каждое из которых закрывает свою часть связки «анализ → проектирование → оценка эффективности». Все они опираются на один факт: крупный узел криминального рынка данных ликвидирован, а значит, потоки утечек будут перераспределяться по мелким площадкам — и это измеримое изменение ландшафта угроз.
| Тема ВКР | Цель | Задачи | Структура |
|---|---|---|---|
| Разработка модели угроз и системы мониторинга утечек учётных данных на базе threat intelligence | Снизить время обнаружения скомпрометированных учётных записей организации | 1) Классифицировать источники утечек; 2) Построить модель нарушителя; 3) Спроектировать конвейер обогащения индикаторов; 4) Оценить полноту детектирования | Гл. 1 — анализ рынка утечек и нормативной базы; Гл. 2 — архитектура конвейера и правила корреляции; Гл. 3 — эксперимент и метрики |
| Проектирование SIEM-контура для выявления признаков credential stuffing | Автоматизировать выявление атак с использованием утекших паролей | 1) Описать жизненный цикл компрометации; 2) Сформировать требования по ISO/IEC 27001; 3) Реализовать Sigma-правила; 4) Замерить FP/FN | Гл. 1 — теория и стандарты; Гл. 2 — логическая и физическая схема по ГОСТ 34; Гл. 3 — стенд и результаты |
| Оценка эффективности риск-ориентированного подхода к защите персональных данных | Показать, как смена ландшафта угроз влияет на остаточный риск | 1) Построить реестр активов; 2) Рассчитать риск по NIST CSF; 3) Смоделировать сценарии «до/после»; 4) Дать рекомендации | Гл. 1 — обзор подходов; Гл. 2 — методика расчёта; Гл. 3 — расчёты и чувствительность модели |
Глава 1: что именно писать про LeakBase
Не пересказывайте новость. В аналитической главе нужна типология. Опишите теневой рынок данных как экосистему с ролями: поставщик (инсайдер или эксплуатация уязвимости), брокер, покупатель. Покажите, что закрытие одного форума — это не устранение рынка, а его фрагментация, которая усложняет мониторинг, но упрощает задачу атакующих за счёт децентрализации.
Здесь уместно наложить сценарий на матрицу MITRE ATT&CK: этапы Initial Access, Credential Access, Exfiltration. Схему можно оформить как диаграмму последовательности (UML) или как контекстную диаграмму C4 уровня System Context: организация — её сервисы — внешняя среда угроз. Ниже — ASCII-вариант потока, который легко перерисовать в Visio или draw.io.
Источники утечек Нормализация Обогащение Потребители
[ форумы / пастбины ] --> [ парсинг, ] --> [ сверка с ] --> [ SIEM: корреляция ]
[ публичные бреши ] [ дедупликация ] [ AD/LDAP ] [ DLP: блокировка ]
[ dark web фиды ] [ hash-БД ] [ SOC: инцидент ]
|
[ реестр активов ]
Дальше — нормативная привязка. Не выдумывайте стандарты: ISO/IEC 27001 в части управления инцидентами и соответствия требованиям, NIST CSF в части функций Identify/Detect/Respond, ГОСТ 34.601 и 34.602 — для стадий создания системы и технического задания. Именно ГОСТ 34 чаще всего требует нормоконтроль, когда вы описываете автоматизированную систему мониторинга.
Глава 2: от схемы к рабочему артефакту
Самая частая претензия комиссии: «где реализация?». Реализация не обязана быть монолитной системой. Достаточно воспроизводимого стенда: коллектор логов, нормализатор, хранилище индикаторов, движок правил. Разверните это в Docker Compose, добавьте один-два источника событий (например, журналы аутентификации) и напишите правила детектирования.
Практичный формат правила — Sigma, потому что он переносится между SIEM и хорошо читается в приложении к диплому. Пример ниже ловит всплеск неуспешных входов с последующим успехом — типичный след credential stuffing после публикации базы.
title: Подозрение на credential stuffing после утечки
id: 8f2c-4a10-leakbase-demo
status: experimental
description: Множественные неуспешные входы с одного IP, затем успех
logsource:
product: windows
service: security
detection:
selection_fail:
EventID: 4625
selection_success:
EventID: 4624
timeframe: 10m
condition: selection_fail | count() by SourceIp > 20 and selection_success
level: high
tags:
- attack.credential_access
- attack.t1110
Глава 3: какие метрики считать, чтобы не получить «воду»
Эффективность системы ИБ измеряется не количеством строк кода. Зафиксируйте четыре величины: время обнаружения (MTTD), долю ложных срабатываний (FP rate), полноту детектирования (доля воспроизведённых сценариев, которые правило поймало) и стоимость владения (TCO) на этапе пилота. Сравнивайте «до» и «после»: например, ручной мониторинг давал MTTD около 8 часов, а корреляция в SIEM снизила его до 15 минут на тестовом наборе.
Для расчёта риска используйте качественно-количественную шкалу из NIST CSF или собственную матрицу «вероятность × ущерб». Обязательно приложите исходные данные с допущениями — комиссия любит проверять чувствительность модели. И держите в голове юридическую рамку: все данные для эксперимента берите из открытых источников, собственных тестовых баз или синтетических наборов. Работа с реальными утекшими базами — это уже не диплом, а статья.
FAQ
Где брать данные, если реальные утечки использовать нельзя?
Три легальных пути: синтетические наборы (генерация через Faker), публичные исследовательские датасеты по утечкам, собственные логи тестового стенда. Плюс открытые фиды индикаторов компрометации и материалы отчётов об инцидентах. Этого достаточно для полноценного эксперимента.
Нужен ли код в дипломе по ИБ?
Да, если тема заявлена как «разработка» или «проектирование системы». Минимальный набор: конфигурация стенда, одно-два правила детектирования, скрипт обогащения индикаторов. Всё остальное — в приложения.
Как оформить схемы, чтобы прошёл нормоконтроль?
Логическую и физическую структуру — по ГОСТ 34.602. Диаграммы взаимодействия — UML или BPMN, с подписью «Рисунок N — …» и ссылкой в тексте до появления рисунка. Проверьте единообразие обозначений на всех схемах.
Можно ли взять готовую тему и не изобретать свою?
Можно, но её придётся адаптировать под свой объект исследования и под свои метрики. Если времени мало — разумнее взять тему с понятным стендом и измеримым результатом, чем гнаться за оригинальностью без данных.
- Задачи из введения дословно совпадают с выводами по главам.
- Все нормативные ссылки реальны: ГОСТ 34.601, ISO/IEC 27001, NIST CSF, MITRE ATT&CK.
- Схемы пронумерованы, подписаны и упомянуты в тексте.
- Метрики (MTTD, FP rate, полнота детектирования) имеют исходные данные и методику расчёта.
- Код вынесен в приложения, а в тексте — только ключевые фрагменты.
- Проверка на уникальность пройдена с запасом, список литературы оформлен по ГОСТ Р 7.0.5.
- Юридическая чистота: ни одной реальной утекшей базы в приложениях.
1. Пересказ новости вместо анализа. Комиссия мгновенно видит компиляцию из СМИ. Нужна типология, модель нарушителя, измеримые выводы — LeakBase здесь только триггер, а не содержание.
2. Отсутствие метрик. «Система повышает безопасность» — не результат. Без MTTD, FP rate и полноты детектирования защита превращается в разговор о намерениях.
3. Серая зона по закону. Скачивание реальных баз для «тестирования» — прямой путь к проблемам. Стройте эксперимент на синтетике и открытых фидах; в тексте явно зафиксируйте источники данных.
Источник: В России арестован администратор хак-форума LeakBase (опубликовано 2026-03-26)
``` Если нужно — могу адаптировать эту же статью под другой поддомен (например, Data Engineering: конвейеры обработки индикаторов компрометации) или заменить Sigma-правило на YARA/Suricata под вашу конкретную тему ВКР.