Моделирование угроз
Определи границы модели
- Установи ценные активы, предполагаемых участников, точки входа, потоки данных и изменения доверия или привилегий. Включай фоновую обработку и передачу третьим сторонам, когда они пересекают рассматриваемую границу.
- Отделяй уже подтверждённые защитные меры от предлагаемых мер и предположений. Описывай условия развёртывания, необходимые для существования риска, не считай каждую гипотетическую возможность присутствующей.
- При изменении существующей системы сначала изучи затронутую границу и её зависимости. Небольшая функция не требует заново строить модель угроз всей организации.
Преврати сценарии в решения
- Описывай реалистичное злоупотребление через участника и предпосылку, путь входа, нарушаемое свойство и последствия. Приоритизируй сценарии, которые допускает архитектура, включая злоупотребление со стороны законного пользователя с недостаточными полномочиями.
- Проверь, как идентичности, принадлежность арендатору, асинхронная работа, общие кеши, логи и пути восстановления сохраняют ту же границу доверия. Контроль одной точки входа может не защищать всех потребителей.
- Размещай предотвращение на границе, которую система может контролировать. Укажи, какие риски можно только обнаружить или устранить восстановлением: оповещение не предотвращает само действие.
- Для каждого существенного сценария определи меру защиты и проверку, способную опровергнуть её эффективность. Включай допустимое поведение в критерии приёмки, чтобы запрет всего доступа не считался успехом.
- Зафиксируй остаточный риск, неизвестные предпосылки и ответственного за решение. Избегай численной точности, которую не подтверждают данные о вероятности или влиянии.
Результат
Предоставь компактную модель потоков или границ и приоритизированные сценарии, связанные с защитными мерами, проверкой и открытыми решениями. Используй templates/threat-model.md, если он доступен и полезен. Для небольшого изменения может хватить схемы и нескольких определяющих сценариев.
Модель представляет обоснованную оценку проекта, а не доказательство работоспособности развёрнутой защиты. Не придумывай успешные тесты, не предполагай доступ к секретам или административные права и не превращай защитный анализ сценариев в эксплуатацию уязвимостей на работающей системе.
1---2name: threat-modeling3description: Разобрать сценарии злоупотребления и требования безопасности для предлагаемой системы или существенного архитектурного изменения. Использовать до фиксации проектных решений, а не вместо проверки кода или расследования инцидента.4---56# Моделирование угроз78## Определи границы модели910- Установи ценные активы, предполагаемых участников, точки входа, потоки данных и изменения доверия или привилегий. Включай фоновую обработку и передачу третьим сторонам, когда они пересекают рассматриваемую границу.11- Отделяй уже подтверждённые защитные меры от предлагаемых мер и предположений. Описывай условия развёртывания, необходимые для существования риска, не считай каждую гипотетическую возможность присутствующей.12- При изменении существующей системы сначала изучи затронутую границу и её зависимости. Небольшая функция не требует заново строить модель угроз всей организации.1314## Преврати сценарии в решения15161. Описывай реалистичное злоупотребление через участника и предпосылку, путь входа, нарушаемое свойство и последствия. Приоритизируй сценарии, которые допускает архитектура, включая злоупотребление со стороны законного пользователя с недостаточными полномочиями.172. Проверь, как идентичности, принадлежность арендатору, асинхронная работа, общие кеши, логи и пути восстановления сохраняют ту же границу доверия. Контроль одной точки входа может не защищать всех потребителей.183. Размещай предотвращение на границе, которую система может контролировать. Укажи, какие риски можно только обнаружить или устранить восстановлением: оповещение не предотвращает само действие.194. Для каждого существенного сценария определи меру защиты и проверку, способную опровергнуть её эффективность. Включай допустимое поведение в критерии приёмки, чтобы запрет всего доступа не считался успехом.205. Зафиксируй остаточный риск, неизвестные предпосылки и ответственного за решение. Избегай численной точности, которую не подтверждают данные о вероятности или влиянии.2122## Результат2324Предоставь компактную модель потоков или границ и приоритизированные сценарии, связанные с защитными мерами, проверкой и открытыми решениями. Используй `templates/threat-model.md`, если он доступен и полезен. Для небольшого изменения может хватить схемы и нескольких определяющих сценариев.2526Модель представляет обоснованную оценку проекта, а не доказательство работоспособности развёрнутой защиты. Не придумывай успешные тесты, не предполагай доступ к секретам или административные права и не превращай защитный анализ сценариев в эксплуатацию уязвимостей на работающей системе.
fbakiyev