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