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

Сканирование как первый шаг атаки в ВКР: от новостного кейса до защищаемого проекта

Поддомен: Cybersecurity. Роль: специалист по информационной безопасности / архитектор защищённых систем.

В свежей публикации SecurityLab описана ситуация, знакомая каждому, кто вскрывал логи после инцидента: «активность началась раньше, чем о ней узнали те, кого это касается больше всего». Иными словами — сначала долгое, методичное сканирование, потом собственно атака. Нападавшие работали по учебнику: разведка, картирование периметра, поиск слабых мест и только затем — воздействие. Для выпускника ИТ это не просто новость, а готовый каркас дипломной работы. Здесь есть и кибер-убийственная цепочка (kill chain), и разрыв между обнаружением и реакцией, и измеримые метрики (MTTD, MTTR), которые можно честно посчитать на лабораторном стенде. Ниже — как превратить этот сюжет в главы, схемы, эксперименты и защищаемые выводы, а не в пересказ новости.

Темы ВКР и техническая основа: от разведки до реакции

Тема 1. Система раннего обнаружения сетевого сканирования на периметре

Актуальность. Кейс из статьи показывает, что фаза разведки может длиться днями и оставаться незамеченной. Классические средства защиты реагируют на эксплуатацию уязвимости, а не на подготовку к ней. Значит, есть разрыв, который можно закрыть дипломным проектом.

Цель ВКР: разработать модуль обнаружения сканирования (host discovery, port sweep, service fingerprinting) и оценить его эффективность на лабораторном стенде.

Задачи:

• проанализировать тактики разведки и сопоставить их с моделью угроз организации;
• сравнить подходы: сигнатурный (Suricata/Zeek), пороговый и поведенческий (по энтропии и частоте обращений к портам);
• описать правила корреляции и пороги срабатывания;
• провести эксперимент на трафике и посчитать Precision, Recall, F1 и MTTD.

Структура: Глава 1 — анализ угроз, обзор OWASP-классификаций и требований ISO/IEC 25010 к защищённости; Глава 2 — проектирование архитектуры (диаграммы C4, UML activity для потока событий); Глава 3 — стенд, воспроизведение сценария «scan → exploit», метрики и сравнение с baseline-IDS.

Тема 2. Лабораторный SOC на открытом стеке: от логов до алертов

Актуальность. Статья подчёркивает разрыв между обнаружением и информированием: активность была, но те, «кого это касается», узнали позже. Это классическая проблема SOC без корреляции событий и плейбуков реагирования.

Цель: спроектировать и развернуть мини-SOC (сбор → нормализация → корреляция → оповещение) и обосновать выбор компонентов.

Задачи: собрать требования по ГОСТ 34.602; спроектировать конвейер логов; описать правила корреляции; реализовать уведомления; провести нагрузочное тестирование.

Структура: Глава 1 — обзор SIEM-подходов и Threat Intelligence; Глава 2 — ТЗ и архитектура (C4 Container/Component); Глава 3 — пилот, замеры задержек и MTTR.

Тема 3. Методика оценки качества систем обнаружения вторжений по ISO/IEC 25010

Актуальность. «Читал учебник» — это комплимент атакующим. Защищающаяся сторона тоже должна действовать по методике, а не «на глаз». Оценка качества IDS — редкий, но выигрышный для защиты сюжет.

Цель: разработать и апробировать методику оценки IDS по подхарактеристикам security, performance efficiency и reliability.

Задачи: выбрать метрики; собрать эталонный датасет; провести серию экспериментов; оформить протоколы испытаний.

Структура: Глава 1 — теория метрик и стандартов; Глава 2 — методика и инструментарий; Глава 3 — апробация на 2–3 IDS с разными профилями.

Куда встраивать материал статьи в главы

Первую главу не стоит делать конспектом новости. Используйте публикацию как триггер: вынесите в неё описание реального сценария, затем сопоставьте с MITRE-подобной тактикой Discovery и сформулируйте гипотезу — «если на периметре есть N событий от одного источника за T секунд, вероятность сканирования высока». Гипотеза превращается в критерий проверки во второй и третьей главах.

Для проектной части хватит диаграмм C4 (System Context и Container) плюс UML activity для потока «лог → корреляция → алерт». Не рисуйте «просто схему сети» — её нечем защищать. Каждая стрелка на C4 должна иметь подпись протокола и формата данных, иначе на защите спросят «а что здесь передаётся?».

# Фрагмент правила Suricata: детект горизонтального сканирования
alert tcp any any -> $HOME_NET any (
  msg:"SCAN horizontal port sweep detected";
  flags:S;
  threshold: type both, track by_src, count 30, seconds 10;
  sid:1000001; rev:1;
)

# Расчёт метрик детектора в главе 3
from sklearn.metrics import precision_score, recall_score, f1_score

y_true = [0,0,1,1,0,1,1,0]   # разметка эталонного трафика
y_pred = [0,1,1,0,0,1,1,0]   # срабатывания детектора

print("Precision:", round(precision_score(y_true, y_pred), 3))
print("Recall:  ", round(recall_score(y_true, y_pred), 3))
print("F1:      ", round(f1_score(y_true, y_pred), 3))

Такой скрипт в приложении закрывает вопрос «а как вы считали эффективность» — и снимает половину каверзных вопросов комиссии.

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

• строить модель угроз и привязывать её к фазам атаки, а не к абстрактной «актуальности»;
• проектировать конвейер обработки событий и обосновывать выбор каждого компонента;
• корректно считать метрики детектирования и не путать Recall с точностью;
• оформлять ТЗ и протоколы испытаний по ГОСТ 34/19;
• защищать выбранные решения через измеримые показатели, а не через «так принято».

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

Три рабочих пути: публичные датасеты трафика (CIC-IDS, UNSW-NB15, MAWILab), самостоятельно сгенерированный стенд на изолированных виртуалках и логи собственного развёрнутого honeypot. Для диплома достаточно второго: вы контролируете разметку и можете честно описать ограничения эксперимента.

Какой стек выбрать, чтобы уложиться в 4–5 месяцев?

Минимум, который защищается: Zeek или Suricata для детекта, Elastic/OpenSearch для хранения, Python для аналитики. Не берите тяжёлый коммерческий SIEM — вы не успеете его обосновать. Если делаете API-часть, ограничьтесь FastAPI и PostgreSQL.

Сколько метрик должно быть в главе 3?

Четыре-пять ключевых. Перегруз метриками без интерпретации снижает оценку. Обязательный минимум: MTTD, Recall, Precision, F1 и доля ложных срабатываний. Этого хватает для честных выводов.

Как оформить схемы, если нормоконтроль строгий?

Диаграммы C4 и UML вставляйте как изображения с подписью «Рисунок N — …» и ссылкой в тексте. Формат — ГОСТ 34.201 для проектной документации. Не используйте цветные нотации без легенды: чёрно-белая печать превратит их в кашу.

Источник: Сначала сканируем, потом воюем. Кто-то явно читал учебник — и делал всё строго по нему (опубликовано 2026-03-27)