S'attaquer soi-même pour prouver que la défense fonctionne
Vous pouvez installer tous les outils défensifs du monde — et pourtant ne pas savoir s'ils fonctionnent réellement. Le seul moyen de savoir est de s'attaquer soi-même et de voir si l'alerte se déclenche. Mais attaquer sans limites est un risque en soi. Voici comment nous l'avons fait correctement.
Le problème : une défense non testée n'est qu'un espoir
Une entreprise installe un antivirus, un pare-feu et de la surveillance — et suppose qu'elle est protégée. Mais le pare-feu bloque-t-il vraiment ? L'alerte concernant une tentative d'intrusion arrive-t-elle vraiment, et en combien de secondes ? Sans test actif, ce ne sont que des hypothèses. Et lorsqu'une vraie attaque survient, on découvre la réponse de la manière la plus douloureuse.
La barrière avant tout : l'autorisation signée (RoE)
Avant même de lancer une seule analyse contre une cible, il y a une barrière d'autorisation signée (Rules of Engagement). Sans formulaire de consentement numérique signé couvrant la cible — aucun test actif ne s'exécute. La barrière impose aussi une fenêtre temporelle et une option de révocation. Ce n'est pas de la bureaucratie : c'est la même preuve de consentement qu'exige une réglementation comme l'Amendement 13, et c'est la protection juridique pour nous comme pour le client. Un vrai DoS ? Toujours refusé — tout au plus un test de charge contrôlé.
Ce que nous avons construit : un lanceur de campagnes
Au lieu de lancer un test à la fois, nous avons construit un lanceur de campagnes qui orchestre de nombreux tests ensemble — une matrice cible × méthode. Une méthode, par exemple, est le test d'intrusion d'applications web (détection d'injection SQL avec sqlmap et analyse DAST). Chaque campagne s'exécute contre la liste, collecte les résultats et les remonte vers le même tableau de bord de sécurité unifié où réside tout le reste de l'information.
Le cœur : une matrice de couverture Purple-Team
C'est ici que la magie opère. Nous avons pris toutes nos détections (ce que la défense sait attraper) et projeté chacune sur une technique de MITRE ATT&CK — le dictionnaire universel de la façon dont les attaquants opèrent réellement. Le résultat est une matrice de couverture : un tableau qui montre exactement quelles techniques d'attaque nous détectons, et où sont les lacunes. « Purple-Team » = combiner le camp rouge (offensive) et le camp bleu (défense) dans une seule boucle.
Les trois preuves qui concluent une vente
- « Voici votre exposition » — une analyse externe qui montre ce qu'un attaquant voit.
- « Voici la correction — de 62 à 88 » — un score de durcissement avant/après.
- « Nous avons prouvé que l'alerte se déclenche sur votre serveur » — la matrice de couverture en action.
Comment nous l'avons testé
Nous avons exécuté la première méthode d'attaque (détection SQLi + DAST) contre une cible de test autorisée, et avons trouvé une vraie vulnérabilité — ce qui a prouvé que le chemin de bout en bout fonctionne : lanceur → barrière d'autorisation → test → résultat dans le tableau de bord. En parallèle, la barrière RoE a fait ses preuves : sans autorisation signée, aucun test ne s'exécute.
Comment nous continuons de l'améliorer — un contrôle qualité continu
La matrice de couverture est vivante : à mesure que nous ajoutons des détections, la couverture augmente et les lacunes se réduisent. Prochaines étapes : une validation planifiée des détections (BAS — Atomic Red Team sur un sous-ensemble sûr) qui exécute des techniques d'attaque et vérifie que l'alerte s'est déclenchée, un suivi de tendance du pourcentage de couverture dans le temps, et un test de charge contrôlé comme substitut sûr au DoS. Nous nous attaquons nous-mêmes — pour que personne d'autre n'ait à le faire.
Cet article décrit l'approche au niveau des principes. Toute notre activité offensive est contrôlée, autorisée par signature et révocable ; nous n'exposons ni outils, ni charges utiles, ni détails qui aideraient un attaquant.
← Tous les articles