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

# Семантический анализ **1. Основной поисковый запрос (Primary keyword)** «Анализ вымогательского ПО для ВКР» (кластер: защита информации в дипломе, ransomware-кейс в ВКР). **2. LSI-запросы (5–10)** - модель угроз MITRE ATT&CK - ISO/IEC 27001, ISO/IEC 25010 (метрики качества) - ГОСТ Р 34.10-2012, AES-256 / RSA-2048 - EDR, SIEM, YARA-правила - RTO / RPO, резервное копирование - OpenTelemetry, журналирование - Docker/VirtualBox, изолированный стенд - ГОСТ 34.602-89 (ТЗ), ГОСТ 19.701 (схемы) **3. Реальные вопросы студентов (5)** 1. «Обязательно ли поднимать настоящий стенд или можно обойтись теорией?» 2. «Где брать логи и тестовые данные, если нет доступа к реальной инфраструктуре?» 3. «Как измерить эффективность защиты в дипломе — чем, кроме „стало безопаснее“?» 4. «Нужен ли код (правила YARA, скрипты), или хватит схем и расчётов?» 5. «Как оформить диаграммы, чтобы их приняли по ГОСТ?» **4. Ключевые сущности (5)** MITRE ATT&CK · ISO/IEC 27001 · ГОСТ Р 34.10-2012 · EDR/SIEM · RTO/RPO. --- ```html

Анализ вымогателя Pay2Key для ВКР: от модели угроз MITRE ATT&CK до расчёта RTO и RPO

Сюжет из клиники, о котором сообщил SecurityLab 30 марта 2026 года, звучит как анекдот для сисадминов: файлы зашифрованы, а ключ и служебные данные злоумышленник оставил прямо в каталоге %TEMP% — временной папке, которую любой скрипт читает первой. Из-за этой небрежности ущерб оказался меньше, чем обещала громкая реклама Pay2Key. Но для выпускника ИТ-направления ценность здесь не в иронии, а в методике: перед нами готовый учебный кейс «атака — обнаружение — восстановление», который отлично ложится в диплом. Ниже — как превратить новость в защищаемую ВКР, не скатившись к пересказу пресс-релиза.

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

Тема 1. Оценка устойчивости корпоративной сети к вымогательскому ПО

Актуальность. Инцидент в клинике показывает типичный разрыв: шифрование сработало, а вот контроль временных каталогов и резервных копий — нет. В работе как раз анализируется, какие слои защиты дают сбой на каждом этапе атаки.

• Цель: разработать методику оценки устойчивости ИС к атакам класса «шифрование данных с выкупом».
• Задачи: построить модель угроз по MITRE ATT&CK; сопоставить техники атаки с мерами из ISO/IEC 27001 (Приложение A); сформировать чек-лист проверки и метрики; апробировать методику на учебном стенде.
• Структура: Глава 1 — анализ техник ATT&CK и требований ГОСТ/ISO; Глава 2 — проектирование методики и стенда; Глава 3 — эксперименты, расчёт показателей, оценка внедрения.

Тема 2. Стенд для моделирования атак и сравнительного тестирования EDR

Актуальность. В кейсе ключ восстановили во многом благодаря артефактам, оставшимся на диске. Значит, вопрос в том, какие средства логирования и EDR вообще заметят подобное — а это уже измеримая задача.

• Цель: спроектировать изолированный стенд для воспроизведения атак и сравнения средств обнаружения.
• Задачи: обосновать виртуализацию (Docker/VirtualBox); описать сценарии атак с безопасными имитаторами; настроить сбор журналов (OpenTelemetry, syslog); сравнить 2–3 решения по частоте срабатываний и ложных положительных.
• Структура: Глава 1 — обзор SIEM/EDR и стандартов; Глава 2 — архитектура стенда и политики изоляции; Глава 3 — прогон сценариев, таблица результатов, ограничения.

Тема 3. Проектирование подсистемы резервного копирования с заданными RTO/RPO

Актуальность. Даже успешная расшифровка не отменяет простоя: клиника жила без данных, пока разбиралась с ключом. Расчёт RTO/RPO — самая «защищаемая» часть такой работы, потому что даёт числа, а не обещания.

• Цель: спроектировать схему резервного копирования, обеспечивающую заданные RTO и RPO для медицинской ИС.
• Задачи: классифицировать данные по критичности; выбрать схему (full + инкремент, правило 3-2-1, неизменяемые копии); построить диаграмму развёртывания; провести замеры восстановления.
• Структура: Глава 1 — теория непрерывности и стандарты; Глава 2 — архитектура хранения и расписания; Глава 3 — учения по восстановлению, фактические RTO/RPO, экономика.

Аналитическая глава: как превратить новость в сравнение решений

Не пересказывайте статью — используйте её как триггер. Первый раздел аналитики логично начать с разбора атаки: где злоумышленник получил доступ, как прошёл к файлам, почему ключ остался в %TEMP% и что это говорит о зрелости вредоноса. Дальше — обоснование стека, и здесь нужна таблица, а не абзац текста.

Обоснование стека без «мы выбрали Python, потому что он популярный»

Каждое решение подкрепляйте ограничением из вашей предметной области: объём данных, требования к изоляции стенда, доступность лицензий в вузе. Формулировка вида «VitualBox выбран из-за снапшотов и отсутствия гипервизорных лицензий; альтернатива vSphere отклонена по стоимости владения» закрывает вопрос комиссии мгновенно.

Проектная часть: схемы, алгоритмы, интеграция

Практическая глава — это то, что комиссия смотрит руками. Минимум, который ожидается: диаграмма развёртывания стенда, схема потоков журналов в SIEM и алгоритм реакции на инцидент. Оформляйте по ГОСТ 19.701, а не «картинкой из Figma».

Пример правила обнаружения — как листинг, а не как украшение

rule Ransomware_KeyArtifact_InTemp
{
    meta:
        author      = "VKR, 2026"
        description = "Поиск служебных артефактов шифрования во временном каталоге"
        reference   = "securitylab.ru/news/570949"
    strings:
        $key   = "KEY_DATA" ascii
        $path  = "\\Temp\\" ascii nocase
        $note  = "readme" ascii nocase
    condition:
        filesize < 2MB and 2 of them
}

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

Алгоритм реакции на инцидент

Достаточно шагов «изоляция хоста → фиксация артефактов (%TEMP%, журналы) → проверка резервных копий → восстановление → разбор». Каждый шаг привяжите к исполнителю и времени — получается блок-схема, которую легко защищать.

Тестирование и метрики: то, что отличает диплом от реферата

Здесь пригодится гипотеза из самой новости: если служебные данные остаются на диске, восстановление возможно без выкупа. Проверить её можно измерением.

Нагрузочное тестирование делайте хотя бы базовое: сколько событий в секунду выдерживает коллектор (OpenTelemetry/syslog-ng), на каком объёме начинает терять данные журнал. Числа с потолка не приводите — фиксируйте методику замера в приложении.

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

• Строить модель угроз и связывать её с конкретными мерами из ISO/IEC 27001 и приказов ФСТЭК.
• Обосновывать стек через ограничения, а не через популярность технологий.
• Проектировать изолированные стенды и не ронять инфраструктуру вуза при демонстрации.
• Считать метрики безопасности: RTO, RPO, полноту и точность обнаружения.
• Оформлять ТЗ, схемы и листинги по ГОСТ 34.602-89 и ГОСТ 19.701.

Вопросы, которые задают чаще всего

Нужно ли запускать настоящий вымогатель?

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

Обязателен ли код?

Формально нет, но одно рабочее правило YARA, парсер логов или скрипт развёртывания стенда резко усиляют защиту. Работа «только со схемами» защищается тяжелее — комиссии нечего посмотреть вживую.

Где брать тестовые данные?

Три источника: открытые отчёты (MITRE ATT&CK, CISA, публикации SecurityLab), собственные журналы стенда, сгенерированные сценарии. Каждый источник фиксируйте датой выгрузки и ссылкой — иначе получите вопрос «откуда цифры».

Как оформить диаграммы?

Диаграмма развёртывания — UML, схема алгоритма — ГОСТ 19.701 (блок-схема), общая архитектура — допустимо в свободной нотации с легендой. Главное: единая нумерация, ссылки из текста («см. рисунок 2.3») и подписи без «красиво нарисовано».

Источник: — «Ты зашифровал файлы?» — «Да» — «А где ключ?» — «В папке Temp» — «Упс…». Вот почему вымогатель Pay2Key не так страшен, как его рисуют (опубликовано 2026-03-30)

```