Security Architecture Vocabulary: Threat Modeling, STRIDE, Zero Trust, and Defense-in-Depth (англійською)
Необхідний словник з архітектури безпеки для інженерів і архітекторів: моделювання загроз, STRIDE, PASTA, дерева атаки, межі довіри, аналіз поверхні атаки, проектування нульової довіри і мова перегляду проектування безпеки.
Архітектура безпеки - це те, де дизайн програмного забезпечення зустрічається з суперечливим мисленням. На відміну від операційної безпеки або тестування на помилку, словник архітектури безпеки стосується мови * розробки * систем, які мають бути безпечними з самого початку — слів, які ви використовуєте у семінарах з моделювання загроз, переглядів архітектури, документів з розробки безпеки і обговорень прийняття ризиків.
Цей словник використовується щодня архітекторами безпеки, старшими інженерами в чутливих до безпеки областях (платежі, охорона здоров’я, ідентичність) і інженерними лідерами, які беруть участь у перегляді дизайну безпеки.
Розділ 1: Моделювання загроз
Моделювання загроз Структурований процес ідентифікації, аналізу та зменшення загроз безпеки під час фази проектування — до того, як система буде побудована або змінена. Мета: знайти проблеми безпеки, коли їх найдешевше виправити.
- “Перед тим, як створити нову функцію вивантаження файлів, давайте запустимо модель загрози. Нам потрібно визначити, що атакуючий може зробити зі зловмисним завантаженням, перш ніж ми напишуть будь-який код. ”*
Погроза Суб’ єкт, який становить загрозу: зовнішній нападник, злочинець, автоматизований бот, національна держава або конкурент. Визначення того, які чинники загрози є в сфері впливу, допомагає зосередити рішення щодо проектування.
- “Наша модель загрози розглядає три учасники: зовнішніх нападників (анонімних, інтернет), автентифікованих, але зловмисних користувачів (внутрішній ризик) і стороннього постачальника, який піддався компромісу. Державні актори не мають права на цей продукт».*
Вектор атаки Метод або шлях, який використовує злочинець для доступу до системи. Поширені вектори: мережа (віддалене виконання коду, SSRF), фізична (крадіжка пристроїв), ланцюг постачання програмного забезпечення, соціальна інженерія.
- “Вектор атаки тут — SSRF — атакуючий обманює наш сервер, щоб він зробив запит до нашої внутрішньої кінцевої точки метаданих. Нам потрібно заблокувати запити на 169.254.0.0/16 від процесора завантаження.”*
Погроза Потенційна подія, яка може завдати шкоди системі. Визначається як: учасник загрози, який використовує вектор атаки для використання вразливості, що призведе до впливу.
“Загроза: неавтентифікований зовнішній атакуючий використовує вразливість пересування шляху в кінцевій точці звантаження файлів для читання довільних файлів з сервера, включаючи налаштування, що містять дані реєстрації бази даних.”
Смягчение Контроль або контрзахід, що зменшує ймовірність або вплив загрози. Зменшення ризику може бути профілактичним (заборонити успішну атаку), детективним (визначити, коли відбувається атака) або корекційним (обмежити збитки після атаки).
- “Зменшення загрози SSRF: (1) Перевірити всі адреси URL за допомогою списку дозволених, (2) Використовувати окрему мережу тільки для виходу для URL- захоплення без доступу до внутрішньої мережі, (3) Увімкнути захист SSRF на кінцевій точці хмарних метаданих.” *
Розділ 2: STRIDE і PASTA Frameworks
- СТОРОНИЦА Функціональна модель класифікації загроз, розроблена компанією Microsoft. Акронім для шести категорій загроз:
- Spoofing — олігофренія іншого користувача або системи
- Tampering — зміна даних або коду
- Репутація — заперечення того, що дія відбулася
- ** Розкриття інформації — виявлення конфіденційних даних
- ** D ** N O S — зниження доступності системи
- ** Підвищення привілеїв — отримання більших прав доступу, ніж передбачалося
STRIDE застосовується до кожного компонента в системній діаграмі для систематичного виявлення загроз.
“Запуск STRIDE проти API-шлюзу: Сфабрикування → чи перевірені підписи JWT? Підробка → чи підписано тіло запиту? Відкидання → чи слід записувати у журнал дії автентифікованих користувачів без відкидання? Розкриття інформації → чи витікає відповідь на помилку з слідів стека? Ми знайшли три прогалини за 20 хвилин.»
** PASTA (Процес імітації атаки та аналізу загроз) ** Система моделювання загроз, орієнтованих на ризик, з сімома етапами, від визначення бізнес- цілей до імітації атаки. Більш жорсткий, ніж STRIDE для систем високого ризику. Використовується в регульованих галузях (фінансові послуги, охорона здоров’я).
- “Для системи обробки платежів ми використовували PASTA, тому що нам потрібен був повний аналіз ризиків щодо впливу на бізнес, а не просто перелік загроз. STRIDE не врахував би загрози бізнес-контексту.»*
Дерево атаки Ієрархічна діаграма, яка показує, яким чином атакуючий може досягти мети (кореневий вузол), розбитої на підмети (гілки), з’ єднані вузлами І і ТАКОЖ. І вузли вимагають, щоб всі під- цілі були досягнуті; або вузли вимагають будь- яку під- ціль. Використовується для систематичного відображення шляхів атаки і визначення найпростіших шляхів для атакуючого.
- “Дерево атаки для « атакуючий читає PII клієнта » показує дві гілки ІЛИ: (1) використовувати введення SQL у кінцевій точці пошуку, або (2) скомпрометувати машину розробника і використовувати їхні дані доступу до бази даних. Гілка 1 є шляхом більшого ризику — ми звертаємося до неї першою.»*
Розділ 3: Довірчі межі і поверхня атаки
** Границя довіри ** Межа на системній діаграмі, де дані перетинаються між зонами різних рівнів довіри, наприклад, між мережею Інтернет (без довіри) і сервером програми (частково довіряють) або між сервером програми і базою даних (довіряють). Кожне перетинання межі довіри потребує перевірки.
- “Межа довіри знаходиться на шлюзі API. Все, що перетинає вхід з Інтернету, має бути перевірено на відповідність нашій вхідній схемі перед досягненням логічного шару бізнесу. Ніщо з інтернету не йде безпосередньо до рівня даних.»*
** Зона довіри (Зона безпеки) ** Сегмент мережі або програми, у якому компоненти мають подібні рівні довіри і права доступу. Спільні зони: DMZ, що має доступ до Інтернету (найменша довіра), рівень програм, рівень даних (найвища довіра) і відокремлена зона адміністрування.
- “Ми використовуємо три зони довіри: для інтернету (API- шлюз, CDN), для програм (мікросервіси — без прямого доступу до інтернету) і для даних (бази даних, секретні сховища — доступні лише з зони програми). Бокові рухи через межі зон вимагають чітких правил.”*
Принцип найменших привілеїв Кожен компонент, користувач і служба повинні мати лише мінімальні права доступу, необхідні для виконання їх функцій. Зменшує радіус вибуху, якщо компонент був порушений.
- “Служба обробки зображень має роль IAM з дозволом на читання з вхідного контейнера S3 і запис до вихідного контейнера — нічого більше. Якщо служба була порушена, нападник не може отримати доступ до бази даних або інших служб. *
** Атакуюча поверхня ** Сума всіх точок входу (код, API, порти, інтерфейси, вхідні дані), за допомогою яких неавторизований користувач може спробувати взаємодіяти з системою. Менша площа атаки означає менше місць для захисту.
“Ми зменшили площу атаки, вилучивши внутрішню адміністративну кінцеву точку HTTP і замінивши її однією автентифікованою кінцевою точкою gRPC на нестандартному порту, доступному тільки з мережі VPN ops.”
Зменшення площі атаки Практика навмисного зменшення поверхні атаки за допомогою вимикання не використовуваних можливостей, закриття не використовуваних портів, вилучення не використовуваних залежностей і обмеження доступу до відкритих інтерфейсів.
“Контрольний список зменшення поверхні атаки: вимкніть не використовувані методи HTTP на API (TRACE, PATCH, OPTIONS, крім CORS), вилучіть адмініструючі кінцеві точки з публічної служби, прикріпіть версії залежностей, щоб запобігти атакам ланцюга постачання.”
Розділ 4: Глибинна оборона
Глибинна оборона Стратегія архітектури безпеки, яка використовує декілька незалежних засобів безпеки на різних рівнях — так, що якщо один з засобів безпеки не спрацює, інші все одно захистять систему. Ніякого порушення безпеки.
“Наша глибока оборона для веб- API: (1) WAF на краю, (2) автентифікація API- шлюзів, (3) перевірка вводу в службі, (4) параметризовані запити, що запобігають введенню SQL, (5) користувач бази даних тільки для читання для запитів звітів. Атакуючий повинен обійти всі п’ять шарів.”
Контроль безопасности Захист або контрміра, що зменшує ризик безпеки. Класифікація:
- ** Захист: ** блокує атаку (брандмауэром, автентифікацією)
- ** Детектив: ** виявляє атаку (попередження SIEM, виявлення аномалій)
- ** Коригування: ** обмежує шкоду після атаки (автоматичне відкликання, відновлення знімка)
- Компенсація: Альтернативне керування, коли первинне неможливе
- “Ми не можемо залатати компонент цього місяця — компенсаційним контролем є мережева ізоляція: ми пересуваємо його в обмежену VLAN без вихідного доступу до Інтернету і записуємо всі вхідні з’ єднання.” *
Компенсаторний контроль Керування безпекою, яке забезпечує еквівалентний захист, коли стандартне керування не може бути застосовано. Використовується, коли вразливість не можна негайно лагодити, або коли застаріла система не підтримує стандартний контроль.
- “PCI DSS вимагає TLS 1. 2+, але POS- термінал підтримує лише TLS 1. 0. Компенсаційний контроль: термінал комунікує тільки через спеціальний зашифрований тунель до платіжного шлюз, з мережевим моніторингом аномалій.”*
Розділ 5: Zero Trust Architecture
Нулевая доверчивость Модель безпеки, за якої типово не буде надійним жодний об’ єкт — ні всередині, ні за межами периметра мережі. Кожен запит доступу аутентифікується, авторизується і постійно перевіряється, незалежно від розташування в мережі.
*“Ми перейшли до нульової довіри — використання корпоративного VPN більше не надає доступу до внутрішніх служб. Кожне викликання між службами вимагає чинного сертифіката mTLS, і кожен користувач людини вимагає атестації пристрою + автентифікації SSO. *
“Ніколи не довіряй, завжди перевіряй” Основний принцип нульової довіри: ніколи не надавати неявної довіри на основі розташування у мережі. Завжди перевіряти ідентичність, стан пристрою і авторизацію перед надання доступу.
Микросегментація Розділення мережі на невеликі сегменти з суворим контролем доступу між кожним сегментом. При нульовій довірі навіть зв’язок між внутрішніми службами вимагає явної авторизації. Обмежує горизонтальний рух, якщо одна служба буде порушена.
- “Ми використовуємо мікросегментацію на рівні мережі служб — кожна служба має мережеву політику, яка дозволяє вхідні з’ єднання лише з певних служб, які мають потребу викликати її. Компрометована служба розрахунків не може безпосередньо досягти користувача».*
За Корпорацією Мережева модель нульового довіри Google (опублікована 2014 року, тепер доступна як BeyondCorp Enterprise). Виключає концепцію VPN: весь доступ здійснюється за допомогою проксі- сервера доступу, який здійснює автентифікацію пристрою і користувача, надає доступ лише до певних програм і вимагає постійної перевірки.
- “Ми переходимо від VPN до моделі BeyondCorp - VPN занадто грубозернистий. Зловмисники, що використовують VPN, отримують доступ до всієї внутрішньої мережі. З BeyondCorp, компрометовані дані доступні тільки для конкретних застосунків, для яких авторизований пристрій користувача. “*
Розділ 6: Перегляд мови дизайну безпеки
** Перегляд дизайну безпеки** Формальний перегляд архітектури та дизайну системи для вразливостей безпеки і відповідності стандартам безпеки — проводиться перед реалізацією або перед основними змінами. Відрізняється від перегляду безпеки коду (який перевіряє реалізацію).
- “Перед тим, як ми об’ єднаємо архітектуру нового платіжного шлюз, нам потрібен перегляд дизайну безпеки. Ми запустимо STRIDE, перевіримо перетин меж довіри і перевіримо на нашу базу безпеки. ”*
Прийняття ризику Формальна рішення визнати залишковий ризик (ризик, що залишається після застосування заходів зменшення) і продовжувати в будь-якому випадку - зазвичай тому, що витрати на зменшення перевищують очікуваний вплив.
- “Після зменшення ризику, залишковий ризик шляху вивантаження файла оцінено як низький — атака вимагає зловмисного PDF, який обходить наше двоетапне сканування. Бізнес прийняв цей залишковий ризик, враховуючи низьку ймовірність і вартість додаткової інфраструктури сканування. ”*
** Прийняти / Зменшити / Виправити / Перенести ** Чотири відповіді на ризики у керуванні ризиками безпеки:
- Прийняти: визнавати і терпіти ризик
- ** Зменшити: ** зменшити ризик за допомогою контролю
- ** Виправлення: ** повне усунення вразливості
- ** Передача: ** Передача ризику третій стороні (страхування, SLA постачальника)
“Для вразливості стороннього SDK: ми не можемо її виправити (виправлення виробника триває 3 місяці), ми зменшуємо її за допомогою правил WAF, що блокують шаблон атаки, і переносимо залишковий ризик через нашу політику кіберстрахування. Ми документуємо прийняття з підписом CISO.”
** Червоний/Жовтий/Зелений (RAG) Рейтинг безпеки ** Якісний рейтинг ризику: 🟢 Зелений = прийнятний ризик, 🟡 Бурштиновий = потребує зменшення до виробництва, 🔴 Червоний = неприйнятний ризик, повинен бути вирішений або ескалація до CISO.
“Відповідно до моделі загрози, ми отримали 2 червоних, 4 бурих і 8 зелених результатів. Ми не перейдемо до виробництва, поки обидва червоні не будуть вирішені. “
Зв’язані ресурси
- Словник безпеки: 40 термінів — фундаментальний словник безпеки
- Англійська для інженерів безпеки — ролево-специфічна комунікація
- Як писати пост-морт англійською — написання звіту про інцидент
- Практика лексикографії — вправи з словниковим запасом