Un audit de vulnérabilité informatique est un examen méthodique qui identifie les failles techniques, organisationnelles et humaines d’un système d’information. Son périmètre ne se limite pas aux serveurs ou aux postes de travail : il couvre aussi les applications, les accès distants, les équipements réseau et, depuis l’entrée en vigueur de NIS2, la chaîne d’approvisionnement numérique.
Cycle de vie d’une vulnérabilité : ce que l’audit doit couvrir
Détecter une faille ne suffit pas. Un audit pertinent vérifie la capacité de l’organisation à gérer tout le cycle de vie d’une vulnérabilité : identification, priorisation, correction, vérification, puis clôture formelle. Chaque étape produit une trace documentée.
A voir aussi : La méthode 2FA est-elle sûre ?
L’identification repose sur des scanners automatisés (Nessus, Qualys, OpenVAS) croisés avec une inspection manuelle des configurations. La priorisation, elle, a changé de logique ces dernières années.
Prioriser au-delà du score CVSS
Le score CVSS attribue une note de gravité technique à chaque vulnérabilité. Les analyses européennes récentes recommandent de ne plus s’y fier seul. Croiser exploitation connue, exposition Internet et criticité de l’actif donne une image bien plus réaliste du risque réel.
A découvrir également : Comment savoir si une image a été manipulée ?
Une faille notée 6.5 sur un serveur exposé à Internet et déjà exploitée dans la nature est plus urgente qu’une faille notée 9.0 sur une machine isolée sans données sensibles. L’audit doit formaliser cette grille de priorisation pour que les équipes techniques sachent par où commencer.
Périmètre d’audit : intégrer la chaîne d’approvisionnement numérique
La plupart des audits se concentrent sur le périmètre technique interne. Avec la directive NIS2, cette approche est devenue insuffisante. L’audit doit inclure les dépendances numériques et les fournisseurs, qu’il s’agisse d’un hébergeur cloud, d’un éditeur SaaS ou d’un prestataire de maintenance.
Concrètement, l’auditeur examine plusieurs points liés à la supply chain :
- Les contrats fournisseurs prévoient-ils des clauses de notification en cas d’incident de sécurité, avec un délai précis ?
- Les mises à jour et correctifs des logiciels tiers sont-ils suivis dans un registre centralisé, avec une procédure de test avant déploiement ?
- Les accès distants accordés aux prestataires sont-ils limités dans le temps, tracés et révoqués après chaque intervention ?
Ignorer ce volet revient à verrouiller la porte d’entrée en laissant la fenêtre ouverte. Les attaquants ciblent régulièrement le maillon le plus faible de la chaîne, souvent un sous-traitant moins protégé.
Preuves de conformité réglementaire exigées par NIS2
Pour les organisations concernées par NIS2, l’audit change de nature. Il ne s’agit plus seulement de produire un rapport technique listant des failles. Il faut démontrer l’existence de politiques d’audit, de procédures de correction et de tests d’efficacité.
Le rapport d’audit doit pouvoir prouver, pièces à l’appui, que les correctifs sont appliqués selon un calendrier défini, que les mesures de sécurité (comme le MFA pour les comptes administrateurs) sont en place, et que des contrôles réguliers vérifient leur bon fonctionnement.
Capacité de réaction sous contrainte de temps
NIS2 impose une alerte précoce au plus tard dans les 24 heures après la prise de connaissance d’un incident significatif. L’audit doit donc tester cette capacité de réaction, pas uniquement la solidité des défenses.
Un exercice de simulation, même simple (notification fictive d’une compromission fournisseur un vendredi soir), révèle vite si la procédure d’escalade existe réellement ou si elle dort dans un document que personne n’a lu.
Déroulement concret d’un audit de vulnérabilité
L’audit commence par une phase de cadrage : définir le périmètre (réseau interne, applications web, environnement cloud), les contraintes (plages horaires de scan, systèmes critiques à ménager) et les livrables attendus.
La phase technique combine ensuite trois approches complémentaires :
- Le scan automatisé identifie les vulnérabilités connues à grande échelle, en comparant les versions logicielles détectées aux bases de vulnérabilités publiques (CVE)
- L’analyse de configuration vérifie les paramètres de sécurité des équipements réseau, des pare-feu, des annuaires d’identités et des droits d’accès
- Les tests manuels ciblent les points que les scanners ne couvrent pas bien, comme les erreurs de logique applicative ou les mauvaises pratiques d’authentification
Le rapport final classe chaque vulnérabilité par niveau de risque contextuel (pas seulement par score technique) et propose un plan de remédiation avec un ordre de priorité. Les failles exploitables à distance sur des actifs exposés passent en tête.
Fréquence d’audit et vulnérabilités n-day
Un audit ponctuel donne une photographie à un instant donné. Les vulnérabilités dites « n-day » (failles connues pour lesquelles un correctif existe mais n’est pas encore appliqué) restent un vecteur d’intrusion fréquent. Plus le délai entre la publication d’un correctif et son application s’allonge, plus le risque augmente.
La bonne fréquence dépend du contexte : une plateforme web exposée à fort trafic justifie des scans mensuels, tandis qu’un réseau interne stable peut être audité tous les trimestres. L’audit annuel complet reste un minimum raisonnable, complété par des scans ciblés après chaque changement majeur (migration, nouveau prestataire, mise en production).
Un audit régulier transforme la sécurité d’un coût subi en processus maîtrisé. Le premier audit est souvent le plus long et le plus coûteux, les suivants gagnent en efficacité parce que le référentiel existe déjà. La dette technique identifiée lors du premier passage diminue à chaque cycle, à condition que les remédiations soient réellement suivies et vérifiées.
