Зачем при моделировании угроз описывать злоупотребления, а не только штатные сценарии системы?
Злоупотребления показывают, как легитимные функции могут быть использованы против целей безопасности: конфиденциальности, целостности или доступности. Без таких сценариев модель описывает, что система должна делать, но не проверяет, что произойдёт при намеренно вредоносном использовании тех же возможностей.
Традиционные требования к системе обычно формулировались через успешные пользовательские сценарии: создать объект, получить данные, выполнить операцию. Такой подход полезен для функционального проектирования, но сам по себе не заставляет рассматривать нештатные действия пользователя или скомпрометированной стороны.
Моделирование злоупотреблений появилось как практическое дополнение к функциональному анализу безопасности. Оно переводит угрозу из абстрактного утверждения «система может быть атакована» в проверяемый сценарий: кто действует, каким доступным механизмом, на какой актив воздействует и какой ущерб возникает.
Одна и та же функция может быть безопасной в штатном сценарии и опасной при злоупотреблении. Например, массовая выгрузка данных может быть нужна администратору, но стать способом незаметного сбора персональной информации при краже его сессии.
Если описаны только нормальные сценарии, команда может не проверить ограничения частоты, объёма, последовательности операций, контекста пользователя и обнаружения аномалий. Последствие — формально работающая функция, через которую можно обойти бизнес-ограничения или получить больший ущерб, чем предполагалось архитектурой.
Сначала фиксируют штатный сценарий и защищаемый актив. Затем формулируют злоупотребление как изменение одного условия: легитимный пользователь превышает предназначенный объём операции, злоумышленник использует украденный сеанс или доверенный участник обращается к функции в запрещённом контексте.
Для каждого сценария нужно определить:
Злоупотребление не означает, что вся функция должна быть запрещена. Обычно выбирают комбинацию ограничений: проверку бизнес-контекста, минимальные полномочия, лимиты, подтверждение рискованной операции, журналирование и оповещение. Важно связать каждую меру с конкретным сценарием, иначе список контролей превращается в формальность.
У подхода есть ограничение: злоупотребления не заменяют технический анализ уязвимостей, проверку реализации и тестирование. Сценарии также могут разрастись до неуправляемого списка, поэтому их приоритизируют по ценности актива, реализуемости атаки и тяжести последствий. Слишком широкие сценарии плохо проверяются, а слишком узкие могут пропустить другой путь к тому же ущербу.
Система позволяет сотруднику экспортировать отчёт по клиентам. Штатный сценарий выглядит корректно: сотрудник выбирает доступный подраздел и получает файл. При анализе злоупотреблений обнаруживается другой сценарий: сотрудник многократно экспортирует небольшие отчёты, меняя фильтры, чтобы постепенно собрать данные всего подразделения.
Рассматривались три варианта. Полностью запретить экспорт — просто реализовать, но это ломает рабочий процесс. Ограничить только размер одного файла — недостаточно, поскольку данные можно разделить на серии запросов. Разрешать экспорт при проверке области доступа, совокупного объёма за период, цели операции и с журналированием — сложнее, зато контролирует именно выявленный способ злоупотребления.
Выбран третий вариант. Для обычных отчётов сохранили экспорт, а превышение совокупного лимита или необычная последовательность запросов переводит операцию на дополнительное подтверждение и создаёт событие для расследования. Так модель злоупотреблений повлияла не на внешний вид функции, а на её ограничения, наблюдаемость и реакцию на риск.
Ответ: Нет. Важны не только тип субъекта, но и его реальные полномочия, доступные интерфейсы, знания и возможность действовать через доверенные компоненты. Сотрудник, партнёрский сервис, пользователь с украденной сессией и скомпрометированный администратор создают разные злоупотребления даже при обращении к одной функции.
Ответ: Негативный тест обычно проверяет отдельное некорректное значение или нарушение технического контракта. Сценарий злоупотребления рассматривает цель, последовательность действий, полномочия и ущерб. Поэтому он может требовать не только отклонить запрос, но и ограничить частоту, связать операции с бизнес-контекстом, зафиксировать событие или инициировать реакцию.
Ответ: Не всегда. Несколько способов можно объединить, если они используют один и тот же актив, приводят к сопоставимому ущербу и требуют одинаковых защитных мер. Разделять их нужно, когда отличаются границы доверия, необходимые полномочия, механизм обнаружения или решение о допустимом риске; иначе один сценарий скроет важное различие в контролях.