Beaucoup d'organisations pensent avoir couvert leur exposition avec des scans automatisés et des audits de configuration. Ces outils sont utiles, personne ne dit le contraire. Ils répondent juste à une question incomplète.
Ce qu'un scan voit, et ce qu'il ne voit pas
Un scan repère une vulnérabilité connue, une version obsolète, une règle mal configurée, un service exposé. Utile. Mais il ne dit rien de l'essentiel : qu'est-ce qu'un attaquant ferait réellement de cet environnement. La capacité à enchaîner plusieurs faiblesses mineures pour en faire une brèche majeure, à contourner une règle métier, à exploiter un compte trop permissif, à progresser jusqu'aux ressources critiques. Voilà ce qui échappe au scanner.
C'est toute la différence entre une liste de failles et un scénario d'attaque exploitable. La première rassure. Le second révèle. Un audit de configuration produit la première. Un test d'intrusion produit le second.
Ce que NIS2 exige vraiment
La directive n'écrit nulle part le mot pentest. Autant le dire clairement. Elle impose autre chose, au point 21(2)(f) : des politiques d'évaluation de l'efficacité des mesures de sécurité. Or un questionnaire ne démontre pas une efficacité. Un scan non plus. Le test d'intrusion, avec son exigence de preuve d'exploitabilité réelle, le fait.
Régulateurs et auditeurs interprètent largement cette exigence comme imposant des tests réguliers. La formulation reste ouverte, l'intention beaucoup moins.
Rapprocher la conformité du terrain
Pour une DSI, l'intérêt du test d'intrusion n'est pas cosmétique. Il rapproche la conformité de la réalité opérationnelle. La bonne question n'est pas combien de vulnérabilités existent sur le parc. Elle est de savoir lesquelles un attaquant peut réellement exploiter pour atteindre ce qui compte vraiment. Un rapport de scan liste des centaines de lignes. Un pentest en isole quelques unes, celles qui mènent quelque part. C'est cette hiérarchisation par l'exploitabilité qui manque à l'audit de configuration seul.
