Triade CIA et modèles de menaces

Prérequis (cursus dev) : défense en profondeur.

Pourquoi

« Sécuriser » sans modèle, c'est empiler des outils au hasard. La triade CIA dit quoi protéger, le threat modeling dit contre qui : tout le cursus en découle.

Concepts

• CIA : Confidentialité (qui peut lire ?), Intégrité (qui peut modifier ? peut-on détecter ?), Disponibilité (ça répond quand il faut ?). Chaque incident se lit dans ce triangle : fuite = C, défacement = I, DDoS = A.
• Threat modeling : lister assets (données, accès), attaquants (script kiddie ? concurrent ? état ? ex-employé ?), vecteurs et impacts. 1 heure en début de projet > 100 heures après.
• Surface d'attaque : tout ce qui est exposé et interrogeable (ports, endpoints, formulaires, headers qui bavardent, .git exposé !). La réduire avant de la défendre.

Exemple : modéliser en 20 minutes

Assets : base users (emails + hash), sessions, backups
Attaquants : bots (botnet), curieux (IDOR), ex-presta (accès restants)
Vecteurs : login (brute-force), reset password (token ?), API sans auth ?, backups non chiffrés ?
Priorités : 1) auth/rate-limit 2) secrets/accès 3) durcissement

Cas réel

Audit « tout est chiffré, tout va bien » : backups S3 publics en lecture (surface oubliée), 2M d'emails aspirés. Le chiffrement protégeait le transport, pas l'exposition. La surface se cartographie (ss, scan externe, inventaire buckets), pas se suppose.

Pièges

• Protéger contre « les hackers » en général : sans attaquants nommés, pas de priorités — juste de l'anxiété et des outils.
• Oublier l'insider (ex-employé, prestataire) : la moitié des fuites viennent de dedans (accès non révoqués !).
• Sécurité = produit fini (« on fera un audit avant la sortie ») : l'audit valide, il ne construit pas. Le modeling est en continu.

À retenir

CIA pour classer, menaces nommées pour prioriser, surface cartographiée avant d'être défendue.