Экономика кибербезопасности в дипломе: расчёт эффекта 1:12 и метрики ROI для защиты ВКР

**Поддомен:** Cybersecurity / Информационная безопасность **Роль:** Специалист по ИБ (Security Architect & Compliance Lead) **Схема структуры:** C — Введение → FAQ → Темы ВКР (карточки) → Основная часть → Чек-лист → Ошибки → CTA → Эксперт → Источник

Введение: почему цифра 1:12 меняет постановку задач в дипломе

Индустрия кибербезопасности России впервые оценила свой вклад в экономику в мультипликативных терминах: каждый вложенный в защиту ИС рубль принёс до 12 рублей совокупного эффекта, а общий вклад оценивается в 3,6–5,3 трлн рублей. Для выпускника это не абстрактная макроэкономика, а готовый каркас для третьей главы ВКР. Комиссия всё чаще спрашивает не «какие уязвимости вы закрыли», а «сколько это стоило бизнесу и что он сэкономил». Умение перевести техническое решение в деньги — тот навык, который отличает защищаемую работу по ИБ от «ещё одного обзора OWASP». Ниже — как встроить эту логику в структуру ВКР, какие метрики считать и где взять данные, если доступа к реальной инфраструктуре нет.

FAQ: 4 вопроса, которые задаёт каждый второй студент-безопасник

Где взять данные для оценки эффекта ИБ, если нет доступа к реальной компании?

Используйте публичные источники: отчёты Positive Technologies об актуальных атаках, Verizon DBIR, статистику ЦБ РФ по ущербу от кибермошенничества, кейсы из обзоров R-Vision и «Лаборатории Касперского». Для ВКР этого достаточно, если вы корректно укажете источник и год. Плюс — собственный стенд на Docker/ВМ, где вы эмулируете инцидент и считаете потери на модели.

Какую метрику ROI использовать — она ведь сильно зависит от допущений?

Берите не одну, а набор: ALE (Annualized Loss Expectancy), ROI по формуле (снижение ущерба — стоимость решения) / стоимость решения, и NPV за 3 года. В приложении обязательно дайте таблицу чувствительности: как меняется ROI при ±20% к стоимости лицензий и к вероятности атаки. Комиссия любит, когда автор честно показывает границы модели.

Обязательно ли делать собственный SOC/SIEM или можно ограничиться моделью?

Можно ограничиться моделью, если вы её проверите. Разверните Wazuh или ELK в Docker, сгенерируйте тестовые события через Atomic Red Team, настройте 3–5 правил детекта по MITRE ATT&CK и покажите, что детект работает. Это займёт вечер, но превратит теоретическую главу 2 в практическую, а вам даст скриншоты для приложений.

Как связать техническую часть с экономической, чтобы не получилось «двух отдельных дипломов»?

Введите промежуточный слой — модель киберриска. Технические меры (WAF, SIEM, EDR) снижают вероятность реализации угроз из ATT&CK; вероятность умножается на стоимость актива из реестра — получаете деньги. Одна таблица на 15 строк связывает обе части. Этот приём часто используют в работах, где нужно заказать диплом с реальной защитой, но и самостоятельно его реализовать вполне по силам.

Три темы ВКР, которые напрямую опираются на статью

Как встроить материал статьи в главы ВКР

Глава 1: превращаем макроэкономику в теоретическую рамку

Не пересказывайте статью — используйте её как источник постановки проблемы. В первом разделе уместно дать таблицу сопоставления: «макротренд из статьи → метрика уровня компании → метрика уровня технического решения». Например: 1:12 на уровне ВВП превращается в ROI проекта, а тот — в снижение ALE. Обязательно добавьте схемы: контекстную диаграмму C4 уровня System Context (компания, SOC, внешние угрозы, регулятор) и диаграмму классов угроз по OWASP Top 10. Так глава 1 перестаёт быть рефератом.

Глава 2: реализация прототипа и сбор технических метрик

Здесь — стенд в Docker: Wazuh Manager, агенты, тестовая ВМ с имитацией атак через Atomic Red Team. Настраиваете детекты и фиксируете MTTD и MTTR. Ниже — пример правила Sigma для детекта подозрительной аутентификации, которое пойдёт и в приложение, и в текст главы.

title: Suspicious Failed Logon Followed by Success
id: 7c3f4d2a-1b3e-4b52-9f2a-9b1c4e77a101
status: experimental
description: Детектирует серию неуспешных входов и последующий успешный — сценарий brute-force
logsource:
  product: windows
  service: security
detection:
  selection_fail:
    EventID: 4625
  selection_success:
    EventID: 4624
  timeframe: 5m
  condition: selection_fail | count() > 5 by IpAddress and selection_success
level: high
tags:
  - attack.credential_access
  - attack.t1110

Отдельно опишите схему потоков данных: агент → менеджер → индексер → дашборд. Простая ASCII-схема сгодится, если под рукой нет инструмента для UML.

[Endpoint] --> [Wazuh Agent] --> [Wazuh Manager] --> [Indexer] --> [Dashboard]
                                         |
                                         v
                                   [Alerting: Email/Telegram]

Глава 3: экономическая оценка и скрипт расчёта ROI

Ключевой раздел. Берём модель ALE = SLE × ARO. SLE — стоимость единичного инцидента, ARO — частота за год. После внедрения защиты ARO падает. Разницу вычитаем из стоимости решения. Ниже — минимальный скрипт для ВКР: его можно положить в приложение и упомянуть в автореферате.

def roi(ale_before: float, ale_after: float, cost: float, years: int = 3) -> dict:
    """
    ale_before - ожидаемые потери в год до внедрения
    ale_after  - ожидаемые потери после внедрения
    cost       - стоимость внедрения и сопровождения за год
    """
    saved = ale_before - ale_after - cost
    roi_pct = saved / cost * 100 if cost else 0
    npv = sum(saved / (1.15 ** t) for t in range(1, years + 1))
    return {"annual_saving": round(saved, 2),
            "roi_percent": round(roi_pct, 2),
            "npv_3y": round(npv, 2)}

# пример: 12 млн до, 3 млн после, 4 млн стоимость
print(roi(ale_before=12_000_000, ale_after=3_000_000, cost=4_000_000))

Такой расчёт — прямая иллюстрация тезиса статьи: если отношение «сэкономленное/затраченное» превышает 1, инвестиция оправдана. У вас появится числовой вывод, который комиссия запомнит.

Чему вы научитесь, пока будете это делать

Что проверить перед сдачей

  1. Каждая задача из введения отражена в выводах по главам — это первое, что смотрит нормоконтролёр.
  2. Все рисунки подписаны и пронумерованы, ссылки в тексте есть (Рисунок 3.2 — …).
  3. Код и конфиги вынесены в приложения, в тексте — только ключевые фрагменты.
  4. В третьей главе есть числовой результат: ROI, ALE, NPV или MTTD/MTTR — иначе работа не защищаема.
  5. Библиография оформлена по ГОСТ Р 7.0.100-2018, статья-источник указана корректно.
  6. Оригинальность текста выше порога вуза — проверьте заранее, а не за день до защиты.
  7. Все сокращения расшифрованы при первом появлении, единицы измерения единообразны.

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

1. Экономика «из воздуха». Студент пишет «внедрение даст эффект», но не указывает источник цифр. Комиссия сразу ловит это. Решение — таблица с источниками (Verizon DBIR, Positive Technologies, ЦБ РФ) и явные допущения.

2. Техническая часть без метрик. Скриншот дашборда Wazuh — это ещё не результат. Нужны MTTD/MTTR до и после, количество срабатываний, доля ложных срабатываний. Иначе нечего конвертировать в экономику.

3. Игнорирование регуляторики. Для российского контекста критично упомянуть ФСТЭК, ГОСТ 34, ISO/IEC 27001 и приказы ЦБ в части ИБ. Без этого работа выглядит оторванной от реальности — в отличие от статьи, где эффект посчитан именно для российской экономики.

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

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

Последнее обновление: 2026-09-18

Источник: Сектор ИБ на ВВП. Каждый рубль, вложенный в инфобез, дал 12 рублей эффекта (опубликовано 2026-03-24)