От угроз к приоритетам: ранжирование риска и выбор мер защиты

От списка к порядку: вероятность x ущерб

Результат STRIDE, DFD и деревьев атак — это множество, неупорядоченное по построению. Приоритизация навязывает порядок, и рабочая ось здесь — риск = вероятность x ущерб. Вероятность — это насколько правдоподобна атака для реального противника: нужен ли ему государственный масштаб и zero-day или достаточно скучающего пользователя, правящего URL? Ущерб — это во что тебе обойдётся, когда атака сработает: испорченная маркетинговая страница — это не утёкшая таблица клиентов, и ни то ни другое — не баг с подменой цены, из-за которого каждый заказ уезжает за одну копейку.

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

Почему DREAD утратил доверие

Годами схемой оценки по умолчанию был DREAD — Damage, Reproducibility, Exploitability, Affected users, Discoverability — каждый фактор по шкале 1–10 и суммируется. Звучит научно, но это не так. Проблема в том, что входы субъективны, а шкала не определена: нет общего рубрикатора, что делает Damage шестёркой, а что семёркой, поэтому два рецензента оценивают одну угрозу по-разному, и тот же рецензент во вторник оценит её иначе. Discoverability (обнаруживаемость) — фактор активно вредный: он поощряет security-through-obscurity, занижая оценку бага лишь потому, что его сейчас трудно найти, — а это ровно наоборот тому, как следует рассуждать о противнике, у которого всё время мира. Microsoft, популяризовавшая DREAD, тихо отказалась от неё внутри по этим причинам. Система оценки, вывод которой нельзя воспроизвести, — это не измерение; это число, которое выглядит как измерение, что хуже, потому что выдаёт догадку за данные.

Вместо этого команды берут небольшую лесенку лучше откалиброванных инструментов, выбираемых по тому, что именно оценивается:

• Качественные матрицы риска для угроз из модели. Сетка 3x3 или 5x5 «вероятность x ущерб», где каждый диапазон определён («высокая вероятность = эксплуатируется неаутентифицированным пользователем с публичным инструментарием»). Определённые диапазоны — в этом весь смысл: они делают оценку воспроизводимой, не притворяясь точностью до второго знака.
• CVSS для известных уязвимостей — CVE в зависимости, находка сканера. CVSS даёт стандартизированный, вендоронезависимый базовый балл 0–10 из определённых метрик (вектор атаки, сложность, требуемые привилегии, область, влияние на CIA), так что «CVE-2023-xxxx — это 9.8» означает одно и то же между командами и инструментами. CVSS — для уязвимостей, на которые можно указать пальцем; он не предназначен для ранжирования проектных угроз, выведенных из DFD.
• OWASP Risk Rating Methodology, когда нужна определённая, но гибкая факторная модель. Она разделяет вероятность (факторы агента угрозы + уязвимости: навык, мотив, лёгкость обнаружения, лёгкость эксплуатации) и ущерб (технические + бизнес-факторы), оценивает каждый фактор по определённой шкале 0–9 и сводит их в матрицу Low/Medium/High — амбиция DREAD, но уже с настоящими рубрикаторами под ней.

Зрелый ход — подбирать инструмент под вход: матрица для смоделированных угроз, CVSS для каталогизированных CVE, OWASP Risk Rating, когда нужна аудируемая разбивка по факторам. Смешивание — оценка проектной угрозы через CVSS или CVE в зависимости через взмах руки — даёт числа, которым никто не доверяет.

Ячейка-ловушка: низкая вероятность, высокий ущерб

Самая дорогая ошибка в ранжировании — не переоценка шума. Это округление низковероятной, высокоущербной угрозы до нуля, потому что «этого никогда не случится». Та правая нижняя ячейка матрицы — место, где живёт хвостовой риск, а хвостовой риск — это то, что хоронит компании. Никогда не проверявшийся путь восстановления из бэкапа, SSRF к cloud-metadata, требующий конкретной мисконфигурации, баг с подменой цены, требующий перехвата запроса, — каждый кажется отдалённым, пока в один день условия не сойдутся, и тогда ущерб тотален. Дисциплина в том, чтобы относиться к этой ячейке как к Среднему, а не нулю: она не обгоняет высоковероятную-высокоущербную позицию в этом спринте, но заслуживает отслеживаемого решения — компенсирующего контроля, монитора, алерта, — а не молчаливого пропуска. Сбой именно в молчаливом пропуске: угроза, которую не записали, никогда не будет пересмотрена, и «мы решили, что риск приемлем» — позиция защитимая только тогда, когда есть запись, что вы это решили.

Четыре ответа: снизить, устранить, передать, принять

Ранжированная угроза не закрыта, пока ты не выбрал ответ, и их ровно четыре. Снизить (mitigate) — добавить контроль, уменьшающий вероятность или ущерб: ограничить частоту запросов на сброс пароля, ограничить запрос владельцем, добавить правило WAF. Это частый случай, и он почти никогда не сводит риск к нулю — то, что остаётся, — это остаточный риск, риск, остающийся после контроля. Устранить (eliminate) — удалить функциональность или актив целиком: если SSRF — это функция «загрузить произвольный URL», и продукт может жить без неё, удаление убирает угрозу вместо того, чтобы её сторожить. Самая дешёвая уязвимость для починки — та, которую ты так и не отгрузил. Передать (transfer) — переложить финансовое последствие на кого-то ещё: кибер-страхование или платёжный процессор, владеющий PCI-областью, чтобы утечка карточных данных была по договору их. Передача двигает стоимость, а не событие — утечка всё равно происходит, клиент всё равно затронут, а твою репутацию не застрахуешь. Принять (accept) — решить, что остаточный риск ниже твоей планки, и сознательно ничего не делать, с зафиксированным согласованием от того, у кого есть полномочия владеть этим решением.

Замыкание цикла: хорошо ли мы поработали?

Модель угроз — это живой артефакт, а не документ, который подшивают. Честный закрывающий вопрос — хорошо ли мы поработали? — состоит из двух половин. Первая, проверить модель: покрыли ли мы систему (каждый элемент DFD, каждую границу доверия), нашли ли значимые угрозы и действительно ли меры отгружены и работают? Мера, помеченная «готово» в модели, но так и не влитая, — это ложь, которую наследует следующий рецензент. Вторая, замкнуть цикл во времени: перезапускать модель при изменении архитектуры, скармливать реальные инциденты и находки пентеста обратно для рекалибровки вероятности (угроза, которую ты оценил как «низковероятную» и которая только что произошла, — теперь данные, а не догадка) и переранжировать по мере движения системы и ландшафта угроз. Модель, к которой возвращаются после каждого инцидента и каждой крупной фичи, остаётся правдивой; написанная однажды и положенная на полку устаревает за квартал.