Le 7 septembre, Equifax a annoncé une intrusion pouvant toucher environ 143 millions de consommateurs américains. Noms, adresses, dates de naissance et numéros permanents font partie des données que les victimes ne peuvent pas simplement remplacer. Le risque dépend autant de la collecte et de la durée que de la faille initiale.

Une application Web reçoit une requête, la fait passer dans un framework, appelle services et base. Une vulnérabilité connue dans une composante exposée peut permettre l’exécution de code, puis l’attaquant cherche identifiants, bases et chemins de sortie. Un correctif existe seulement si l’inventaire relie composante, version, système et propriétaire.

Réduire la fenêtre et le rayon

Un programme de vulnérabilités devrait :

1. découvrir les applications exposées;
2. produire une nomenclature de dépendances;
3. recevoir les avis et relier les versions;
4. classer selon exposition et donnée;
5. corriger en environnement de test;
6. déployer avec preuve;
7. scanner pour confirmer;
8. surveiller exploitation et extraction;
9. gérer chaque exception avec date.

Le scan externe et l’inventaire interne se complètent. Une application oubliée ne reçoit pas de ticket. Une alerte sans propriétaire n’est pas un contrôle. Le délai de correction pour une faille activement exploitable sur Internet doit être beaucoup plus court qu’une faiblesse locale mineure.

La segmentation et le moindre privilège limitent ce qu’un serveur compromis peut lire. Les données sensibles sont séparées, chiffrées et leurs clés protégées ailleurs. Le chiffrement au repos ne sert pas si l’application compromise peut demander toutes les lignes; les requêtes massives et volumes sortants doivent alerter.

Concevoir la vie de la donnée

Pour chaque champ, je demanderais pourquoi il est collecté, combien de temps, qui le reçoit et comment le corriger. Une donnée permanente crée une dette permanente. La tokenisation peut remplacer certains identifiants dans les systèmes qui n’en ont pas besoin.

Après une intrusion, préserver les preuves, couper l’accès, tourner les secrets et reconstruire précède la confiance. La notification doit expliquer données, période et actions. Offrir une surveillance ne corrige pas l’asymétrie pour les personnes qui n’ont jamais choisi la collecte.

Détecter l’exfiltration comme une séquence

Un attaquant ne télécharge pas toujours toute la base d’un coup. Il peut exécuter des requêtes, compresser, découper puis transmettre lentement. Je relierais requêtes volumineuses, création d’archives, processus inhabituels et trafic sortant par hôte et compte. Une baseline de volume aide, mais les comptes administratifs exigent des seuils stricts et une approbation d’export. Les alertes partent vers un dépôt que le serveur compromis ne peut pas effacer. Pendant l’enquête, l’équipe conserve l’horloge et les identifiants pour reconstruire quelles tables et périodes ont été touchées. Cette séquence réduit l’incertitude de notification et de réinitialisation.

Je pratiquerais un scénario où une application exposée est compromise : retrouver sa version, isoler, déterminer les tables consultées et produire la liste des personnes. Le temps nécessaire révèle les trous d’inventaire et de logs. La pratique la plus durable reste de ne pas conserver un identifiant sensible dans dix systèmes si deux suffisent.