Modelarea amenințărilor și controlul riscurilor
1) Principii
1. Arhitectural First. Începem cu contexte, limite de încredere și fluxuri de date.
2. Riscul ≈ probabilitatea × impact. Măsurăm, nu simţim.
3. Apărare în profunzime. Controale pe fiecare strat: cod → protocol → platformă → persoane.
4. Shift stânga/dreapta. Porți timpurii în PR + monitorizare și reacție în prod.
5. Confidențialitate prin design. Simulăm nu numai amenințările de securitate, ci și riscurile de confidențialitate.
6. Automatizați acolo unde este posibil. Politici ca cod, verificări automate, „linii roşii”.
2) Inventar: active, entități, limite de încredere
Active: date (PII, finanțe, secrete), resurse de calcul, chei, accesări, procese de afaceri.
Subiecte: utilizatori, servicii, administratori, parteneri, furnizori externi.
Limite de încredere: utilizatorii ↔ față, față ↔ gateway API, servicii ↔ baze de date/cache/cozi, regiuni/nori.
Suprafata de atac: puncte de intrare (API, carti web, UI, retele, CI/CD, lant de aprovizionare).
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 end3) Cadre de amenințare
STRIDE (безопасность): Spoofing, Manipulare, Repudiere, Dezvăluire de informații, Refuzul de serviciu, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identificability, Non-repudiere, Detectabilitate, Dezvăluire, Inconștiență, Neconformitate.
PASTA (proces): de la obiectivele de afaceri și actorii de amenințare → detalii tehnice → scenarii de testare.
4) Evaluarea riscurilor
DREAD/OWASP Rating de risc sau CVSS pentru vulnerabilități.
Probabilitatea (L): motivul/capacitățile atacatorului, complexitatea, expunerea la suprafață.
Impact (I): finanțe, riscuri juridice, timpi morți, scurgeri PD.
Risc (R = L × I) → prioritizare și tritment: Evitați/reduceți/transferați/acceptați.
Impact
Low Med High Critical
Lik Low L L M H
Med L M H H
High M H High CritRegistrul de risc (câmpuri minime): 'id, scenariu, STRIDE, activ, L, I, R, proprietari, controale, stare, data reviziei'.
5) Controale: Preveni/Detecta/Răspunde
Preveni:- Autentificare/autorizare: OIDC/OAuth2, PoLP, RBAC/ABAC, credite de servicii pe termen scurt.
- Secrete/chei: KMS/HSM, rotație, nu știu, FPE/criptare câmp.
- Protocoale securizate: TLS1. 2 +, mTLS, semnături webhook, idempotență și anti-reluare.
- Validare/salubrizare: scheme (Schema JSON/Proto), limite, normalizare.
- Izolare: politici de rețea, segmentare, sandbox, namespaces, pereți etanși.
- Jurnalele de audit (de nerecunoscut), corelarea în SIEM, alerte la anomalii.
- Monitorizarea semnăturii și integrității (exportul de hashes artefact, atestare).
- Miere/canari pentru detectarea timpurie a scurgerilor de chei.
- Runbook IR: clasificare, izolare, rechemare cheie, alerte, criminalistică.
- Kill-switch automat/feature-flag, „liste negre” de jetoane.
- Notificările utilizatorilor/autorităților de reglementare în cazul incidentelor PD.
6) Porțile SDL și de securitate
În idee/design: model de amenințare (RFC/ADR), lista de verificare a comenzilor.
În dezvoltare: SAST/secret-scan, scanări de dependență (SCA), politica de dependență.
În asamblare: SBOM, semnătură artefact, politica de vulnerabilitate (praguri CVSS).
În domeniul: OPA/Kyverno - IaC/manifest policy (securityContext, network policies, secret forwarding).
În vânzări: IDS/WAF, detectarea anomaliilor, verificări canare, securitate haos (de exemplu, certificat expirat).
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) Lanțul de aprovizionare și încrederea în artefacte
SBOM per imagine/pachet; actualizări de dependență - prin intermediul bot/policy.
SLSA/Proveniență: ansambluri reproductibile, semnături, atestate.
Containere: imagini minime, fără rădăcini, capabilități de cădere, numai citire FS.
IaC scanează: Terraform/Helm - politică de criptare, porturi deschise, reguli de rețea.
8) Confidențialitate și conformitate
LINDDUN-hartă a amenințărilor la adresa vieții private, minimizarea datelor, pseudonimizare/anonimizare.
Politici de retenție: TTL/retenție, „dreptul de a șterge”, auditul accesului la PD.
Localizare: geo-limitări, „datele rămân în regiune”.
Transparență: procesare, notificare și consimțământ jurnale.
9) Nori și perimetre
Zero Trust: autentificarea fiecărei cereri, mTLS/OPA între servicii.
Segmentare: VPC/subrețele/SG, puncte finale private, control de ieșire.
Chei/secrete: KMS, rotație, credite scurte în CI (federația OIDC).
Rezervă/DR: copii de rezervă criptate, chei separat, repetiții de recuperare.
10) Echipe roșii/violet și exerciții de masă
Echipa roșie: testarea ipotezei amenințării, ingineria socială, exploatarea în lanț.
Purple Team: depanarea comună a detecțiilor/alertelor, îmbunătățirea cărților de redare IR.
Tabletop: scripturi "certificat expirat", "chei scurgeri", "compromis lanț de aprovizionare. "Rezultatul este actualizarea controalelor și a măsurătorilor.
11) Măsurarea și gestionarea maturității
Acoperire:% din serviciile cu modelul actual de amenințare și DFD.
Siguranța MTTD/MTTR, proporția incidentelor prinse de controale.
Rata de trecere a politicilor în CI, timpul de închidere a vulnerabilităților prin criticalitate.
Confidențialitate:% din seturile de date cu TTL/ILM, cota de acces cu justificare.
Audit: regularitatea revizuirii registrului de risc (trimestrial).
12) Modele artefact
12. 1 Card de risc (exemplu)
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-0112. 2 Lista de verificare a designului
Active și PII identificate? Limitele de încredere marcate?
DFD-urile/buclele de date sunt compuse și mapate la ADR-uri?
STRIDE/LINDDUN traversat fiecare săgeată DFD?
Tritment de risc selectat; au proprietari/termene limită/DoD?
Politici adăugate ca cod (OPA/Kyverno/CI gates)?
Planul de monitorizare/alerte și IR-runbook actualizat?
Confidențialitate: minimizare, criptare, TTL/retenție, localizare?
12. 3 Politica de broșură web (Pseudocode)
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 20013) Anti-modele
Modelul de amenințare „pentru spectacol” fără DFD/invarianți.
„Super-perimetru” fără autentificare internă service-to-service.
Secrete de lungă durată în variabile de mediu/repo.
Politicile nu sunt încorporate ca cod → manual „uitat”.
Busteni cu PD fara camuflaj si fara retentie/TTL.
Ignorarea lanțului de aprovizionare (fără SBOM/semnături/scanări).
Acceptați fără proprietar și data revizuirii.
14) Integrarea în procese
RFC/ADR - Fiecare soluţie semnificativă conţine o secţiune Ameninţări şi Controale.
Docs-as-Code: model de amenințare, DFD, registru de risc în versiunea de lângă cod.
Porți de eliberare: eliberarea este blocată atunci când politicile SAST/SCA/SBOM eșuează sau controalele de înaltă severitate lipsesc.
Training: playbook-uri pentru dezvoltatori (secrete, semnături, PoLP), tabletop regulat.
Concluzie
Modelarea amenințărilor este o practică inginerească de gestionare a riscurilor, nu un document unic. Definiți active și limitele de încredere, aplicați STRIDE/LINDDUN, măsurați riscul, înregistrați-l și implementați controale ca cod prin încorporarea lor în CI/CD și operare. Cu măsurători de maturitate și revizuire regulată, veți transforma siguranța într-o abilitate arhitecturală previzibilă - cu preț, efect și viteză ușor de înțeles.