Concepts et menaces

Le 2 novembre 1988, un étudiant de Cornell libère sur ARPANET un programme de quatre-vingt-dix lignes. Il ne détruit rien, ne vole rien, ne chiffre rien : il se copie. Une erreur de paramètre le fait se recopier bien plus vite que prévu, et en une nuit il immobilise environ 10 % des machines connectées au réseau. Robert Morris sera le premier condamné au titre du Computer Fraud and Abuse Act, et son ver donnera naissance au premier CERT.

Trois choses de ce cours tiennent déjà dans cette histoire. Une attaque n'a pas besoin de voler quoi que ce soit pour faire des dégâts — c'est la disponibilité qui est tombée. L'écart entre l'intention et l'effet ne relève pas de la technique mais du droit. Et la défense organisée est née après l'incident, ce qui reste vrai aujourd'hui de la plupart des organisations.

Ce premier chapitre n'exploite rien. Il installe le vocabulaire et la méthode sans lesquels les neuf suivants seraient une collection de recettes : ce qu'on protège, contre qui, par où, et dans quel cadre on a le droit de le vérifier.

Ce qu'on protège : quatre propriétés, pas une

La sécurité ne se mesure jamais « en général ». Elle se décompose en propriétés nommées, dont chacune se perd indépendamment des autres.

L'acronyme français DICT — parfois DICP, avec la preuve à la place de la traçabilité — vaut mieux que le CIA anglo-saxon parce qu'il nomme la quatrième. Sans traçabilité, un incident n'est pas analysable : on constate le résultat sans pouvoir reconstituer le chemin, et le chapitre 9 sera sans objet.

Deux erreurs classiques méritent d'être défaites tout de suite.

Les propriétés ne se déduisent pas les unes des autres. Un fichier chiffré peut être supprimé — confidentialité intacte, disponibilité perdue. Une base parfaitement disponible peut avoir été modifiée par un attaquant — et si personne ne s'en aperçoit, la perte d'intégrité coûte plus cher qu'une fuite, parce que l'organisation continue de décider sur des données fausses.

Elles entrent en conflit. Le contrôle le plus sûr pour la confidentialité — refuser tout le monde — détruit la disponibilité. Une politique de mot de passe extrême produit des mots de passe écrits sur des feuilles collées aux écrans. La sécurité n'est pas la maximisation d'une propriété, c'est un arbitrage explicite entre les quatre, et cet arbitrage appartient au métier, pas à l'équipe technique. C'est le fond du chapitre 10.

Quatre mots qu'on ne doit plus confondre

Le vocabulaire du risque est le seul de ce cours qu'on emploie devant une direction. Le confondre coûte cher : c'est la différence entre un rapport qu'on lit et un rapport qu'on classe.

Un actif est ce qui a de la valeur : une base clients, un serveur de paie, une marque, la disponibilité d'un site de vente. C'est le point de départ, et l'oublier est l'erreur des débutants — on se met à sécuriser ce qui est technique plutôt que ce qui compte.

Une vulnérabilité est une faiblesse : un logiciel non corrigé, un mot de passe par défaut, une procédure qui autorise un virement sur simple courriel. Elle existe indépendamment de tout attaquant.

Une menace est un événement redouté associé à une source capable de le provoquer : un concurrent qui veut le fichier clients, un rançongiciel opportuniste, un employé qui part en emportant des données, un incendie. Une menace sans vulnérabilité correspondante ne se réalise pas ; une vulnérabilité sans menace ne coûte rien.

Le risque est ce qui reste quand on les croise, pondéré par les conséquences :

1risque ≈ vraisemblance (menace × vulnérabilité) × gravité (impact sur l'actif)

Le signe ≈ est important. Cette formule n'est pas un calcul, c'est une grille de discussion : les deux facteurs s'estiment sur des échelles à quatre niveaux, jamais en euros à la décimale. Une méthode complète — EBIOS Risk Manager, ISO 27005 — organise cette estimation ; le chapitre 10 la conduira en entier.

La conséquence pratique est immédiate : on ne corrige pas les vulnérabilités par ordre de gravité technique, mais par ordre de risque. Une faille critique sur un serveur de test isolé passe après une faille moyenne sur le portail de paiement. Un score CVSS de 9,8 n'est pas un ordre de mission ; c'est un des facteurs de la vraisemblance.

Qui attaque, et ce que cela change

Le mot « pirate » ne décrit rien. Ce qui décrit, c'est le couple motivation × moyens, parce que c'est lui qui dit ce contre quoi vous pouvez espérer tenir.

Deux enseignements sortent de ce tableau, et ils vont dans des sens opposés.

Le premier est rassurant : l'immense majorité des attaques ne vous vise pas. Elles balaient Internet et prennent ce qui cède. Contre elles, l'hygiène élémentaire — correctifs appliqués, pas de service inutile exposé, pas de mot de passe par défaut, sauvegardes testées — suffit à changer de catégorie de victime.

Le second l'est moins : contre un attaquant étatique déterminé, la question n'est pas de tenir mais de détecter. Il a plus de temps et d'argent que vous, il achètera un accès ou compromettra un fournisseur. L'objectif réaliste devient la réduction du temps de présence, qui se mesure en jours et non en mois — d'où le poids donné à la traçabilité et au chapitre 9.

Le cas de l'attaquant interne mérite une mention à part, parce qu'il défait toutes les défenses périmétriques du chapitre 6 : il est déjà à l'intérieur, et ses actions sont légitimes une par une. C'est le moindre privilège du chapitre 3, la séparation des tâches et la journalisation qui répondent — pas le pare-feu.

La surface d'attaque

La surface d'attaque est l'ensemble des points par lesquels un attaquant peut interagir avec le système. Elle se compte, et c'est la seule mesure de sécurité qui se réduit directement par une action.

Elle a trois faces, et on n'en voit couramment qu'une :

• Réseau — ports ouverts, services exposés, API publiques, accès distants, objets connectés.
• Logicielle — code applicatif, dépendances tierces, interpréteurs, formats de fichiers acceptés.
• Humaine — personnes joignables par courriel ou téléphone, prestataires, sous-traitants.

Trois principes de réduction, dans l'ordre d'efficacité :

1. Supprimer ce qui n'est pas nécessaire. Un service désinstallé n'a aucune vulnérabilité. C'est la seule mesure dont l'efficacité ne se dégrade pas avec le temps.
2. Restreindre ce qui reste. Un service qui n'écoute que sur 127.0.0.1 a une surface proche de zéro, à coût nul.
3. Cloisonner ce qui doit rester exposé, pour que sa compromission ne donne pas le reste. C'est le rôle de la zone démilitarisée et de la segmentation, au chapitre 6.

Notez ce que ces trois principes ont en commun : aucun ne consiste à ajouter un produit de sécurité. La première réponse à une surface d'attaque trop large n'est pas un pare-feu de plus, c'est un inventaire — et l'inventaire est presque toujours faux, parce que personne ne sait plus quelles machines existent.

La chaîne d'attaque

Une intrusion réelle n'est pas un exploit unique : c'est une suite d'étapes, dont chacune prépare la suivante. Le modèle le plus employé en enseignement est la cyber kill chain, ici ramenée à cinq phases ; en pratique professionnelle, la matrice MITRE ATT&CK décrit les mêmes étapes avec beaucoup plus de détail, et sert de langage commun entre attaque et défense.

L'intérêt du modèle n'est pas descriptif, il est stratégique, et tient dans une asymétrie qu'il faut avoir comprise avant toute la suite du cours :

L'attaquant doit réussir toutes les phases. Le défenseur n'a besoin d'en casser qu'une.

C'est ce qui rend la défense en profondeur rationnelle plutôt que paranoïaque. On ne mise pas sur un mur parfait, on multiplie les occasions de détecter et d'interrompre le long de la chaîne. Et c'est ce qui explique le poids donné à la détection en phase 2 et 3 : plus on intercepte tôt, moins l'incident coûte — la différence entre un poste réinstallé et une restauration complète de l'entreprise.

Le cadre légal et l'éthique du test d'intrusion

Ce cours vous apprendra à exploiter des vulnérabilités. Cette compétence est légale ; son exercice sur un système qui ne vous appartient pas ne l'est pas. La frontière n'est pas technique, et elle ne dépend ni de votre intention ni des dégâts causés.

En droit français, la loi Godfrain du 5 janvier 1988 a introduit les articles 323-1 et suivants du code pénal :

• accéder ou se maintenir frauduleusement dans un système : deux ans d'emprisonnement et 60 000 € d'amende — portés à trois ans et 100 000 € si des données sont altérées ;
• entraver le fonctionnement d'un système, ou introduire, modifier, supprimer frauduleusement des données : cinq ans et 150 000 € ;
• détenir ou mettre à disposition un outil conçu pour commettre ces infractions : puni également, avec une réserve pour la recherche et la sécurité informatique.

Trois points sont contre-intuitifs et tombent régulièrement à l'examen.

« Se maintenir » suffit. Découvrir un accès par hasard est une chose ; y rester pour regarder en est une autre, et c'est déjà l'infraction. La bonne conduite est de sortir immédiatement et de signaler.

L'absence de dégât n'est pas une défense. L'infraction est constituée par l'accès, pas par le préjudice. La quantifier sert à fixer la peine, pas à l'écarter.

Un système mal protégé reste protégé en droit. L'argument « la porte était ouverte » a été jugé et rejeté ; il ne vous protégera pas. Symétriquement, la loi pour une République numérique de 2016 protège en France celui qui signale de bonne foi une faille à l'ANSSI — mais elle protège le signalement, pas l'exploration qui l'a précédé.

Le cadre exact dépend du pays. La convention de l'Union africaine sur la cybersécurité et la protection des données à caractère personnel — dite convention de Malabo, adoptée en 2014 et entrée en vigueur en 2023 — engage les États parties à incriminer les mêmes actes, et plusieurs États ont adopté des lois nationales sur la cybercriminalité. Vérifiez le droit applicable là où vous êtes ; les principes ci-dessous, eux, n'en dépendent pas.

Ce qui rend un test licite tient en quatre exigences, et aucune n'est facultative :

1. Une autorisation écrite du propriétaire du système, signée avant le premier paquet.
2. Un périmètre explicite : adresses, domaines, comptes, horaires. Ce qui n'y figure pas est hors autorisation, même si c'est techniquement accessible depuis le périmètre.
3. Des limites d'action : ce que vous n'avez pas le droit de faire — déni de service, ingénierie sociale, exfiltration réelle de données de production.
4. Une conduite en cas de découverte grave : à qui signaler, dans quel délai, et l'arrêt immédiat en cas de compromission préexistante constatée.

Dans ce cours, tout ce que vous exploiterez tournera dans un environnement isolé — machines virtuelles, réseau fermé, applications volontairement vulnérables du type DVWA ou Juice Shop — et vous signerez une charte d'usage en début de semestre. Ce n'est pas une formalité administrative : c'est la première fois que vous rédigez le périmètre d'un test, et c'est exactement le document que vous signerez plus tard, côté prestataire ou côté client.

À vous

L'exercice ci-dessous n'exploite rien : vous êtes analyste, après coup. On vous remet les journaux d'un incident réel, réduits à onze événements sur vingt-huit jours.

Replacez chaque événement dans sa phase, puis répondez à la seule question qui compte pour l'organisation : à partir de quand cette attaque était-elle détectable ?

// Vingt-huit jours de journaux, réduits à ce qui compte.
//
// Chaque ligne est un événement observé quelque part dans le système
// d'information. Votre travail : replacer chaque événement dans la phase de
// la chaîne d'attaque à laquelle il appartient, puis dire à quelle date
// l'attaque devenait détectable.

const JOURNAL = [
  { jour: 1,  source: "web",      evenement: "412 requêtes depuis une même IP vers /wp-login.php, /admin, /.git/config" },
  { jour: 2,  source: "web",      evenement: "consultation de la page Équipe : 34 fiches, 34 adresses de courriel" },
  { jour: 6,  source: "courriel", evenement: "message « Facture_Mars.docm » à 12 comptables, expéditeur usurpé" },
  { jour: 6,  source: "poste",    evenement: "WINWORD.EXE lance powershell.exe -enc <base64>" },
  { jour: 6,  source: "reseau",   evenement: "poste-comptable-04 ouvre une connexion sortante TLS vers 185.x.x.x:443" },
  { jour: 7,  source: "poste",    evenement: "création du service Windows « WinDefendUpd », démarrage automatique" },
  { jour: 7,  source: "poste",    evenement: "clé de registre Run ajoutée pour l'utilisateur mkonate" },
  { jour: 9,  source: "annuaire", evenement: "mkonate ajouté au groupe Administrateurs du domaine" },
  { jour: 11, source: "fichiers", evenement: "lecture de 8 400 fichiers du partage RH en 40 minutes" },
  { jour: 12, source: "reseau",   evenement: "4,2 Go sortis vers 185.x.x.x, par blocs de 20 Mo, entre 2 h et 5 h" },
  { jour: 14, source: "poste",    evenement: "chiffrement de masse, note de rançon déposée sur 60 postes" },
];

// Les cinq phases, dans l'ordre.
const PHASES = ["reconnaissance", "intrusion", "persistance", "escalade", "exfiltration"];

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Complétez classer() : rendez le nom de la phase pour chaque événement.
//    Indice : ce n'est pas la source qui décide, c'est ce que l'attaquant
//    est en train d'obtenir.
// 2. Répondez à la question du bas : à partir de quel jour l'attaque
//    était-elle détectable par un défenseur attentif ?

function classer(e) {
  return "reconnaissance"; // à compléter
}

const premierJourDetectable = 14; // à corriger

// ── Vérification ──────────────────────────────────────────────────────────
console.log("Reconstitution de l'attaque\n");
let phasePrecedente = null;
for (const e of JOURNAL) {
  const phase = classer(e);
  const marque = phase === phasePrecedente ? "  " : "▸ ";
  console.log(marque + "J" + String(e.jour).padStart(2) + " [" + phase.padEnd(14) + "] " + e.evenement.slice(0, 62));
  phasePrecedente = phase;
}
console.log("\nDétectable à partir de J" + premierJourDetectable);
console.log("Exfiltration constatée à J12, rançongiciel à J14.");
console.log("Coût de la détection tardive :", 14 - premierJourDetectable, "jours d'avance perdus.");

Ce que la suite en fait

Ce chapitre a posé une grille, et les neuf suivants la remplissent.

Le chapitre 2 outille la confidentialité et l'intégrité par la cryptographie. Les chapitres 3 et 4 traitent le contrôle d'accès et le durcissement du système — les phases d'intrusion, de persistance et d'escalade. Les chapitres 5 et 6 prennent le réseau, en attaque puis en défense. Les chapitres 7 et 8 descendent dans l'applicatif, où se trouve aujourd'hui la majorité de la surface exploitable. Le chapitre 9 traite ce qui arrive quand tout cela a échoué, et le chapitre 10 remet l'ensemble en ordre de risque.

Gardez la chaîne d'attaque sous les yeux : chaque technique de ce cours occupe une case précise, et savoir laquelle vaut mieux que savoir la technique.

À retenir