Modéliser et contrôler les risques

1) Principes

1. Architectural First. Nous commençons par les contextes, les limites de confiance et les flux de données.
2. Risk ≈ Likelihood × Impact. Nous mesurons, pas nous sentons.
3. Defense in Depth. Contrôles sur chaque couche : code → protocole → plate-forme → personnes.
4. Shift Left/Right. Les premiers gates dans PR + surveillance et réaction dans la vente.
5. Privacy by Design. Nous simulons non seulement les menaces à la sécurité, mais aussi les risques à la vie privée.
6. Automate Where Possible. Les politiques sont comme un code, des tests automobiles, des lignes rouges.

2) Inventaire : actifs, sujets, limites de confiance

Actifs : données (PII, finances, secrets), ressources informatiques, clés, accès, processus métiers.
Sujets : utilisateurs, services, admins, partenaires, fournisseurs externes.
Limites de confiance : utilisateurs ↔ front, front ↔ API Gateway, services ↔ bases de données/caches/files d'attente, régions/nuages.
Surface d'attaque : points d'entrée (API, webhooks, UI, réseaux, CI/CD, chaîne d'approvisionnement).

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) Cadres de menaces

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (processus) : des objectifs commerciaux et des acteurs de la menace → des détails techniques → des scénarios de test.

4) Évaluation des risques

DREAD/OWASP Risk Rating ou CVSS pour les vulnérabilités.
Probabilité (L) : motif/capacités de l'attaquant, complexité, exposition de la surface.
Impact (I) : finances, droit, temps d'arrêt, fuites de PD.
Risque (R = L × I) → priorité et 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

Registre des risques (minimum de champs) : 'id, script, STRIDE, actif, L, I, R, propriétaires, contrôleurs, statut, date de révision'.

5) Contrôles : Prevent/Detect/Respond

• Authentification/autorisation : OIDC/OAuth2, PoLP, RBAC/ABAC, crédits de service à court terme.
• Secrets/clés : KMS/HSM, rotation, principe de « ne pas savoir », FPE/cryptage de champs.
• Protocoles sécurisés : TLS1. 2 +, mTLS, signatures Web, idempotence et anti-replay.
• Validation/assainissement : schémas (JSON Schema/Proto), limites, normalisation.
• Isolation : politiques de réseau, segmentation, sandbox, namespaces, bulkheads.

• L'audit-logs (non-élucidé), la corollation dans le SIEM, les alertes sur les anomalies.
• Surveillance de la signature et de l'intégrité (exportation d'artefacts hachés, attestation).
• Honeytokens/canaris pour le détail précoce de la fuite de clés.

• Runbook IR : classification, isolation, rappel de clés, alertes, forensica.
• Automatique kill-switch/feature-flag, « listes noires » de tokens.
• Notifications aux utilisateurs/régulateurs en cas d'incidents de DP.

6) SDL et gates de sécurité

Dans l'idée/la conception : modèle de threat (RFC/ADR), chèque de contrôle.
En développement : SAST/secret-scan, scans dépendants (SCA), politique de dépendance.
Dans l'assemblage : SBOM, signature d'artefacts, stratégie de vulnérabilité (seuils CVSS).
OPA/Kyverno est une politique IaC/manifeste (securityContext, stratégies réseau, secret).
Dans la vente : IDS/WAF, détection d'anomalie, contrôles canariaux, sécurité de chaos (par exemple, certificat expiré).

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 et la confiance dans les artefacts

SBOM par image/paquet ; mises à jour des dépendances - via bot/politique.
SLSA/Provence : assemblages reproductibles, signatures, attestations.
Conteneurs : images minimales, rootless, drop capabilities, read-only FS.
Analyse IaC : Terraform/Helm est une politique de chiffrement, de port ouvert, de règles réseau.

8) Vie privée et conformité

Carte LINDDUN des menaces à la vie privée, minimisation des données, pseudonymisation/anonymisation.
Politiques de conservation : TTL/rétention, « droit de suppression », vérification de l'accès au PD.
Localisation : géo-contraintes, « les données restent dans la région ».
Transparence : registres de traitement, de notification et de consentement.

9) Nuages et périmètres

Zero Trust : authentification de chaque requête, mTLS/OPA entre les services.
Segmentation : VPC/sous-réseaux/SG, endpoints privés, contrôle egress.
Clés/secrets : KMS, rotation, crédits courts en CI (fédération OIDC).
Reserve/DR : backups cryptés, clés séparées, répétitions de récupération.

10) Commandes rouges/violettes et exercices tabletop

Red Team : vérification des hypothèses de menaces, ingénierie sociale, exploitation des chaînes.
Purple Team : débogage conjoint des détails/alerts, amélioration du playbook de l'IR.
Tabletop : les scénarios "étaient expirés par le certificat", "la fuite des clés", "supply-chain компрометация". Le résultat est une mise à jour des contrôles et des métriques.

11) Métriques de maturité et gestion

Coverage :% des services avec le modèle threat actuel et DFD.
MTTD/MTTR de sécurité, proportion d'incidents pris par les contrôleurs.
Policy pass-rate dans CI, heure de fermeture des vulnérabilités par criticité.
Vie privée :% de datacets avec TTL/ILM, proportion d'accès avec justification.
Audit : régularité de la révision du registre des risques (trimestriel).

12) Modèles d'artefacts

12. 1 Carte de risque (exemple)

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 Chèque-feuille de conception

Actifs identifiés et IPI ? Les limites de confiance sont-elles marquées ?
DFD/contours de données établis et liés à l'ADR ?
STRIDE/LINDDUN parcourus sur chaque flèche DFD ?
Le tritment de risque est sélectionné ; y a-t-il des propriétaires/des délais/DoD ?
Comment le code est-il ajouté (OPA/Kyverno/CI-gates) ?
Plan de surveillance/alertes et RI-runbook mis à jour ?
Privacy : minimisation, cryptage, TTL/rétention, localisation ?

12. 3 La politique des webhooks (pseudo-code)

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-modèles

Modèle Threat « pour cocher » sans DFD/invariants.
« Super-périmètre » sans authentification interne du service-à-service.
Secrets à longue durée de vie dans les variables d'environnement/repo.
Les politiques qui ne sont pas incorporées comme code → sont « oubliées » manuellement.
Logs avec PD sans camouflage et sans retenti/TTL.
Ignorer la chaîne d'approvisionnement (pas de SBOM/signatures/scans).
Acceptation du risque (Accept) sans propriétaire et date de révision.

14) Intégration dans les processus

RFC/ADR : chaque décision importante contient une section « Menaces et contrôles ».
Docs-as-Code : threat model, DFD, registre des risques dans la version à côté du code.
Release gates : La release est bloquée en cas d'échec d'une politique SAST/SCA/SBOM ou de contrôle de criticité élevée manquant.
Formation : playbooks pour développeurs (secrets, signatures, PoLP), tabletop régulier.

Conclusion

Threat Modeling est une pratique d'ingénierie de gestion des risques, pas un document unique. Identifiez les actifs et les limites de confiance, appliquez STRIDE/LINDDUN, mesurez le risque, enregistrez-le dans le registre et implémentez les contrôles comme code en les intégrant dans CI/CD et l'exploitation. Avec des mesures de maturité et une révision régulière, vous transformerez la sécurité en une capacité architecturale prévisible - avec un prix, un effet et une vitesse compréhensibles.