Информационная безопасность в дипломе: как превратить кейс о цифровых следах в исследование

В новости от 18 марта 2026 года Следственный комитет предъявил обвинение 17-летнему школьнику из Кузбасса — он поставил несколько реакций в мессенджере, и это расценили как финансирование терроризма. Для студента ИТ-направления это не просто тревожный сигнал, а готовая исследовательская задача. Любое действие в цифровой среде оставляет след, а значит, информационные системы должны и уметь фиксировать такие следы, и правильно их интерпретировать. Если вы пишете ВКР по информационной безопасности, этот кейс можно превратить в полноценное исследование — от анализа законодательства до прототипа системы мониторинга. Разберём, как это сделать без лишней «воды» и с реальной практической пользой.

Почему этот случай — готовый фундамент для ВКР

История с «звездочками» в мессенджере поднимает сразу три пласта проблем: правовой, технический и социальный. В выпускной квалификационной работе важно показать взаимосвязь этих уровней. Студенты часто уходят либо в чистую юриспруденцию, либо в чистый код. В грамотной ВКР по ИБ должен быть баланс. Ниже — три предметные области, в которых кейс ложится в основу дипломного проекта.

Тема ВКР	Актуальность (отсылка к статье)	Цель	Задачи	Структура
Разработка прототипа DLP-системы для мониторинга действий в мессенджерах	Реакции и пересылки стали юридически значимыми событиями, нужен инструмент, который предупреждает риск	Создать систему выявления подозрительного контента и действий пользователя	1) Классифицировать угрозы; 2) спроектировать архитектуру; 3) реализовать прототип; 4) провести тестирование	Глава 1 — анализ методов DLP; Глава 2 — проектирование и реализация; Глава 3 — оценка эффективности (точность, полнота, F1)
Методика расследования инцидентов, связанных с финансированием противоправной деятельности через мессенджеры	СК использует цифровые следы как доказательства — необходима формализованная процедура их сбора	Разработать алгоритм сбора и анализа цифровых следов для правоохранительных органов или служб безопасности	1) Типизировать инциденты; 2) описать юридические требования к доказательствам; 3) создать методику; 4) апробировать на сценарии из статьи	Глава 1 — анализ практики расследований; Глава 2 — разработка методики; Глава 3 — апробация и оценка достоверности
Оценка влияния правовых требований на проектирование архитектуры защищённого мессенджера	Новое регулирование требует встраивать контроль действий пользователя на уровне архитектуры	Определить технические требования к мессенджеру с учётом законодательства РФ	1) Изучить законы и подзаконные акты; 2) построить модель угроз; 3) сформировать требования к системе; 4) предложить архитектурное решение (UML/C4)	Глава 1 — правовые и технические аспекты; Глава 2 — проектирование архитектуры; Глава 3 — анализ соответствия требованиям ISO/IEC 25010

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

Как перевести новость в технические требования к системе

Предположим, вы выбрали первую тему — прототип DLP-системы. Материал из статьи вам нужно встроить в первую главу: вы описываете инцидент как типовую угрозу и показываете, почему реакция в мессенджере — это маркер. Дальше строите архитектуру. Вместо того чтобы рисовать абстрактные кубики, используйте C4-модель: сначала контекстная диаграмма (пользователь, мессенджер, сервер), потом контейнеры, потом компоненты. Это легко объяснить на защите: вы не просто набросали схему, а применили стандарт.

Для определения требований к системе удобно взять декомпозицию из ГОСТ 34.601-90 — она всё ещё часто используется при проектировании автоматизированных систем. А для оценки качества — ISO/IEC 25010: функциональная пригодность, производительность, безопасность, сопровождаемость. Обязательно пропишите эти стандарты в тексте, но не как «использован ГОСТ», а с реальными ссылками на конкретные характеристики.

Вот фрагмент кода, который покажет членам комиссии, что вы знаете, как работает детектирование. Это не полноценная DLP, но ядро эвристики для выявления подозрительных реакций. Пример на Python:

# Простейшая эвристика: связь между действием, частотой и "весом" сообщения
import re

ACTION_WEIGHT = {"👍": 1, "🔥": 1, "❤️": 2, "🚫": 3}
FORBIDDEN_TOPICS = ["финансирование", "схема", "криптовалюта", "перевод"]

def check_message(message, actions):
    score = 0
    text = message.get("text", "")
    for action in actions:
        score += ACTION_WEIGHT.get(action["type"], 0)
    for word in FORBIDDEN_TOPICS:
        if re.search(word, text, re.IGNORECASE):
            score += 5
    if score > 10:
        return {"risk": "high", "score": score}
    return {"risk": "low", "score": score}

Этот код — предмет для обсуждения на защите. Вы можете показать, как расширяется список ключевых слов, как вводится временной окно, как добавляется модель машинного обучения. Главное — код не должен быть «игрушечным», а должен быть обоснован моделью угроз.

Метрики эффективности и эксперименты: на что смотреть

Любую систему ИБ нужно оценивать. Для DLP-прототипа используйте метрики классификации: precision (точность), recall (полнота), F1-score и FAR/FRR (ложные срабатывания/пропуски). Покажите, как вы собирали датасет: возьмите синтетические диалоги, разметьте их вручную — это отдельный артефакт для приложения. В главе 3 нужно построить таблицу с результатами экспериментов и сравнить с базовым порогом.

Важно: не «рисуйте» красивые цифры. Если полнота получилась 98%, вы должны объяснить, почему так, какие данные использовали. Лучше честно показать, что при увеличении полноты падает точность, и предложить компромиссный вариант — так комиссия увидит инженерное мышление.

Практические выводы: чему вы научитесь

Проектировать архитектуру DLP-системы с использованием UML/C4 и перекладывать требования ГОСТ на технические решения.
Обосновывать выбор метрик (FAR/FRR, F1, time to response) и строить эксперимент для дипломной работы.
Собирать и размечать данные для обучения моделей или проверки эвристик — без этого невозможно тестирование.
Правильно оформлять схемы и диаграммы по стандартам, чтобы проходить нормоконтроль без переделок.
Анализировать правовые нормы и превращать их в проверяемые требования к программному обеспечению.

FAQ по теме ВКР

Как выбрать стек для DLP-системы, если в вузе не требуют конкретных технологий?

Берите популярные и понятные: Python + FastAPI для бэкенда, PostgreSQL для логов, Redis для кэша. Если хотите показать навыки DevOps — оберните в Docker и добавьте OpenTelemetry для трейсинга. В пояснительной записке просто перечислите, почему этот стек решает задачи из главы 2.

Что делать, если сложно найти данные для испытаний DLP-системы?

Генерируйте синтетические диалоги. Можно взять открытые датасеты с диалогами на русском языке и «подмешать» искусственные маркеры. Главное — в приложении указать, как вы формировали выборку и как обеспечили отсутствие реальных персональных данных. Методику такой генерации можно оформить как отдельный регламент.

Какие метрики считать, чтобы доказать эффективность?

Для DLP — точность, полнота, F1, FAR/FRR. Если хотите показать экономическую эффективность, посчитайте, сколько инцидентов система предотвращает в месяц и сколько человеко-часов экономит служба безопасности. Это можно вывести в главу «Экономическая эффективность».

Требует ли вуз обязательного использования ГОСТ в ВКР по ИБ?

Даже если вуз не требует, член комиссии ожидает, что вы знаете ГОСТ 34.601-90 на уровне названия и связи с этапами проектирования. Также полезно сослаться на ГОСТ Р 56545-2015 по расследованию инцидентов, если ваша тема близка к реагированию. Но не перегружайте текст цитатами — достаточно одного-двух корректных упоминаний.

Типичные ошибки студентов

Ошибка 1. Копировать настройки чужих DLP-систем из интернета без адаптации. Если вы взяли конфигурацию, вы обязаны объяснить, почему в ней такие правила. Иначе на защите вопрос «А почему этот порог — 10?» поставит в тупик. Выход: всегда описывайте, как правила и пороги связаны с моделью угроз из главы 1.

Ошибка 2. Разрыв между юридической и технической частями. В статьях о новых законах часто описывают только правовые риски. Студенты же пишут главу о законодательстве, а потом код, который никак на него не опирается. Лучше прогнать каждое требование: «согласно закону X, система должна сохранять неизменность логов» — и добавить в проект модуль хэширования логов.

Ошибка 3. Подмена метрик «средней эффективностью». Фразы вроде «система работает эффективно» без цифр — это красный флаг. Если вы не считали F1, попросите руководителя помочь с методикой. В крайнем случае можно взять публичные исследования и адаптировать их, но с обязательной ссылкой на источник.

Чек-лист перед сдачей

Все задачи в ведении соответствуют выводам в заключении — проверьте зеркальность.
Схемы в тексте и презентации подписаны, а названия соответствуют ГОСТ или C4 (например, «Диаграмма контейнеров C4»).
Упомянуты стандарты: ГОСТ 34.601-90, ISO/IEC 25010, OWASP для веб-части.
Для каждой метрики (F1, FAR/FRR) есть формула и объяснение, почему она выбрана.
В приложении есть исходный код, ссылки на датасеты и README с инструкцией по запуску.
Уникальность текста — не менее требуемой в вашем вузе, но без переливания воды.

Помните: не обязательно заказывать диплом, чтобы получить хорошую тему. Пример из статьи — уже готовый кейс, который можно развить с руководителем. Если вам нужна консультация по выбору темы, оценке метрик или структуре работы, вы можете обратиться за бесплатной помощью — в течение 120 часов мы помогаем студентам с ВКР и подскажем, как упростить защиту.

Материал подготовлен экспертами компании Deploif.dev. Мы помогаем студентам с 2010 года. Если вам нужна помощь в разработке темы или оформлении работы, наши специалисты готовы подсказать.

Последнее обновление: 2026-08-15

Источник: 15 лет за «звездочку». 17-летнего школьника обвинили в финансировании терроризма из-за реакций в мессенджере (опубликовано 2026-03-18)

```