Инциденты ИБ в дипломе: как превратить «чужих людей в серверах» из Гааги в защищаемую ВКР

Поддомен: Cybersecurity · Роль эксперта: специалист по информационной безопасности

Введение

В марте 2026 года министерство финансов Нидерландов столкнулось с классическим сценарием: в серверной инфраструктуре ведомства обнаружены посторонние. Формулировка «в штате — нет, в серверах» — это не анекдот, а точное описание того, что в моделях угроз называется несанкционированным закреплением в инфраструктуре. В Гааге до сих пор гадают, что именно вынесли: бюджетные модели, переписку, персональные данные сотрудников? Именно эта неопределённость и есть главный кошмар ИБ-специалиста — ты знаешь, что доступ был, но не знаешь периметр ущерба.

Для выпускника направления 09.03.04 / 10.03.01 такой кейс — готовый полигон для ВКР. Он даёт редкое сочетание: свежий публичный инцидент, понятная бизнес-боль (госсектор, критическая инфраструктура) и явный технический запрос на решение. Разберём, как не свести это к реферату «что такое хакеры», а собрать инженерную работу с архитектурой, метриками и воспроизводимым экспериментом.

FAQ: что чаще всего спрашивают до начала работы

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

• Тема 1. Разработка системы раннего обнаружения закрепления нарушителя в корпоративной сети госсектора

  Актуальность: в Гааге выявили посторонних уже на этапе «в серверах», то есть стадия обнаружения была провалена. Разбираем именно её.

  Цель: сократить время обнаружения закрепления с суток до десятков минут на тестовом стенде.

  Задачи: 1) формализовать модель угроз по ATT&CK; 2) развернуть сбор телеметрии (Sysmon/auditd, журналы AD); 3) написать 8–12 правил корреляции и проверить их на эмуляции; 4) измерить MTTD и ложноположительные срабатывания.

  Структура: Гл. 1 — анализ инфраструктуры и тактик закрепления. Гл. 2 — проектирование конвейера «источник → нормализация → правило → алерт», схема C4. Гл. 3 — эксперимент, замеры, сравнение с базовой конфигурацией.

• Тема 2. Управление привилегированными учётными записями как средство снижения риска внутреннего нарушителя

  Актуальность: посторонний в серверной чаще всего опирается на легитимную учётку или сервисный аккаунт без хозяина. PAM-контур закрывает ровно этот класс атак.

  Цель: спроектировать и оценить схему JIT-доступа (just-in-time) к административным учёткам.

  Задачи: 1) инвентаризация привилегированных ролей; 2) проектирование выдачи доступа по заявке с TTL; 3) реализация на базе RBAC в тестовом контуре; 4) оценка снижения поверхности атаки.

  Структура: Гл. 1 — анализ рисков учётных записей, ISO/IEC 27002 в части контроля доступа. Гл. 2 — архитектура и схемы последовательности (UML Sequence). Гл. 3 — сценарии «до/после», метрики покрытия и времени выдачи.

• Тема 3. Автоматизация реагирования на инциденты с помощью плейбуков SOAR

  Актуальность: когда неизвестно, что именно украли, критично иметь воспроизводимый сценарий отсечения и сбора доказательств — иначе расследование превращается в гадание.

  Цель: спроектировать набор плейбуков для типовых инцидентов и оценить экономию времени аналитика.

  Задачи: 1) классификация инцидентов; 2) проектирование плейбуков (изоляция хоста, сброс сессий, снятие дампа памяти); 3) реализация оркестрации в тестовом контуре; 4) расчёт MTTR и трудозатрат.

  Структура: Гл. 1 — теория реагирования (NIST SP 800-61: подготовка → обнаружение → локализация → восстановление → выводы). Гл. 2 — BPMN-схемы плейбуков и интеграции. Гл. 3 — прогон сценариев, метрики, экономический эффект.

Как разложить материал статьи по главам

Глава 1: инцидент как источник требований, а не как пересказ новости

Новость о Гааге вставляется в первую главу одной страницей — и сразу превращается в требования. Ключевой вопрос, который вы задаёте: почему посторонние в серверах остаются незамеченными месяцами? Ответ разбирается на три составляющие: отсутствие централизованного сбора событий, отсутствие корреляции между ними, отсутствие владельца у сервисных учётных записей.

Схемы, которые здесь уместны: контекстная диаграмма C4 (уровень 1) — показать границы ведомства и точки входа; диаграмма классов UML — модель «Событие → Правило → Инцидент → Действие». Текстом это описывается так:

[Источник логов] --(syslog/API)--> [Нормализатор] --(ECS-событие)--> [Движок правил]
                                                                          |
[Playbook SOAR] <--(webhook)---- [Менеджер инцидентов] <--(score>70)-----+

Глава 2: проектирование контура защиты

Здесь строится целевая архитектура. Опора — принципы Zero Trust («никогда не доверяй, всегда проверяй») и практический контроль доступа через RBAC. Обязательно покажите, как ваше решение отвечает на конкретный сценарий из статьи: доступ сервисного аккаунта к файловому хранилищу вне регламентного окна должен порождать алерт, а не тишину в логах.

Пример правила корреляции, которое студент вполне может написать за вечер — Sigma-подобная конструкция для «закрепления»:

title: Добавление учётной записи в группу администраторов
id: wkr-ib-0007
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4728          # добавление в глобальную группу
    TargetUserName|endswith: '$'   # сервисный аккаунт
  condition: selection
fields:
  - SubjectUserName
  - TargetUserName
level: high
falsepositives:
  - Легитимная инвентаризация (подтверждается тикетом)

И минимальный обработчик, который нормализует события перед корреляцией:

import json, hashlib
from datetime import datetime

def normalize(raw: dict) -> dict:
    """Приводим сырое событие SIEM к единому формату."""
    return {
        "ts": datetime.fromisoformat(raw["timestamp"]),
        "host": raw.get("computer_name", "unknown"),
        "user": raw.get("subject_user_name"),
        "action": raw.get("event_id"),
        "risk": 0.0,
        "fingerprint": hashlib.sha256(
            json.dumps(raw, sort_keys=True).encode()
        ).hexdigest()[:16],
    }

Обратите внимание на поле fingerprint: оно позволяет дедуплицировать события, когда один и тот же алерт прилетает из трёх источников. Комиссия такие детали ценит — они показывают, что вы думали не только о срабатывании, но и о потоке алертов уставшего дежурного.

Глава 3: метрики вместо «работает, я проверял»

Третья глава без чисел — это не третья глава. Ниже — минимальный набор метрик, которые реально считаются на тестовом стенде и коррелируют с требованиями стандарта ISO/IEC 25010 в части производительности и защищённости.

Чему вы научитесь к моменту защиты

• Формализовать инцидент из открытого источника в проверяемые требования к системе защиты.
• Проектировать архитектуру детектирования и реагирования, а не набор разрозненных скриптов.
• Писать и валидировать правила корреляции, отличая реальный сигнал от шума.
• Считать метрики безопасности через призму ISO/IEC 25010 и защищать их на защите ВКР.
• Оформлять техническую документацию по ГОСТ 34 и ГОСТ 19 так, чтобы нормоконтроль проходил с первого раза.

Ещё не определились с направлением?

Иногда сложность не в коде, а в выборе ракурса: тема кажется размытой, требования вуза не читаются однозначно, а сроки уже поджимают. Если вы понимаете, что заказать диплом по ИБ нужно с внятной технической частью, а не с набором общих фраз, — начните с бесплатной консультации. Мы отводим на проработку одной темы около 120 часов, объясняем, где брать данные для экспериментов, и разбираем, как оформить схемы и метрики под ГОСТ. Помощь с дипломом не означает, что за вас всё напишут — чаще это разбор вашего плана и подсказка, где в нём дыра. ВКР на заказ тоже возможен, если времени на самостоятельный путь совсем нет.

Источник: «У вас там чужие люди». «В штате?» «Нет, в серверах». Инцидент в министерстве финансов Нидерландов (опубликовано 2026-03-25)