La plupart des attaques réussissent parce qu'un principe de sécurité connu depuis des décennies n'a pas été appliqué. Un serveur exposé sans pare-feu, un compte administrateur partagé, une application aux droits trop larges : ces situations ne sont pas des fatalités. Ce module, le premier de la formation, pose les principes qui rendent un système résistant, avec un exemple concret pour chacun. Il s'adresse à une personne qui débute en sécurité, sans aucun prérequis technique, et il prépare tout le reste : comprendre une attaque suppose de savoir ce qu'on cherche à protéger et par quels moyens.
Ces principes ne s'appliquent pas isolément, ils se renforcent mutuellement. Le schéma les regroupe en familles autour de la triade CIA, le but commun.
Dans quel ordre lire les principes ?
Section intitulée « Dans quel ordre lire les principes ? »Le module va du but vers les moyens. Il s'ouvre sur le vocabulaire : la leçon Menace, risque, vulnérabilité, attaque, partagée avec la formation DevSecOps, distingue la faiblesse, ce qui peut l'exploiter et ce qu'on risque de perdre. Vient ensuite ce que l'on protège : la triade CIA pose les trois propriétés à préserver (confidentialité, intégrité, disponibilité), complétées par le critère de preuve (DICP) et par le modèle AAA. Les types de mesures donnent enfin le vocabulaire pour décrire n'importe quelle protection : technique, organisationnelle ou physique, préventive, détective ou corrective. Avec ces trois leçons, vous pouvez nommer ce qui menace et ce que vous défendez, puis classer ce que vous mettez en place.
Les leçons suivantes sont des principes de conception, chacun répond à une question. Pour réduire l'exposition, la surface d'attaque liste les prises offertes à un attaquant, et la minimisation, leçon facultative, enlève tout ce qui n'est pas nécessaire. Pour limiter les dégâts, le moindre privilège réduit les droits de chaque compte, et la séparation des privilèges cloisonne les rôles. Pour penser l'architecture, la sécurité par défaut refuse tout sauf ce qui est autorisé, la défense en profondeur empile les couches, le Zero Trust vérifie chaque accès. Le module se termine par la non-répudiation, qui permet de prouver qui a fait quoi, puis par les référentiels de la sécurité (NIST, ISO, CIS, ANSSI), les catalogues publiés où l'on retrouve ces principes et ces types de mesures. La leçon facultative sur le refus de la sécurité par l'obscurité vient en dernier : elle montre pourquoi seule la clé doit rester secrète, jamais le mécanisme.
Comment distinguer les principes qui se ressemblent ?
Section intitulée « Comment distinguer les principes qui se ressemblent ? »Plusieurs leçons parlent de réduire ou de limiter, et il est facile de les confondre. Chaque paire a une frontière nette.
La surface d'attaque, la minimisation et la sécurité par défaut réduisent toutes l'exposition, mais pas au même moment. La surface d'attaque est un inventaire : elle apprend à compter les points d'entrée. La minimisation est une règle de retrait : ne garder que le nécessaire, en composants, en données et en droits. La sécurité par défaut est une règle de configuration initiale : ce qui n'est pas autorisé est refusé dès l'installation. Le moindre privilège et la séparation des privilèges touchent aux droits : le premier limite ce qu'un compte peut faire, la seconde empêche qu'un seul compte cumule plusieurs rôles critiques. Une application peut respecter l'un sans l'autre.
Le Zero Trust de ce module présente le principe général : ne jamais accorder de confiance implicite, vérifier chaque accès. Sa mise en oeuvre dans les clouds publics a son propre guide, Zero Trust cloud, à lire après la leçon du module. Enfin, la défense en profondeur est le principe d'assemblage : elle combine tous les autres, en couches, pour qu'aucune faille ne soit fatale.
Que couvre la formation au-delà de ce module ?
Section intitulée « Que couvre la formation au-delà de ce module ? »Deux principes appartiennent à la formation DevSecOps plutôt qu'à celle-ci : la confiance transitive, qui rappelle qu'on hérite du risque de toutes ses dépendances, et la dette de sécurité, qui mesure le coût des raccourcis accumulés. Les citer ici donne la vue d'ensemble, les étudier suppose de connaître la chaîne de livraison logicielle.
Ces principes sont le pourquoi ; ils se traduisent ensuite en contrôles concrets. Le modèle de menaces SOCLE montre contre quelles attaques ils protègent, et le durcissement des serveurs comme la sécurité réseau les mettent en oeuvre. Le deuxième module de la formation, complet, prend le point de vue de l'attaquant : la kill chain, le déroulé d'une intrusion en sept phases, commence avec Comprendre les phases d'une cyberattaque, puis le référentiel MITRE ATT&CK situe chaque phase parmi les techniques réelles. À chaque phase, vous y réemployez les principes de ce module pour placer un contrôle, et une épreuve sur papier termine le niveau.
À retenir
Section intitulée « À retenir »Ce module donne une grille de lecture qui sert à juger n'importe quelle mesure de sécurité, quel que soit l'outil :
- Menace, vulnérabilité, attaque et risque sont quatre notions distinctes : on gère le risque, on ne l'élimine pas.
- La triade CIA dit ce que l'on protège : confidentialité, intégrité, disponibilité.
- Les types de mesures disent comment on protège : prévenir, détecter, corriger.
- Surface d'attaque, minimisation et sécurité par défaut réduisent l'exposition, à trois moments différents.
- Moindre privilège et séparation des privilèges limitent les dégâts d'un compte compromis.
- La défense en profondeur assemble les autres principes en couches, et le Zero Trust vérifie chaque accès.
- La non-répudiation permet de prouver après coup qui a fait quoi.
- Les référentiels (NIST, ISO, CIS, ANSSI) rassemblent ces principes et ces mesures dans des catalogues publiés, à utiliser comme une carte.