Le test d'intrusion est un élément standard de tout programme de sécurité sérieux. Dans les environnements commerciaux, il s'agit d'un exercice relativement bien compris : une équipe externe reçoit un périmètre, un document de règles d'engagement et une fenêtre temporelle pour trouver des vulnérabilités exploitables avant que de véritables attaquants ne le fassent. Le résultat est un rapport ; le chemin de remédiation est un problème de gestion de projet.
Dans les environnements de défense, rien de ce cadre ne s'applique pleinement. La structure d'autorité légale est différente, le modèle de menace est différent, les contraintes sur ce que les testeurs peuvent toucher sont différentes, et le chemin allant de la découverte à la remédiation passe par un processus d'accréditation formel qui n'a pas d'équivalent commercial. Les organisations qui appliquent les conventions de tests d'intrusion commerciaux aux systèmes de défense — ou qui font appel à des entreprises de tests d'intrusion commerciaux sans expérience défense — produisent systématiquement des évaluations qui ratent les risques les plus pertinents, opèrent en dehors des limites légalement défendables, ou génèrent des découvertes sur lesquelles le bureau du programme ne peut pas agir.
Cet article examine ce qui rend réellement les tests d'intrusion de défense différents, ce que cela signifie opérationnellement, et comment structurer une évaluation produisant des résultats qu'un programme militaire peut utiliser.
Autorité légale : le fondement sans équivalent commercial
Dans les missions commerciales, le fondement juridique d'un test d'intrusion est un contrat et un document de règles d'engagement signé par une personne habilitée à autoriser les tests des systèmes cibles. Cette autorité est généralement simple — l'entreprise possède les systèmes et le RSSI ou le CTO peut accorder la permission.
Dans les environnements de défense, la chaîne d'autorité est plus complexe et les enjeux d'une erreur sont considérablement plus élevés. Les systèmes d'information gouvernementaux opèrent sous une Autorisation d'exploitation (ATO) accordée par une Autorité d'approbation (AO). L'ATO définit la posture de sécurité que le système est autorisé à maintenir. Les tests d'intrusion modifient cette posture, au moins temporairement, et doivent être explicitement autorisés par l'AO — pas seulement par le chef de programme ou l'ISSO du système.
Pour les systèmes US DoD, le Computer Fraud and Abuse Act (CFAA) et l'UCMJ s'appliquent. Une personne qui accède à un système d'information gouvernemental sans autorisation appropriée — même avec de bonnes intentions, même dans le cadre d'un test ostensiblement autorisé — a commis un crime fédéral. Le document d'autorisation n'est pas une formalité : c'est l'instrument qui transforme ce qui serait autrement un accès non autorisé en test légal. Chaque testeur nommé dans l'autorisation doit être identifié individuellement. Le périmètre des tests autorisés doit être spécifique. Les activités en dehors de ce périmètre ne sont pas protégées.
Exigence d'autorité légale : Ne commencez jamais un test d'intrusion de défense sans un document d'autorisation signé et spécifique de l'Autorité d'approbation du système. Les approbations génériques d'« évaluation de sécurité » émanant de chefs de programme ou de sous-traitants principaux ne fournissent pas de protection CFAA. L'autorisation doit identifier les testeurs par leur nom, préciser les systèmes dans le périmètre, définir la fenêtre de test et énumérer les méthodes autorisées.
Les exigences d'habilitation ajoutent une couche supplémentaire. Tester un système classifié exige que les testeurs détiennent des habilitations valides au niveau de classification approprié. L'organisation de test doit détenir une habilitation d'installation (FCL) à ce niveau. L'introduction de personnel non habilité — même dans des rôles de soutien — dans un environnement de test classifié constitue une violation de sécurité, indépendamment de ce qu'ils voient ou touchent réellement.
L'ITAR (International Traffic in Arms Regulations) introduit des contraintes supplémentaires pour les programmes impliquant des articles de défense contrôlés. Les informations sur les vulnérabilités des systèmes contrôlés par l'ITAR peuvent elles-mêmes être soumises à des restrictions de contrôle des exportations, limitant ce qui peut être documenté, transmis ou partagé au-delà des frontières internationales — y compris au sein de programmes alliés multilatéraux. Les entreprises de test opérant dans le cadre de sous-traitances internationales doivent en tenir compte explicitement.
Émulation d'acteurs de la menace : TTPs des États-nations, pas des exploits génériques
Les tests d'intrusion commerciaux se concentrent souvent sur la recherche de toute vulnérabilité exploitable — les problèmes les plus courants, les plus accessibles et les mieux scorés au CVSS dans la surface d'attaque de la cible. Pour un réseau d'entreprise, c'est une approche raisonnable : un attaquant opportuniste exploitera le chemin le plus facile disponible.
Les systèmes de défense font face à une population de menaces fondamentalement différente. Les adversaires principaux pour les cibles de défense à haute valeur sont des acteurs étatiques disposant de ressources substantielles, de capacités avancées et d'horizons temporels longs. Ils ne seront pas stoppés par le correctif de la vulnérabilité OpenSSL CVSS-10 s'ils peuvent pivoter via un partenaire de la chaîne d'approvisionnement de confiance, un composant embarqué hérité, ou une mauvaise configuration d'une solution de domaine croisé.
Un test d'intrusion de défense efficace utilise l'émulation d'adversaires : l'équipe de test réplique les tactiques, techniques et procédures (TTPs) de groupes d'acteurs de la menace spécifiques pertinents pour le modèle de menace du programme. Le cadre MITRE ATT&CK fournit une taxonomie structurée pour cela, avec des matrices Enterprise et ICS couvrant les techniques les plus couramment employées par les groupes de menaces persistantes avancées.
Pour les systèmes de défense, les acteurs de la menace pertinents comprennent généralement :
- APT28 (Fancy Bear / GRU Unité 26165) — Renseignement militaire russe, connu pour le spearphishing, la collecte d'identifiants et la persistance via l'abus d'outils légitimes. Les tactiques pertinentes pour les logiciels de défense incluent le ciblage des postes de travail des développeurs et des pipelines de build pour injecter du code malveillant en amont du déploiement.
- Lazarus Group (RPDC) — Acteur étatique nord-coréen avec un historique de ciblage des contractants de défense et des entreprises aérospatiales, notamment via des attaques de points d'eau et des leurres d'offres d'emploi weaponisés ciblant le personnel habilité.
- Volt Typhoon (RPC) — Acteur étatique chinois axé sur des techniques living-off-the-land pour obtenir un accès persistant et discret aux infrastructures critiques et aux réseaux de défense. Remarquable pour éviter les logiciels malveillants personnalisés au profit des outils système intégrés afin d'échapper à la détection.
Le plan de test doit préciser quel profil d'adversaire est émulé et pourquoi, en se basant sur l'évaluation des menaces du programme. Un test émulant l'approche living-off-the-land de Volt Typhoon sera très différent d'un test émulant les opérations axées sur les identifiants d'APT28 — et les deux seront différents d'un test axé sur des scénarios de menaces internes ou d'intégrité de la chaîne d'approvisionnement.
Note sur la sélection de l'adversaire : Le profil d'acteur de la menace doit être guidé par l'évaluation des menaces basée sur le renseignement du programme, et non par la préférence du testeur ou des labels génériques « avancés ». Pour les programmes avec des profils de menaces géographiques spécifiques ou un historique de ciblage connu, l'ISSO doit briefer l'équipe de test sur les rapports de menaces actuels avant le début de la mission.
Gestion du périmètre : contraintes sans interruption et environnements de test isolés
Les contraintes de périmètre des tests d'intrusion commerciaux visent principalement à limiter la responsabilité et à concentrer les efforts. Les contraintes de périmètre de défense comportent des dimensions supplémentaires qui façonnent fondamentalement la manière dont un test peut être conduit.
De nombreux systèmes de défense ne peuvent accepter aucune interruption pendant les tests. Les systèmes de commandement et de contrôle, les infrastructures de communication et les plateformes de fusion de capteurs en temps réel peuvent être opérationnellement actifs pendant une fenêtre de test. Une tentative d'exploitation provoquant une interruption de service — même brève — peut avoir des conséquences opérationnelles qu'aucune indemnisation contractuelle ne peut compenser. L'approche commerciale standard consistant à tester contre des systèmes de production avec une règle « arrêtez si vous voyez quelque chose d'instable » n'est pas acceptable pour ces environnements.
La conséquence pratique est que de nombreux tests d'intrusion de défense sont conduits contre des environnements de test dédiés : segments réseau isolés, environnements de staging ou répliques de laboratoire reflétant la production aussi fidèlement que possible. La fidélité de l'environnement de test est d'une importance capitale. Un environnement de test utilisant des versions de firmware différentes, manquant d'intégrations de production ou opérant avec des contrôles d'accès assouplis par rapport à la production produira des découvertes ne reflétant pas la posture de risque réelle du système opérationnel. La fidélité de l'environnement de test est un investissement que le bureau du programme doit s'engager à financer — ce n'est pas le problème de l'équipe de test à résoudre.
Les violations de périmètre sont traitées avec une plus grande sévérité dans les environnements de défense que dans les environnements commerciaux. Toucher accidentellement un système hors du périmètre autorisé n'est pas un problème procédural mineur — cela peut constituer un accès non autorisé à un système d'information gouvernemental. Les testeurs doivent maintenir un journal d'activité détaillé tout au long de la mission, documentant les actions significatives en quasi-temps réel, afin que toute question de périmètre surgissant pendant ou après le test puisse être résolue avec des preuves plutôt que des souvenirs.
Classes de vulnérabilités spécifiques à la défense
Au-delà des différences procédurales, les systèmes de défense présentent des classes de vulnérabilités sous-représentées dans les méthodologies de tests d'intrusion commerciaux.
Systèmes embarqués hérités. Les plateformes de défense utilisent systématiquement des logiciels sur du matériel âgé de 10 à 20 ans, avec un firmware embarqué ne pouvant pas être corrigé via les mécanismes normaux de mise à jour logicielle. Les vulnérabilités dans ces composants peuvent être connues mais non traitables dans le cycle de vie du système — la découverte lors du test d'intrusion deviendra une entrée permanente au POAM avec une demande de dérogation plutôt qu'un ticket de remédiation. Les testeurs doivent comprendre ce que « découverte » signifie dans ce contexte : la valeur réside dans la documentation et la quantification du risque, pas nécessairement dans la conduite d'une remédiation immédiate.
Solutions de domaine croisé. Les systèmes traitant des données à plusieurs niveaux de classification utilisent des solutions de domaine croisé (CDS) pour déplacer les données entre les domaines de sécurité. Ce sont des cibles à haute valeur : une CDS pouvant être manipulée pour transmettre des informations dans le mauvais sens compromet toute l'architecture de traitement des données. Les tests CDS nécessitent une expertise spécialisée et une autorisation spécifique — ces composants sont souvent traités comme des périmètres distincts au sein d'une évaluation de programme plus large.
Intégrité de la chaîne d'approvisionnement. Les attaques les plus significatives sur la chaîne d'approvisionnement logicielle ces dernières années (SolarWinds, XZ Utils) ont ciblé les pipelines de build et l'injection de dépendances plutôt que les systèmes en cours d'exécution. Les programmes de défense sont des cibles à haute valeur pour cette classe d'attaques. Les tests d'intrusion doivent inclure l'évaluation de l'environnement de build : un attaquant ayant accès à un poste de travail de développeur peut-il introduire du code malveillant qui survit jusqu'à un build de production ? Une dépendance compromise peut-elle être introduite sans déclencher les contrôles existants ?
Gestion des certificats et des clés. Les systèmes de défense dépendent fortement de l'infrastructure PKI pour l'authentification et la sécurité des communications. La validation de certificats mal configurée, les configurations d'ancres de confiance trop larges et la mauvaise gestion du cycle de vie des clés sont constamment des découvertes à haute criticité. Contrairement aux vulnérabilités applicatives, celles-ci sont souvent invisibles aux analyses automatisées et nécessitent une vérification manuelle de l'architecture PKI par rapport à la conception de sécurité du système.
Le cycle de vie des découvertes : POAM, impact ATO et demandes de dérogation
Dans les missions commerciales, le rapport de test d'intrusion est transmis au RSSI, les découvertes sont triées, une partie est corrigée, et le reste vieillit dans un tracker jusqu'à la prochaine évaluation. Le processus est guidé par l'appétit au risque et la capacité d'ingénierie.
Dans les environnements de défense, les découvertes s'intègrent dans un cycle de vie d'accréditation formel avec des implications légales et contractuelles. Le concept clé est le Plan d'action et jalons (POAM) : un document qui suit chaque faiblesse connue du système contre lequel une ATO a été accordée ou est sollicitée. Chaque découverte d'un test d'intrusion qui n'est pas immédiatement corrigée doit être intégrée au POAM avec une date de correction planifiée, un responsable et une mesure d'atténuation provisoire.
Le POAM est examiné par l'Autorité d'approbation comme condition de la maintenance de l'ATO. Les éléments à haute criticité ouverts sans atténuations provisoires adéquates ou calendriers de correction réalistes peuvent déclencher une suspension de l'ATO — mettant effectivement le système hors ligne jusqu'à ce que la posture de risque soit traitée. Pour un bureau de programme, ce résultat est suffisamment grave pour que certains programmes retardent ou limitent le périmètre des tests d'intrusion afin d'éviter de générer des découvertes susceptibles de déclencher une révision de l'ATO. C'est un échec de gestion des risques : les vulnérabilités existent qu'elles soient documentées ou non.
Pour les découvertes qui ne peuvent être corrigées — composants hérités sans correctifs disponibles, contraintes architecturales nécessitant une refonte complète du système — le bureau du programme peut soumettre une demande de dérogation ou une acceptation de risque à l'AO. Ce n'est pas un aveu d'échec ; c'est le mécanisme formel pour opérer avec un risque résiduel connu sous autorisation explicite. Les testeurs doivent comprendre ce processus et formuler les découvertes d'une manière aidant l'ISSO à construire des entrées POAM défendables et des demandes de dérogation, pas seulement d'une manière maximisant les scores CVSS.
Formulation du rapport pour les programmes de défense : Les rapports de tests d'intrusion de défense doivent inclure, pour chaque découverte : un marquage de classification, une évaluation de criticité alignée sur les critères d'acceptation du risque du programme, une évaluation de l'exploitabilité compte tenu des acteurs de la menace réels du programme, et une disposition POAM recommandée. Les rapports rédigés en format commercial — scores CVSS, conseils de remédiation génériques, résumés exécutifs destinés à des dirigeants non techniques — nécessitent un travail de réécriture significatif avant que l'ISSO puisse les utiliser.
Comment définir le périmètre et autoriser un test d'intrusion de défense
Les étapes suivantes reflètent les exigences pour un test d'intrusion défendable et légalement autorisé sur un système logiciel de défense.
Étape 1 : Établir l'autorité légale et l'autorisation écrite. Obtenir un document d'autorisation de test signé par l'AO du système. Le document doit nommer les testeurs, préciser les systèmes dans le périmètre, définir la fenêtre de test et énumérer les méthodes autorisées. Ce n'est pas une formalité — c'est l'instrument qui rend les tests légaux.
Étape 2 : Vérifier les habilitations et les accréditations d'installation. Confirmer que tous les testeurs détiennent des habilitations valides au niveau de classification du système cible, et que l'organisation de test détient une FCL au niveau requis. Briefer tous les testeurs sur le guide de classification de sécurité du programme avant qu'ils n'accèdent à un environnement classifié.
Étape 3 : Définir le périmètre et les limites de l'environnement de test. Identifier les systèmes, réseaux et interfaces dans le périmètre. Lorsque les systèmes opérationnels ne peuvent accepter d'interruption, établir un environnement de test dédié. Documenter les exclusions explicites et informer les testeurs des conséquences légales des violations de périmètre.
Étape 4 : Sélectionner et vérifier les outils de test. Examiner les obligations ITAR et les exigences d'accréditation du programme pour déterminer quels outils sont autorisés. Éliminer les outils d'origine étrangère, à licence basée dans le cloud ou avec une télémétrie sortante. Documenter la liste d'outils dans le plan de test et la soumettre au bureau du programme avant le début de la mission.
Étape 5 : Conduire l'émulation d'acteurs de la menace basée sur le modèle de menace du programme. Sélectionner le profil d'adversaire le plus pertinent pour le système. Utiliser MITRE ATT&CK pour ICS ou Enterprise selon le cas, adapté à l'architecture spécifique du système et à son profil de mission. Ne pas substituer des tests génériques « avancés » à une véritable émulation d'adversaire.
Étape 6 : Documenter l'activité et les découvertes avec les marquages de classification. Maintenir un journal d'activité détaillé tout au long de la mission. Toutes les découvertes doivent porter les marquages de classification appropriés et des évaluations de criticité alignées sur les critères d'acceptation du risque du programme.
Étape 7 : Intégrer les découvertes dans le POAM et suivre les corrections. Travailler avec l'ISSO pour intégrer toutes les découvertes ouvertes dans le POAM. Attribuer des responsables de correction, des dates planifiées et des mesures d'atténuation provisoires. Briefer directement l'AO sur les découvertes à haute criticité — ne pas laisser des vulnérabilités critiques en attente sans acceptation explicite du risque ou correction active.