Полезная модель угроз объясняет, что вы защищаете, кто или что может на это повлиять, где меняется доверие и как вы будете снижать и проверять наиболее важные риски. Начните с реального проекта, а не с общего списка инструментов.
Определите область, достаточно малую для анализа
Начните с одной работающей услуги: клиентского портала, сайта публикаций или внутреннего приложения. Запишите компоненты, которые вы эксплуатируете, и внешние системы, от которых вы зависите. Модель угроз должна делать допущения видимыми, а не создавать впечатление, что все возможные атаки решены. Держите первую версию достаточно малой, чтобы люди, развёртывающие приложение, могли объяснить её без отдельного консультанта, интерпретирующего диаграмму.
Перечислите ценные результаты и активы. Они могут включать данные клиентов, административный доступ, состояние платежей, опубликованный контент и возможность восстановить обслуживание. Доступность может быть активом, даже когда информация публична. Определите, какие сбои были бы неудобны, а какие нанесли бы ущерб людям или организации. Это различие помогает расставлять приоритеты средств контроля вместо того, чтобы относиться ко всем предупреждениям одинаково.
Отметьте места, где меняется доверие
Руководство OWASP по моделированию угроз использует потоки данных и границы доверия, чтобы сделать проект понятным. Для небольшого размещённого приложения нарисуйте браузер, веб-процесс, базу данных, администратора, место назначения резервных копий и внешние интеграции. Отметьте информацию, перемещающуюся между ними. Запрос, переходящий от недоверенного клиента к привилегированной серверной операции, заслуживает явной проверки и авторизации.
Не предполагайте, что нахождение внутри одной машины делает все компоненты одинаково доверенными. Процесс публичной загрузки не должен иметь те же разрешения, что и администрирование базы данных. Заданию резервного копирования может потребоваться доступ на чтение без возможности изменять рабочие записи приложения. Разделение этих ролей упрощает локализацию последствий компрометации компонента и проверку необходимых разрешений.
Выберите конкретные сценарии отказа
Используйте несколько правдоподобных событий, чтобы проверить проект. Злоумышленник крадёт пароль администратора; пользователь запрашивает запись другого пользователя; загрузка заполняет диск; развёртывание раскрывает файл конфигурации; копию для восстановления не удаётся восстановить. Опишите начальное условие, затронутый компонент и последствие. Конкретный сценарий легче проверить, чем общее указание повысить безопасность.
Включайте ошибки и злоупотребление легитимными рабочими процессами, а также внешнее вторжение. Повторная попытка может создать две ценные операции, или два запроса могут соревноваться за изменение одного объекта. Руководство OWASP по бизнес-логике освещает эти допущения процесса. Проверьте, кому разрешено переводить рабочий процесс в следующее состояние и меняет ли повторение или изменение порядка запроса результат неожиданным образом.
| Сценарий | Средство контроля для исследования | Какие доказательства собрать |
|---|---|---|
| Украденные учётные данные администратора | Ограниченный доступ и второй фактор, где поддерживается | Неавторизованный вход не может завершиться |
| Запрошен объект другого пользователя | Серверная авторизация объектов | Изолированный тест возвращает отказ |
| Диск исчерпан загрузками | Контроль размера, квот и хранения | Ограничение применяется до отказа обслуживания |
| Дублирующий запрос рабочего процесса | Идемпотентность и границы транзакций | Повторный запрос создаёт один результат |
Расставьте приоритеты по влиянию и правдоподобному пути
Для каждого сценария запишите его потенциальное влияние и условия, необходимые для его возникновения. Не делайте вид, что предположительная числовая оценка является точной вероятностью. Вы всё равно можете отличить слабый пароль, доступный из интернета, от локального события с множеством условий. Назначьте владельца и практический следующий шаг для важных рисков, чтобы модель создавала работу, которую кто-то действительно может выполнить.
Учитывайте жизненный цикл информации, а также компрометацию приложения. Диагностический экспорт может раскрыть ненужные данные при обычной работе. Сохранённое поле учётной записи может создавать риск спустя долгое время после окончания его цели. Поэтому проверка конфиденциальности может удалить информацию или сократить срок хранения, а проверка безопасности ограничивает доступ к тому, что осталось. Оба изменения принадлежат модели, когда они защищают проект.
Проверьте средства контроля в авторизованной среде
Создайте промежуточную среду с репрезентативными разрешениями и вымышленными записями. Проверьте отказ в доступе, ограничения запросов, повторы рабочих процессов и восстановление. Не используйте реальные данные клиентов, когда синтетические данные могут продемонстрировать поведение. Цель — проверить средство контроля, а не создать впечатляющий атакующий трафик. Оставайтесь в пределах систем, которыми вы владеете или которые вам явно разрешено оценивать.
Запишите, что прошло, что не прошло и что осталось неизвестным. Результат сканера может служить доказательством, но не заменяет проверку бизнес-правил приложения. Аналогично, опция сетевой защиты не проверяет авторизацию объектов или обработку секретных файлов. Прикрепите полезные результаты к сценарию, чтобы будущие сопровождающие понимали, почему существует конкретное средство контроля.
Поддерживайте связь модели с изменениями
Проверяйте соответствующие части при добавлении интеграции, раскрытии новой конечной точки, изменении привилегии или перемещении данных в другое место назначения. Вам не нужно перерисовывать всю архитектуру из-за незначительного изменения текста. Триггером является изменённое допущение о доступе, информации или поведении системы. Держите модель рядом с документацией по развёртыванию и восстановлению, а не оставляйте её как результат одноразового семинара.
SwissOctet предлагает каталог вариантов инфраструктуры, а не готовую модель угроз приложения. Выберите конфигурацию и опции, поддерживающие ваши средства контроля, затем проверьте созданное развёртывание. Небольшая поддерживаемая модель с проверенными действиями полезнее большого набора продуктов безопасности без ясного объяснения рисков, которые они устраняют.
Ваш практический чек-лист.
- Перечислите активы и последствия отказа.
- Нарисуйте потоки данных и границы доверия.
- Выберите конкретные сценарии вторжения, ошибки и рабочего процесса.
- Назначьте средства контроля и владельцев для важных рисков.
- Проверьте с синтетическими данными в авторизованной среде.
- Пересматривайте модель при изменении соответствующего допущения.
Детали, которые важны.
Нужна ли мне формальная методология для начала?+
Нет. Небольшая диаграмма и документированный набор сценариев могут быть полезны. Методология помогает обеспечить последовательный анализ рисков.
Заменяет ли сканер уязвимостей моделирование угроз?+
Нет. Сканеры могут находить технические слабости, тогда как модель угроз также исследует проектные допущения, разрешения и бизнес-процессы.
Как часто следует обновлять модель?+
Обновляйте затронутые части при изменении потоков данных, интеграций, привилегий или раскрытой функциональности и регулярно пересматривайте нерешённые риски.
Перейдите к источнику.
Эти источники поддерживают технические концепции в этом руководстве. Следуйте актуальной документации, прежде чем менять производственную систему.
- OWASP: Шпаргалка по моделированию угроз cheatsheetseries.owasp.org
- OWASP: Моделирование угроз на практике devguide.owasp.org
- OWASP: Безопасность бизнес-логики cheatsheetseries.owasp.org
Редакционное руководство от SwissOctet. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно.