Риск в деньгах и моделирование угроз

7 мин чтения·Для руководителя

Качественная оценка «высокий / средний / низкий» помогает расставить приоритеты внутри команды, но не помогает получить бюджет. Для разговора с руководством риск нужно назвать в рублях.

В этой главе — количественная оценка, моделирование угроз по STRIDE для команд разработки и фиксация аппетита к риску.

Выражение риска в деньгах

Руководство лучше понимает деньги, чем абстрактные оценки. Переводите риски в финансовые термины.

Формула ожидаемых потерь (ALE)

Ожидаемые годовые потери (ALE) = Потери от одного инцидента × Частота в год

Пример: утечка клиентской базы
- Потери от одного инцидента (SLE): 5 000 000 руб.
  (реагирование + штрафы Роскомнадзора + репутационный ущерб)
- Частота в год (ARO): 0,1 (10% вероятность за год)
- ALE = 5 000 000 × 0,1 = 500 000 руб./год ожидаемых потерь

Если меры за 150 000 руб./год снижают ARO до 0,02:
- Новые ALE = 5 000 000 × 0,02 = 100 000 руб./год
- Экономия: 500 000 − 100 000 = 400 000 руб./год
- Возврат инвестиций: (400 000 − 150 000) / 150 000 = 167%

Ориентиры для расчётов

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

Тип ущерба	Оценка для малого бизнеса	Примечание
Реагирование на инцидент	500 тыс. — 3 млн руб.	Внутреннее время + форензика
Регуляторные штрафы	60–500 тыс. руб. (152-ФЗ), выше — для КИИ	Зависит от типа данных и нарушения
Уведомление пострадавших	50–200 руб. за запись	Требуется при утечке ПДн
Простой	50 тыс. — 2 млн руб./час	Зависит от бизнес-модели
Репутационный ущерб	5–20% годовой выручки	Сложно посчитать, но реально

Как говорить с руководством о рисках

Технический язык	Язык бизнеса
«Высокий риск SQL-инъекции»	«Злоумышленник может скачать всю клиентскую базу»
«Оценка риска 16 из 25»	«Ожидаемые потери от этого риска — около 500 тыс. руб. в год»
«Нужен WAF»	«За 200 тыс. руб./год снижаем вероятность взлома сайта на 60%»
«Уязвимость с CVSS 9.8»	«Эта уязвимость позволяет злоумышленнику захватить сервер за часы после публичного сканирования»

STRIDE: моделирование угроз для разработки

Для команд разработки методика STRIDE — систематический способ выявлять угрозы при проектировании новых функций или ревью архитектуры.

Категории STRIDE

Угроза	Что означает	Пример	Меры защиты
S — Споофинг (Spoofing)	Выдача себя за другого	Использование чужих учётных данных	Аутентификация, MFA
T — Тамперинг (Tampering)	Изменение данных или кода	SQL-инъекция, подмена цен	Валидация ввода, проверка целостности
R— Репудиация (Repudiation)	Отрицание совершённых действий	«Я не делал этот перевод»	Журналы аудита, неотказуемость
I — Информационное раскрытие (Information Disclosure)	Утечка чувствительных данных	Дамп базы, подробные сообщения об ошибках	Шифрование, контроль доступа
D — Доступность (Denial of Service)	Вывод системы из строя	DDoS, исчерпание ресурсов	Ограничение запросов, резервирование
E — Элевация привилегий (Elevation of Privilege)	Получение несанкционированного доступа	Захват admin-аккаунта, эскалация прав	Минимум привилегий, проверка авторизации

Быстрый анализ STRIDE

Для любой новой функции задайте вопросы по каждой из шести категорий:

• S: Как мы проверяем личность пользователя? Могут ли злоумышленники выдать себя за легитимных пользователей?
• T: Можно ли изменить данные при передаче или хранении? Валидируется ли ввод?
• R: Можем ли мы доказать, что произошло? Логируются ли действия?
• I: Какие данные могут утечь? Не слишком ли подробны сообщения об ошибках?
• D: Можно ли злоупотребить функцией? Есть ли ограничения запросов?
• E: Могут ли пользователи делать больше, чем им разрешено? Проверяется ли авторизация на каждом уровне?

Ресурсы: OWASP Threat Modeling — подробное руководство; OWASP Threat Dragon — бесплатный инструмент для диаграмм.

Истории: когда рисками не управляли

Кейс 1: Открытое хранилище

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

Итог: несколько миллионов рублей на реагирование, юридические расходы и отток клиентов. Устранить проблему стоило бы два дня работы.

Кейс 2: Принятый риск, который ударил

SaaS-компания приняла риск отсутствия MFA на административной консоли: «За VPN и так достаточно защиты». Ноутбук сотрудника был скомпрометирован через фишинг. Злоумышленник получил доступ к VPN, затем — к консоли администратора. Отсутствие MFA открыло полный доступ к данным клиентов.

В реестре рисков было написано: «Принят — VPN обеспечивает достаточную защиту». Ревью ни разу не поставило под сомнение, достаточно ли VPN в отрыве от MFA.

Кейс 3: Оценка рисков, которая спасла сделку

Финтех-стартап вёл переговоры о продаже. В ходе due diligence покупатель провёл проверку ИБ. Потому что у стартапа были: документированный реестр рисков, чётко определённые владельцы рисков, регулярные квартальные ревью и формальная документация об осознанно принятых рисках — команда безопасности покупателя потратила на проверку два дня вместо двух недель. Зрелость процессов была учтена при оценке стоимости компании.

Кейс 4: Приоритеты без оценки рисков

Компания потратила 3 млн руб. на систему обнаружения продвинутых угроз, при этом имея: 30% систем без актуальных обновлений, отсутствие MFA на критичных системах, общие пароли администраторов. Первая же «обнаруженная угроза» оказалась злоумышленником, уже находившимся внутри и использовавшим эти общие учётные данные. Дорогая система сработала отлично — и обнаружила взлом, который предотвратила бы базовая гигиена.

Аппетит к риску: как зафиксировать позицию руководства

Добейтесь, чтобы руководство утвердило явный аппетит к риску. Примеры формулировок:

Консервативный (регулируемая отрасль):

«Риски с оценкой 10 и выше не принимаются без решения правления. Все средние риски (5–9) должны иметь задокументированные планы снижения со сроком 90 дней. На производственных системах не допускаются известные критические уязвимости сроком более 7 дней.»

Взвешенный (типичная ИТ-компания):

«Риски с оценкой 15+ требуют согласования генерального директора для принятия. Риски 10–14 — согласования технического директора. Все высокие и критические риски должны иметь планы снижения. Часть средних рисков допустима при условии ежеквартального пересмотра.»

Гибкий (стартап на стадии роста):

«Мы ставим темп на первое место. Риски 20+ требуют согласования основателей. Мы осознанно принимаем повышенный риск в обмен на скорость, но документируем решения. Любые риски раскрытия клиентских данных — недопустимы вне зависимости от оценки.»

Подвяжите риски к бизнес-целям: «Наша цель — выйти на оборот 100 млн руб.» → «Инцидент задержит продажи на ~2 месяца». Это делает ИБ актуальной для бизнеса.

Управленческое задание: провести оценку рисков

Задание для лидера безопасности — управленческий контрольный артефакт

Поручите лидер безопасности провести оценку рисков и предоставить:

1. Инвентаризация активов (1 час). Список критичных активов компании с категоризацией по типам: данные, системы, процессы, люди, репутация. Рейтинг по важности — топ-10.

2. Идентификация угроз (1 час). Для каждого актива из топ-10 — 3–5 конкретных угроз. «Ransomware через фишинговое письмо», а не просто «кибератака».

3. Оценка и ранжирование рисков (1 час). Оценка вероятности и ущерба, итоговый рейтинг рисков от высшего к низшему.

4. Реестр рисков (1 час). Документ по шаблону выше с текущими мерами, решением (снизить/принять/передать/избежать), владельцем и сроком для высоких и критических рисков.

5. План снижения рисков (1 час). Для топ-5 рисков — конкретные меры с оценкой стоимости, усилий и сроками. Краткое обоснование для руководства.

✓Управленческий чек-лист

Контрольные точки для руководителя:

• Реестр рисков создан и содержит не менее 10 позиций
• У каждого высокого и критического риска назначен владелец
• Принятые риски задокументированы с обоснованием
• Ежеквартальный пересмотр реестра внесён в календарь
• Руководство ознакомлено с топ-5 рисками и утвердило аппетит к риску

Итоги

Устранить все риски невозможно. Цель — принимать осознанные решения о том, какие риски принять, какие снизить, а какие передать. Реестр рисков делает эти решения явными, а не подразумеваемыми.

Начните с таблицы и четырёх столбцов. Процесс можно добавить позже.

См. также

• Управление рисками — базовая методика оценки
• Отчётность и ROI — как докладывать это руководству
• Требования безопасности — требования, вытекающие из угроз

Что дальше

Следующий раздел — соответствие требованиям регуляторов: что компания обязана делать по закону и как превратить это в конкурентное преимущество.