Audit & test d’intrusion

Le premier réflexe consiste souvent à demander « un pentest » sans préciser ce que l’on souhaite démontrer. Or un test d’intrusion n’est qu’une méthode parmi d’autres, et son utilité dépend de la question posée. Si vous voulez recenser les faiblesses connues d’un parc, un scan automatisé suffit et coûte peu. Si vous voulez savoir si un enchaînement de failles permet de prendre le contrôle d’un serveur ou de données sensibles, il faut un humain qui raisonne comme un adversaire. Si vous voulez mesurer la capacité de vos équipes à repérer et à contenir une attaque discrète, c’est un exercice de simulation qui s’impose. Distinguer ces trois objectifs évite deux écueils fréquents : payer cher un audit manuel pour obtenir ce qu’un outil aurait livré, ou se contenter d’un scan en croyant avoir validé sa résistance réelle. La nuance n’est pas académique, elle conditionne le budget, le calendrier et la lecture du rapport final.

Quel que soit le format retenu, un test d’intrusion suit un fil conducteur que l’infographie ci-dessus résume. Tout commence par la phase de reconnaissance, qui rassemble les informations accessibles sur l’organisation : domaines, adresses exposées, technologies employées, comptes publiés. Vient ensuite l’exploitation contrôlée, où le testeur essaie de transformer une faiblesse en accès réel, sans jamais mettre le service en danger. Si l’accès obtenu le permet, le rebond vers d’autres machines révèle des chemins d’attaque plutôt que des failles isolées. Reste le rapport, dont dépend toute la valeur de l’exercice. Le niveau d’information donné au testeur change beaucoup de choses : partir sans rien savoir simule un inconnu, partir avec des comptes et de la documentation permet d’aller plus loin dans le temps imparti, comme l’explique notre comparatif entre boîte noire, grise et blanche. Il n’existe pas de bon choix universel, seulement un choix cohérent avec l’objectif.

Un test offensif reste une photographie. Il décrit l’état d’un périmètre à une date donnée, avec le temps et les moyens alloués au testeur, et il ne garantit pas l’absence d’autres failles. Un rapport sans constat critique ne signifie donc pas que l’organisation est totalement inattaquable : il signifie que, dans ces conditions, les chemins explorés n’ont pas abouti. Cette lecture honnête protège contre la fausse assurance. Elle justifie aussi de répéter les tests après chaque changement important, comme une migration, l’ouverture d’un service ou une refonte applicative, et de les compléter par une détection continue des comportements anormaux. Un audit n’est jamais l’alternative à la supervision, il en est le complément : il vérifie que vos protections tiennent, tandis que la supervision vérifie chaque jour que personne ne les contourne. Cette articulation est la clé d’une démarche mature, et c’est elle que la suite de cette page détaille.

Quels périmètres tester, et dans quel ordre ?

Il est tentant de vouloir tout tester d’un seul coup, mais un programme efficace se construit par couches successives, de l’extérieur vers l’intérieur. La logique est celle d’un attaquant : il cherche d’abord ce qui est visible depuis Internet, puis ce qui permet d’entrer, puis ce qui permet de s’étendre. Suivre cet ordre présente un avantage budgétaire, car il évite de découvrir de graves problèmes au moment où ils coûtent le plus cher à traiter. Il garantit aussi la cohérence des constats : corriger l’exposition externe avant de tester l’interne évite de payer deux fois pour la même faille. Le tableau ci-dessous associe les questions les plus courantes à la démarche qui y répond le mieux, avant que nous détaillions les trois grands temps d’un parcours raisonnable. Considérez-le comme une grille de lecture, pas comme un catalogue à commander en bloc, car chaque organisation n’a besoin que de quelques lignes de ce tableau à un instant donné.

Commencer par ce que tout le monde voit

La surface exposée est le point de départ naturel, car c’est celle que n’importe quel inconnu peut examiner sans le moindre accès. Elle regroupe les noms de domaine, les sites, les services de messagerie, les accès distants, les anciennes applications oubliées et les comptes publiés involontairement. Une analyse de reconnaissance menée à partir de sources ouvertes dresse l’inventaire de ce que l’organisation expose réellement, souvent bien au-delà de ce que la direction informatique imagine. On y découvre régulièrement des serveurs de test jamais éteints, des sous-domaines abandonnés, des interfaces d’administration accessibles. Le test d’intrusion externe prolonge ce travail en essayant d’exploiter les faiblesses repérées. L’intérêt de cette étape tient à son rapport entre efficacité et coût : elle révèle des portes d’entrée évidentes que les attaquants automatisés exploitent en continu, et leur correction relève presque toujours d’actions simples, comme fermer un service inutile ou appliquer une mise à jour oubliée.

Poursuivre par le cœur du système d’information

Une fois les portes extérieures traitées, la question devient : que se passe-t-il si quelqu’un entre malgré tout ? Un poste de travail piraté, un mot de passe hameçonné ou un prestataire compromis suffisent à placer l’attaquant à l’intérieur. Le test d’intrusion interne simule cette situation et mesure la facilité avec laquelle il peut se déplacer, récupérer des identifiants et atteindre les serveurs critiques. La plupart du temps, dans un environnement Windows, tout converge vers l’annuaire : c’est pourquoi l’audit de l’Active Directory mérite une attention particulière, avec ses comptes à privilèges, ses délégations et ses configurations héritées de plusieurs années. Pour les organisations qui ont migré vers des services hébergés, l’audit de configuration cloud joue le même rôle en examinant les droits, le stockage et la journalisation. Ces contrôles portent moins sur des failles logicielles que sur des erreurs de paramétrage, plus fréquentes et tout aussi dangereuses.

Terminer par les applications, le code et les usages

Les applications métier, les sites transactionnels et les applications mobiles sont des cibles à part entière, car elles manipulent des données sensibles et sont souvent développées rapidement. Le pentest applicatif examine l’authentification, la gestion des droits, les entrées utilisateur et la logique métier, là où les scanners trouvent peu de choses. L’audit de code source agit plus tôt, directement chez le développeur, et permet de corriger une faille avant sa mise en production, à moindre coût. Restent les angles que l’on oublie : le réseau sans fil des locaux, qui peut offrir une porte d’entrée discrète, et le facteur humain, que l’on évalue par des campagnes d’hameçonnage contrôlées ou des tentatives d’appel frauduleux. Ces tests complémentaires ne sont pas secondaires, car la plupart des intrusions réelles combinent une faiblesse technique et une erreur de comportement. Prévoir ces angles dans le calendrier annuel donne une vision plus juste du risque qu’un seul test technique.

Quelle profondeur de test choisir selon votre niveau de maturité ?

La profondeur d’un test se juge à ce qu’il tente de démontrer, pas à son prix. À la surface, le scan de vulnérabilités parcourt automatiquement un périmètre et compare ce qu’il trouve à des bases de faiblesses connues. Plus bas, le test d’intrusion ajoute le raisonnement humain : il enchaîne des failles mineures, détourne des fonctions légitimes et prouve un impact concret. Plus bas encore, l’exercice red team ne cherche plus à lister les failles, il poursuit un objectif, par exemple accéder à une base sensible sans être détecté, et mesure la réaction des équipes de défense. L’infographie compare qualitativement ces trois niveaux, sans prétendre chiffrer quoi que ce soit : plus la démarche est profonde, plus elle est longue, coûteuse et exigeante pour l’organisation testée. Choisir trop profond trop tôt revient à passer un examen pour lequel on n’a pas encore révisé.

Scan et pentest : deux outils complémentaires

Le scan et le pentest ne se concurrencent pas, ils se répartissent le travail. Le scan, lancé chaque mois ou après chaque changement, assure une hygiène de base : correctifs manquants, certificats expirés, services inutiles. Il est rapide, peu coûteux et répétable, mais il produit des faux positifs et ignore les failles de logique. Le pentest, réalisé régulièrement et après toute évolution majeure, apporte la preuve d’exploitation et la hiérarchisation par impact. Pour bien saisir cette différence, lisez notre éclairage sur la distinction entre scan de vulnérabilités et pentest, qui détaille ce que chaque approche voit et manque. Une organisation qui se contente de scans accumule une dette qu’elle ne mesure pas, tandis qu’une organisation qui ne fait que des pentests ponctuels laisse des failles banales ouvertes pendant des mois. La combinaison des deux, avec une cadence adaptée aux changements du système, offre le meilleur compromis entre coût, couverture et réactivité.

Red team et bug bounty : pour les organisations déjà solides

L’exercice red team s’adresse aux organisations qui disposent déjà d’une supervision, de procédures de réponse et d’un niveau de durcissement correct. Les équipes de défense ne sont généralement pas prévenues, afin de mesurer leur capacité de détection réelle, et une cellule de pilotage restreinte garde la main pour arrêter l’exercice en cas de risque. Le résultat n’est pas une liste de failles mais un récit d’attaque, avec ses réussites, ses échecs et surtout ses moments où l’alerte aurait dû sonner. Le bug bounty, lui, ouvre le périmètre à des chercheurs indépendants rémunérés selon la gravité de ce qu’ils trouvent. C’est une approche puissante pour un service exposé et activement maintenu, à condition de traiter les signalements rapidement. Lancer l’un ou l’autre sans maturité de correction revient à accumuler des constats que personne n’a le temps de résoudre, ce qui ne réduit en rien le risque.

Passer au niveau supérieur n’est pas une question d’ambition mais de préparation. Un bon indicateur consiste à regarder ce que devient le dernier rapport : si la majorité des constats ont été corrigés et vérifiés, l’organisation est prête à chercher plus profond. Si les mêmes faiblesses reviennent d’une année sur l’autre, mieux vaut investir dans le processus de correction avant de commander un test plus exigeant. D’autres signaux comptent : l’existence d’un inventaire fiable des actifs, la présence d’une supervision capable de lever des alertes, et un référent désigné pour recevoir les résultats et arbitrer. À l’inverse, une organisation sans sauvegardes testées ni gestion des accès à privilèges a davantage à gagner d’un audit de configuration que d’une simulation d’attaque sophistiquée. Cette progression par paliers, de la maîtrise de l’existant vers l’épreuve de la détection, évite les dépenses spectaculaires qui laissent les équipes épuisées et les budgets vides. Le bon test est celui dont vous saurez exploiter chaque ligne du rapport.

Comment adapter la démarche à la taille de l’organisation ?

Les mêmes méthodes ne s’appliquent pas de la même façon à un cabinet de dix personnes et à une communauté de communes de plusieurs centaines d’agents. Ce qui change n’est pas la nature des risques mais les ressources disponibles pour les traiter : budget, temps de l’équipe informatique, dépendance à des prestataires, degré de formalisation. L’erreur courante est de copier le programme d’une organisation plus grande, ce qui conduit à des audits ambitieux dont les résultats ne sont jamais traités, ou à l’inverse de ne rien faire faute d’un budget estimé hors de portée. La bonne approche consiste à partir de l’actif à protéger en priorité, qu’il s’agisse des données clients, de la production, de la facturation ou des services aux administrés, puis à dimensionner le test sur ce périmètre. Une démarche modeste mais menée jusqu’à la correction vaut toujours mieux qu’un audit exhaustif laissé dans un tiroir.

TPE et PME : viser l’essentiel

Pour une petite structure, la priorité est de couvrir les risques les plus probables avec un effort maîtrisé. Un test externe ciblé, associé à un scan régulier et à un contrôle des accès à la messagerie et à l’administration, élimine déjà l’essentiel de ce que les attaquants opportunistes recherchent. Si l’entreprise exploite une application sur mesure ou une boutique en ligne, un pentest limité à cette application est un investissement plus pertinent qu’un audit généraliste. La rédaction d’un cahier des charges court, avec un périmètre précis, une durée et des livrables attendus, évite les dérives de coût. Il est aussi raisonnable de s’appuyer sur un prestataire de confiance pour jouer le rôle d’équipe de sécurité : l’important est d’obtenir un plan d’actions réaliste que le dirigeant peut arbitrer en une réunion, plutôt qu’un document de cent pages que personne ne lira jusqu’au bout. La régularité compte plus que l’ampleur.

ETI et collectivités : industrialiser et gouverner

À partir d’une certaine taille, le sujet change d’échelle : multiples sites, filiales, applications nombreuses, prestataires et fournisseurs interconnectés. Il devient nécessaire de bâtir un programme annuel de tests piloté, avec un calendrier, un propriétaire identifié pour chaque périmètre et un suivi centralisé des constats. Les collectivités, souvent soumises à des obligations réglementaires et à des contraintes de continuité de service, ont intérêt à privilégier des tests peu intrusifs sur les systèmes sensibles et à planifier les interventions en dehors des pics d’activité. Les ETI peuvent, de leur côté, intégrer l’audit de code dans le cycle de développement, tester régulièrement leur annuaire et envisager un exercice red team lorsque la supervision est en place. Dans tous les cas, la gouvernance fait la différence : un comité qui suit les indicateurs de correction, par exemple le délai moyen pour traiter une faille critique, transforme une série de tests en démarche d’amélioration.

Cadrer, encadrer, puis exploiter

Quelle que soit la taille, un test se prépare. Le cadrage fixe le périmètre, les horaires, les techniques autorisées et les contacts d’urgence, et il se concrétise par des règles d’engagement signées par la direction, car tester un système sans autorisation écrite engage la responsabilité de chacun. Il faut aussi prévoir des sauvegardes récentes, informer les hébergeurs et prestataires concernés, et décider qui, en interne, est prévenu. À la fin de la mission, la qualité du rapport devient décisive : un bon document distingue les constats par gravité et par facilité de correction, propose des actions concrètes et fournit les preuves nécessaires pour reproduire chaque faille. Ensuite commence le vrai travail, la remédiation priorisée, suivie d’un contre-test ciblé qui confirme que les correctifs tiennent. Sans cette dernière étape, l’organisation ignore si le risque a réellement disparu ou simplement changé de forme, et elle rejoue le même audit l’année suivante pour redécouvrir les mêmes constats.