Опубликовано: 17.09.2026 | Источник: SecurityLab (RSS)

Единая система управления ИБ в ВКР: от SIEM и MITRE ATT&CK до метрик MTTD/MTTR

Поддомен: Cybersecurity. Роль автора: специалист по информационной безопасности, архитектор SOC.

Почему один вебинар про «объединяй и властвуй» стоит дороже трёх глав учебника

Анонс вебинара SECURITM звучит почти как рекламный слоган: «одна система закрывает буквально все ИБ-потребности». За формулировкой стоит вполне инженерная мысль — консолидация разрозненных средств защиты в единый контур управления: сбор событий, корреляция, реагирование, отчётность. Для выпускника это не маркетинг, а готовая постановка задачи для ВКР. Вместо расплывчатого «исследовать кибербезопасность» вы получаете измеримый объект: единая платформа управления ИБ и её эффект на время обнаружения и реакции на инцидент.

Что это даёт на защите? Комиссия любит, когда студент говорит не «я изучил литературу», а «я собрал стенд, воспроизвёл атаку, замерил MTTD до и после внедрения корреляции». Именно так тема из новости превращается в защищаемую работу с цифрами и архитектурными схемами.

FAQ: что спрашивают студенты до первой консультации

Где брать данные для экспериментов, если нет доступа к реальному SOC?

Собирайте тестовый полигон: Wazuh или Elastic Stack + Security Onion в виртуальных машинах, генерация событий через Atomic Red Team (эмуляция техник MITRE ATT&CK). Также подходят публичные датасеты — CICIDS2017, Loghub, BOTS. Этого достаточно для главы 3 с расчётом метрик.

Какой стек выбрать, чтобы не утонуть в настройке?

Для экономии времени: Wazuh (агенты + правила корреляции + встроенный Active Response) либо Elastic Security. Тяжёлые коммерческие SIEM в диплом брать рискованно — нет лицензий и воспроизводимости стенда.

Как считать эффективность, чтобы цифры не выглядели выдуманными?

Фиксируйте методику: сценарий атаки, количество прогонов, метрики MTTD (mean time to detect), MTTR (mean time to respond), доля ложных срабатываний (FPR). Формулы приводите в главе 2, а результаты — таблицей в главе 3 с указанием условий эксперимента.

Нормоконтроль заворачивает схемы. Что делать?

Оформляйте архитектуру по C4 (контекст → контейнеры → компоненты), а не «картинкой из интернета». UML-диаграммы последовательностей для сценария реагирования — по ГОСТ 19.701. Подписи, рамки, ссылки на рисунки в тексте обязательны.

Три темы ВКР, которые вырастают из этого кейса

• Тема 1. «Проектирование единой платформы управления ИБ для организации среднего бизнеса»

  Актуальность: тезис статьи о консолидации ИБ-функций в одной системе прямо задаёт проблему — разрозненные средства защиты плохо коррелируют события.

  Цель: спроектировать целевую архитектуру единого контура управления ИБ и оценить её эксплуатационные эффекты.

  Задачи: 1) анализ ISO/IEC 27001 и требований ФСТЭК к мониторингу; 2) сравнение SIEM/SOAR-платформ; 3) разработка архитектуры по C4; 4) оценка по метрикам MTTD/MTTR и TCO.

  Структура: Гл. 1 — анализ угроз и стандартов; Гл. 2 — проектирование и обоснование стека; Гл. 3 — прототип, нагрузочные тесты, расчёт эффективности.

• Тема 2. «Автоматизация реагирования на инциденты ИБ на основе корреляционных правил»

  Актуальность: «одна система закрывает все потребности» на практике означает автоматизацию, а не ручной разбор алертов.

  Цель: снизить MTTR за счёт автоматических плейбуков реагирования.

  Задачи: 1) маппинг сценариев на MITRE ATT&CK; 2) разработка правил корреляции (Sigma → SIEM); 3) реализация Active Response; 4) замер MTTR до/после.

  Структура: Гл. 1 — теория SOC и SOAR; Гл. 2 — проектирование плейбуков и правил; Гл. 3 — эксперимент и статистика срабатываний.

• Тема 3. «Оценка качества системы управления ИБ по ISO/IEC 25010»

  Актуальность: объединение функций в одну систему повышает связность рисков — надёжность и сопровождаемость становятся критичными.

  Цель: построить методику оценки качества единой ИБ-платформы.

  Задачи: 1) выбор характеристик ISO/IEC 25010; 2) метрики и веса; 3) прототип оценки; 4) апробация на стенде.

  Структура: Гл. 1 — стандарты качества ПО; Гл. 2 — методика и метрики; Гл. 3 — валидация и выводы.

Как встроить материал статьи в главы: пошаговый разбор

Глава 1: где живёт контекст и стандарты

Первая глава — не пересказ новости, а проблематизация. Опишите ландшафт угроз, сославшись на MITRE ATT&CK как таксономию техник, и на требования ISO/IEC 27001 в части мониторинга событий ИБ. Отдельный подраздел — обзор рынка SIEM/SOAR/XDR и обоснование, почему тренд идёт к консолидации. Здесь же уместен обзор OWASP для веб-векторов и ГОСТ 34 как рамки для проектной документации.

Глава 2: проектирование и конфигурация

Это ядро. Стройте архитектуру по C4: контекстная диаграмма (пользователи, агенты, внешние источники логов), контейнерная (коллектор, индекс, коррелятор, реактор), компонентная (правила, плейбуки, интеграции). Далее — спецификация в духе ГОСТ 34.601. Ключевой артефакт главы — набор правил корреляции. Пример правила в формате Sigma, которое потом конвертируется в язык вашей SIEM:

title: Multiple Failed Logons Followed by Success
id: 7f3a1c02-1a55-4e11-9c0a-demo00000001
status: experimental
description: Обнаружение подбора пароля с последующей успешной аутентификацией
logsource:
  product: windows
  service: security
detection:
  failed:
    EventID: 4625
  success:
    EventID: 4624
  timeframe: 5m
  condition: failed | count() by SourceIp > 10 and success
level: high
tags:
  - attack.credential_access
  - attack.t1110
falsepositives:
  - Скрипты с некорректно сохранённым паролем

Сразу привяжите правило к технике ATT&CK (T1110 — Brute Force). Это показывает комиссии, что вы работаете в отраслевой системе координат, а не придумываете классификацию с нуля.

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

Стенд: три-четыре виртуальные машины (жертва, атакующий, сервер SIEM, опционально — контроллер Active Response). Сценарии: брутфорс SSH, подозрительный PowerShell, сканирование портов. Для каждого прогона фиксируйте время от первого события до алерта (TTD) и от алерта до блокировки (TTR).

Считайте не только средние, но и разброс — медиана честнее при выбросах:

MTTD = Σ(T_detect_i − T_start_i) / N
MTTR = Σ(T_response_i − T_detect_i) / N
FPR  = FP / (FP + TP)

# пример разбивки по сценариям
scenarios = ["ssh_bruteforce", "suspicious_powershell", "port_scan"]
for s in scenarios:
    print(s, "MTTD:", mttd[s], "MTTR:", mttr[s], "FPR:", fpr[s])

Результат оформляйте таблицей «до внедрения корреляции / после» — это самый убедительный слайд на защите. И не забудьте про TCO: стоимость лицензий, часов сопровождения, железа. Даже приблизительная оценка на 3 года закрывает вопросы экономической части.

Чему вы научитесь на такой ВКР

• Проектировать архитектуру SOC-платформы и описывать её в нотации C4.
• Писать правила корреляции на Sigma и конвертировать их под конкретную SIEM.
• Строить изолированный стенд и воспроизводить техники MITRE ATT&CK.
• Считать MTTD, MTTR, FPR и защищать эти цифры перед комиссией.
• Оформлять проектную документацию по ГОСТ 34 и оценивать качество по ISO/IEC 25010.

Источник: Вебинар от SECURITM: «Объединяй и властвуй: система управления информационной безопасностью» (опубликовано 2026-03-24)