Defense in Depth

Plusieurs barrières indépendantes : si une cède, les suivantes tiennent. Le contraire de la stratégie « un mur très épais qu'on prie de ne pas voir tomber ».

Problème

Reposer la sécurité sur une seule défense (firewall périmétrique, antivirus, IPS) crée un point unique d'échec : sa compromission expose l'ensemble du système. Or aucune défense n'est infaillible (CVE 0-day, mauvaise configuration, ingénierie sociale). Comment limiter l'impact d'une faille découverte ?

Forces

• Toute défense isolée finit par tomber (CVE 0-day, social engineering, supply chain).
• L'attaquant n'a besoin que d'une faille ; le défenseur doit fermer toutes les portes.
• Empiler trop de défenses redondantes alourdit l'opérationnel et masque les vrais incidents.
• Une faille en couche N doit déclencher la détection en couche N+1 (alerte précoce).
• Les contraintes réglementaires (PCI-DSS, HDS, ISO 27001) imposent souvent plusieurs couches.

Solution

Empiler plusieurs couches de contrôle indépendantes — chacune protégeant contre la défaillance des autres. Le principe vient de la doctrine militaire (lignes de défense successives) et s'applique en sécurité informatique : réseau (firewall, IDS), application (WAF, validation entrée), identité (MFA, RBAC), donnée (chiffrement, classification), monitoring (SIEM, anomaly detection), réponse (IR plan, backups). Chaque couche doit utiliser une mécanique différente (pas 3 firewalls de la même marque qui partagent les mêmes CVE).

Couches typiques

Internet
   │
   ▼
┌──────────────────────────────────────────┐
│ Couche 1: Edge — DDoS, WAF, CDN          │
├──────────────────────────────────────────┤
│ Couche 2: Network — Firewall, segmentation │
├──────────────────────────────────────────┤
│ Couche 3: Endpoint — EDR, OS hardening   │
├──────────────────────────────────────────┤
│ Couche 4: Identity — SSO, MFA, RBAC      │
├──────────────────────────────────────────┤
│ Couche 5: App — Input validation, WAF L7 │
├──────────────────────────────────────────┤
│ Couche 6: Data — Encryption, masking     │
├──────────────────────────────────────────┤
│ Couche 7: Monitoring — SIEM, audit logs  │
└──────────────────────────────────────────┘

Implémentation EDI

Un hub EDI accepte des INVOIC AS2 entrants. Couches successives : (1) WAF / DDoS sur l'edge (Cloudflare, Akamai) ; (2) endpoint AS2 avec mTLS et IP allow-list ; (3) vérification de signature S/MIME applicative — le certificat partenaire est vérifié contre une CA dédiée et un CRL/OCSP ; (4) parsing strict EDIFACT qui rejette toute structure invalide ; (5) validation métier (montants cohérents, partenaire connu) ; (6) archivage chiffré (AES-256, KMS) ; (7) audit log immuable et alerte sur anomalie. Une faille à la couche 3 (cert compromis) est rattrapée à la couche 5 (volumes ou patterns anormaux).

Anti-patterns

• Couches redondantes mais homogènes — 3 firewalls Cisco partagent les mêmes CVE.
• Couche unique « ultime » sans plan B — pari risqué.
• Multiplication des contrôles sans monitoring — l'attaquant teste tranquillement.
• Couches périmétriques sans contrôles internes — la philosophie Zero Trust est ignorée.
• Faux sens du sécurisé après empilement — l'overhead masque que les couches sont mal configurées.

Patterns liés

• Zero Trust Architecture — instance moderne de Defense in Depth.
• Least Privilege — réduit la portée d'une couche compromise.
• Bulkhead — équivalent pour la résilience.
• Secrets Management — couche identité protégée séparément.

Sources

• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems. NIST SP 800-53r5 PDF
• NSA — Defense in Depth: A practical strategy, Information Assurance Solutions Group.
• OWASP Cheat Sheet — Defense in Depth. cheatsheetseries.owasp.org