Threat Modeling і контроль ризиків

1) Принципи

1. Architectural First. Починаємо з контекстів, меж довіри і потоків даних.
2. Risk ≈ Likelihood × Impact. Міряємо, а не відчуваємо.
3. Defense in Depth. Контролі на кожному шарі: код → протокол → платформа → люди.
4. Shift Left/Right. Ранні гейти в PR + моніторинг і реакція в проді.
5. Privacy by Design. Моделюємо не тільки загрози безпеці, а й ризики приватності.
6. Automate Where Possible. Політики як код, автоперевірки, «червоні лінії».

2) Інвентаризація: активи, суб'єкти, межі довіри

Активи: дані (PII, фінанси, секрети), обчислювальні ресурси, ключі, доступи, бізнес-процеси.
Суб'єкти: користувачі, сервіси, адміни, партнери, зовнішні провайдери.
Межі довіри: користувачі ↔ фронт, фронт ↔ API-шлюз, сервіси ↔ БД/кеші/черги, регіони/хмари.
Поверхня атаки: вхідні точки (API, вебхуки, UI, мережі, CI/CD, supply chain).

DFD (приклад, Mermaid):

mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end

3) Фреймворки загроз

STRIDE (безпека): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватність): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (процес): від бізнес-цілей і акторів загроз → технічні деталі → тестові сценарії.

Таблиця (фрагмент, STRIDE × компоненти):

Компонент	S	R	I
API Gateway	mTLS/OIDC, WAF, rate-limit, audit, HSTS
Kafka			ACL, підписані події, квоти, DLQ
Postgres		TLS, RLS, KMS, міграції з валідацією

4) Оцінка ризиків

DREAD/OWASP Risk Rating або CVSS для вразливостей.
Ймовірність (L): мотив/можливості атакуючого, складність, експозиція поверхні.
Вплив (I): фінанси, юрриски, простої, витоки ПД.
Ризик (R = L × I) → пріоритезація і тритмент: Avoid / Reduce / Transfer / Accept.

Матриця (приклад):


Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

Регістр ризиків (мінімум полів): 'id, сценарій, STRIDE, актив, L, I, R, власники, контролі, статус, дата перегляду'.

5) Контролі: Prevent / Detect / Respond

Prevent (запобігання):

Автентифікація/авторизація: OIDC/OAuth2, PoLP, RBAC/ABAC, сервіс-креди короткого терміну.
Секрети/ключі: KMS/HSM, ротація, принцип «не знати», FPE/шифрування полів.
Безпечні протоколи: TLS1. 2 +, mTLS, підписи вебхуків, ідемпотентність і анти-replay.
Валідація/санітарія: схеми (JSON Schema/Proto), ліміти, нормалізація.
Ізоляція: network policies, сегментація, sandbox, namespaces, bulkheads.

Detect (виявлення):

Аудит-логи (невідрікаються), кореляція в SIEM, алерти на аномалії.
Моніторинг підпису та цілісності (експорт хешів артефактів, attestation).
Honeytokens/канарки для раннього детекту витоку ключів.

Respond (реакція):

Runbook IR: класифікація, ізоляція, відгук ключів, оповіщення, форензика.
Автоматичний kill-switch/feature-flag, «чорні списки» токенів.
Повідомлення користувачів/регуляторів при інцидентах з ПД.

6) SDL і гейти безпеки

В ідеї/дизайні: threat model (RFC/ADR), чек-лист контролів.
У розробці: SAST/secret-scan, залежні скани (SCA), політика залежностей.
У збірці: SBOM, підпис артефактів, політика вразливостей (CVSS пороги).
У деплої: OPA/Kyverno - політика IaC/маніфестів (securityContext, мережеві політики, прокидання секретів).
У проді: IDS/WAF, anomaly detection, canary-перевірки, хаос-безпека (наприклад, закінчився сертифікат).

Приклад gate (Policy as Code, псевдо-Rego):

rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}

7) Supply Chain і довіра до артефактів

SBOM на кожен образ/пакет; оновлення залежностей - через бота/політику.
SLSA/Provenance: відтворювані збірки, підписи, attestations.
Контейнери: мінімальні образи, rootless, drop capabilities, read-only FS.
IaC-скани: Terraform/Helm - політика з шифрування, відкритих портів, мережевих правил.

8) Приватність і комплаєнс

LINDDUN-карта загроз приватності, data minimization, псевдонімізація/анонімізація.
Політики зберігання: TTL/ретеншн, «право на видалення», аудит доступу до ПД.
Локалізація: гео-обмеження, «дані залишаються в регіоні».
Прозорість: журнали обробки, повідомлення та згоди.

9) Хмари і периметри

Zero Trust: аутентифікація кожного запиту, mTLS/OPA між сервісами.
Сегментація: VPC/підмережі/SG, приватні ендпоінти, egress-контроль.
Ключі/секрети: KMS, rotation, короткі креди в CI (OIDC-федерація).
Резерв/DR: зашифровані бекапи, ключі окремо, репетиції відновлення.

10) Червоні/фіолетові команди і tabletop-вправи

Red Team: перевірка гіпотез загроз, соціальна інженерія, експлуатація ланцюжків.
Purple Team: спільне налагодження детектів/алертів, поліпшення playbook'ів IR.
Tabletop: сценарії «закінчився сертифікат», «витік ключів», «supply-chain компрометація». Результат - оновлені контролі та метрики.

11) Метрики зрілості та управління

Coverage: % сервісів з актуальним threat model і DFD.
MTTD/MTTR безпеки, частка інцидентів, спійманих контролями.
Policy pass-rate в CI, час закриття вразливостей по критичності.
Приватність: % датасетів з TTL/ILM, частка доступів з обґрунтуванням.
Аудит: регулярність перегляду регістру ризиків (щоквартально).

12) Шаблони артефактів

12. 1 Картка ризику (приклад)


Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High  Impact: High  Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts  Статус: Reduce (в работе)
Дата пересмотра: 2025-12-01

12. 2 Чек-лист дизайну

Ідентифіковані активи та PII? Межі довіри позначені?
DFD/контури даних складені і прив'язані до ADR?
STRIDE/LINDDUN пройдені по кожній стрілці DFD?
Обрано тритмент ризику; є власники/терміни/DoD?
Політики як код додані (OPA/Kyverno/CI-гейти)?
План моніторингу/алертів і IR-runbook оновлені?
Privacy: мінімізація, шифрування, TTL/ретеншн, локалізація?

12. 3 Політика вебхуків (псевдокод)

python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 200

13) Анти-патерни

Threat model «для галочки» без DFD/інваріантів.
«Супер-периметр» без внутрішньої аутентифікації сервісу-к-сервісу.
Довгоживучі секрети в змінних оточення/репо.
Політики, не впроваджені як код → ручне «забувається».
Логи з ПД без маскування і без ретеншну/TTL.
Ігнорування supply chain (немає SBOM/підписів/сканів).
Прийняття ризику (Accept) без власника і дати перегляду.

14) Інтеграція в процеси

RFC/ADR: кожне значуще рішення містить розділ «Загрози і контролі».
Docs-as-Code: threat model, DFD, регістр ризиків у версії поруч з кодом.
Release gates: реліз блокується при провалі SAST/SCA/SBOM-політик або відсутніх контролях високої критичності.
Навчання: плейбуки для розробників (секрети, підписи, PoLP), регулярні tabletop.

Висновок

Threat Modeling - це інженерна практика управління ризиком, а не одноразовий документ. Визначте активи і межі довіри, застосуйте STRIDE/LINDDUN, виміряйте ризик, зафіксуйте його в регістрі і реалізуйте контролі як код, вбудувавши їх в CI/CD і експлуатацію. З метриками зрілості і регулярним переглядом ви перетворите безпеку в передбачувану архітектурну здатність - зі зрозумілою ціною, ефектом і швидкістю.

Threat Modeling і контроль ризиків

Висновок

Зв’яжіться з нами

Швидкий зв’язок

Відео скоро буде оновлено

Зараз ми дуже завантажені проєктами