Threat Modeling e controllo dei rischi

1) Principi

1. Architectural First. Cominciamo con contesti, limiti di fiducia e flussi di dati.
2. Risk ≈ Likelihood × Impact. Lo misuriamo, non lo proviamo.
3. Defense in Depth. Controllati su ogni livello, codice, protocollo, piattaforma di controllo.
4. Shift Left/Right. Gate precoci in PR + monitoraggio e risposta in vendita.
5. Privacy by Design. Modelliamo non solo le minacce alla sicurezza, ma anche i rischi alla privacy.
6. Automate Where Possible. Regole come codice, automezzi, linee rosse.

2) Inventario: beni, entità, limiti di fiducia

Risorse: dati (PII, finanza, segreti), risorse informatiche, chiavi, disponibilità, processi aziendali.
Soggetti: utenti, servizi, admini, partner, provider esterni.
Limiti di fiducia: utenti del fronte ↔, ↔ ↔ API, servizi di database/cache/coda, regioni/nuvole.
Superficie d'attacco: punti di ingresso (API, webhoop, UI, reti, CI/CD, supply chain).

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) Cornici di minaccia

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA - Gli obiettivi aziendali e gli attrezzi di minaccia ano i dettagli tecnici e gli script di prova.

4) Valutazione dei rischi

DREAD/OWASP Risk Rating o CVSS per le vulnerabilità.
Probabilità (L) - Movente/capacità dell'attaccante, complessità, esposizione della superficie.
Influenza (I): finanza, giurisprudenza, inattività, fughe di PD.
Rischio (R = L x I) priorità e tritment: 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

Registro dei rischi (minimo campi): 'id, script, STRIDE, attivo, L, I, R, proprietari, controllori, stato, data di revisione'.

5) Controllori: Prevent/Detect/Respond

• Autenticazione/autorizzazione: OIDC/OAuth2, PoLP, RBAC/ABAC, crediti di servizio di breve durata.
• I segreti/chiavi sono KMS/HSM, rotazione, non sapere, FPE/crittografia dei campi.
• Protocolli sicuri: TLS1. 2 +, mTLS, firme di webhook, idampotenza e anti-replay.
• Convalida/igiene: schemi (JSON Schema/Proto), limiti, normalizzazione.
• Isolamento: network policies, segmentazione, sandbox, namespades, bulkheads.

• Logi di controllo (non rigettati), corazzamento in SIEM, alert su anomalie.
• Monitoraggio della firma e dell'integrità (esportazione di manufatti hash, attestation).
• Honeytokens/canarini per il primo bambino di perdita delle chiavi.

• Runbook IR: classificazione, isolamento, richiamo delle chiavi, avvisi, forense.
• Kill-switch automatico/feature-flag, «black list» dei token.
• Notifiche di utenti/controllori in caso di incidenti con il PD.

6) SDL e gate di sicurezza

In idea/design: threat model (RFC/ADR), foglio di controllo.
In sviluppo: SAST/secret-scan, scan delle dipendenze (SCA), criterio delle dipendenze.
Nell'assieme: SBOM, firma manufatti, soglia CVSS (CVSS).
L'OPA/Kyverno è una politica IaC/Manifesto (securityContext, regole di rete, interruzioni di segreti).
In vendita: IDS/WAF, anataly detection, controlli canary, caos-sicurezza (ad esempio, certificato scaduto).

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 e fiducia nei manufatti

SBOM per ogni immagine/pacchetto; aggiornamenti delle dipendenze tramite bot/criteri.
SLSA/Provenance - Assemblaggi riprodotti, firme, attrazioni.
Contenitori: immagini minime, rootless, drop capabilities, read-only FS.
IaC-Scan: Terraform/Helm - Criteri di crittografia, porte aperte, regole di rete.

8) Privacy e compliance

Mappa LINDDUN delle minacce alla privacy, data minimization, alias/anonimizzazione.
Criteri di conservazione: TTL/Reimpostazione, diritto di eliminazione, controllo dell'accesso al PD.
Localizzazione: geo-vincoli, «i dati rimangono nella regione».
Trasparenza: registri di elaborazione, notifica e consenso.

9) Nuvole e perimetri

Zero Trust - Autenticazione di ogni richiesta, mTLS/OPA tra i servizi.
Segmentazione: VPC/subnet/SG, endpoint privati, egress control.
Chiavi/segreti: KMS, rotation, crediti brevi in CI (OIDC).
Backup crittografati, chiavi separate, prove di recupero.

10) Comandi rossi/viola ed esercizi tabletop

Test delle ipotesi di minacce, ingegneria sociale, gestione delle catene.
Purple Team: il debug congiunto di dati/alert, il miglioramento del playbook IR.
Tabletop: script «certificato scaduto», «chiave fuoriuscita», «compromissione supply-chain». Risultato: controlli e metriche aggiornati.

11) Metriche di maturità e controllo

Coverage:% di servizi con threat model e DFD aggiornati.
MTTD/MTTR di sicurezza, percentuale di incidenti catturati dai controllori.
Policy pass-rate in CI, tempo di chiusura delle vulnerabilità per criticità.
Privacy:% di dataset con TTL/ILM, percentuale di disponibilità con giustificazione.
Controllo: regolarità della revisione del registro dei rischi (trimestrale).

12) Modelli di manufatti

12. 1 Scheda di rischio (esempio)

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 Assegno-foglia di progettazione

Beni identificati e PII? I limiti della fiducia sono segnati?
I tracciati DFD/dati sono stati compilati e collegati a ADR?
STRIDE/LINDDUN hanno superato ogni freccia DFD?
Trittment di rischio selezionato; ci sono proprietari/date/DoD?
Quali criteri sono stati aggiunti (OPA/Kyverno/CI-gate)?
Il piano di monitoraggio/alert e l'IR-runbook sono stati aggiornati?
Privacy: minimizzazione, crittografia, TTL/retensh, localizzazione?

12. 3 Criteri di webhoop (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 200

13) Anti-pattern

Threat model per spunta senza DFD/invarianti.
«Super perimetro» senza autenticazione interna del servizio-a-servizio.
Segreti a lunga vita nelle variabili ambientali/repo.
Regole non incorporate come codice «manuale».
Loghi con PD senza occultamento e senza retenschn/TTL.
Ignora supply chain (nessun SBOM/firme/scene).
Accettazione del rischio senza proprietario e data di revisione.

14) Integrazione nei processi

RFC/ADR: ogni soluzione rilevante contiene la sezione «Minacce e controlli».
Docs-as-Code: threat model, DFD, minuscolo dei rischi nella versione accanto al codice.
Release gates: il rilascio viene bloccato in caso di fallimento di SAST/SCA/SBOM o di controlli ad alta criticità mancanti.
Formazione: playbook per sviluppatori (segreti, firme, PoLP), tabelletop regolari.

Conclusione

Threat Modeling è una pratica ingegneristica per la gestione dei rischi, non un documento monouso. Definire le risorse e i limiti della fiducia, applicare STRIDE/LINDDUN, misurare il rischio, fissarlo nel registro e implementare i controlli come codice, inserendoli in CI/CD e funzionamento. Con le metriche di maturità e la revisione regolare, trasformerete la sicurezza in una prevedibile capacità architettonica, con un prezzo, un effetto e una velocità comprensibili.