Audit de sécurité informatique

Audit d'architecture, audit de configuration, test d'intrusion

L'essentiel de la confusion autour de cet achat vient d'un mot qui désigne trois travaux différents. Ils ne répondent pas à la même question, n'exigent pas les mêmes preuves et ne se terminent pas par le même document.

Le reste de cette page porte sur les deux premiers. Le troisième est celui qu'on confond avec eux le plus souvent, parce que les trois se vendent sous le mot audit. Test d'intrusion : ce qu'un test couvre et ce qu'il laisse de côté

Ce qu'un audit de sécurité informatique couvre

Un audit se définit par son périmètre et par la référence à laquelle il compare, pas par ses outils. Dans une PME, le travail se situe le plus souvent à six endroits, et un rapport qui en oublie un décrit un système plus petit que celui qui tourne en production.

• L'inventaire : quelles machines, quelles applications, quels domaines, quels comptes cloud et quels services externes existent réellement. Le shadow IT est le premier constat de la plupart des audits, et souvent celui que personne ne voulait mentionner.
• Les comptes et les accès : qui peut se connecter où, avec quel privilège, et si ce privilège est encore justifié. Les comptes partagés, les accès administrateur dormants et les accès qui survivent à un départ appartiennent à cette rubrique.
• La frontière : ce qui est exposé à internet, quels ports répondent, quelles versions de quels services écoutent, et si la surface exposée correspond à l'architecture annoncée.
• La configuration face à une base de référence : chiffrement des échanges, en-têtes de sécurité, messages d'erreur, droits sur les fichiers, tous ces réglages qui décident si une erreur devient un incident.
• Les correctifs et les versions : quels composants sont encore maintenus, lesquels ne le sont plus, et comment l'organisation apprend une vulnérabilité à temps pour agir.
• La journalisation, la détection et la restauration : ce qui est enregistré, qui le lit, et si une restauration a déjà été testée. Un audit qui s'arrête à la prévention décrit la moitié du problème.

Le périmètre est convenu par écrit avant toute collecte. Deux entreprises de même effectif peuvent avoir besoin de périmètres très différents, parce que ce qui fixe la charge est le nombre de pièces mobiles, pas le nombre de salariés.

Ce qu'un audit de sécurité informatique ne couvre pas

La plupart des déceptions devant un rapport viennent de ce que la mission n'a jamais eu à faire. Voici les manques habituels.

• La tentative d'exploitation. Un audit lit, compare et rapporte. Il n'essaie pas d'entrer, et un constat qui dit qu'une faiblesse est probablement exploitable n'est pas un constat démontré.
• La revue de code. Un audit voit la configuration et le comportement. Il ne voit pas la branche que personne n'a déployée, la dépendance joignable seulement derrière un drapeau de fonctionnalité, ni l'erreur de logique qui paraît correcte de l'extérieur.
• L'ingénierie sociale et l'accès physique. L'hameçonnage, le prétexte et l'entrée dans un bâtiment sont des exercices séparés, avec leur propre autorisation et leurs propres risques pour les personnes concernées.
• La certification. Un audit produit des constats par rapport à une référence. Il ne rend pas une organisation conforme à un référentiel, et un rapport n'est pas une attestation.
• Tout ce qui sort du périmètre convenu. Une filiale, une application ancienne, un environnement que le client a omis de l'inventaire : non testés, quoi que laisse entendre le rapport. Un prestataire qui refuse de dire clairement ce qui reste dehors vous dit quelque chose du rapport.

La frontière entre un audit et un test d'intrusion est celle entre lire et tenter. Les deux servent. Un seul produit la requête qui prouve le problème.

Comment se déroule un audit de sécurité informatique

L'ordre compte plus que l'outillage. Chaque phase produit ce que la suivante consomme, et sauter une phase est la façon dont un audit devient un questionnaire assorti d'une note.

1. 01Périmètre et inventaire

   Ce qui est inclus, ce qui ne l'est pas, qui autorise le travail et qui répond aux questions pendant la mission. Rien n'est collecté avant que ce document existe : sans lui, l'auditeur devine la taille du système et le client devine la taille de la facture.

2. 02Collecte des preuves

   La collecte en lecture seule des configurations, des exports de comptes et de droits, des schémas réseau, de l'inventaire des services, et des journaux que l'équipe conserve déjà. Là où un document n'existe pas, son absence est un constat, pas un obstacle.

3. 03Comparaison à la référence

   Chaque élément est comparé à la base que la mission a nommée : la documentation de l'éditeur, un guide de durcissement, ou un standard comme l'ISO/IEC 27001 pour le volet organisationnel et l'OWASP Application Security Verification Standard pour le volet applicatif. La référence est choisie avant la collecte, sinon l'audit retient le référentiel que ses constats satisfont déjà.

4. 04Priorisation

   Chaque écart est replacé dans ce que fait le système. Un réglage faible sur un environnement de test et le même réglage sur le chemin de paiement n'ont pas la même urgence, et un rapport qui les cite dans le même paragraphe pousse à corriger d'abord le mauvais.

5. 05Rapport et suivi

   Ce qui a été trouvé, sur quel système, avec la preuve qui le montre, et quoi faire ensuite. Le suivi est l'endroit où la valeur arrive : un constat que personne ne revérifie après la correction est un avis, pas un résultat.

Un audit mené ainsi produit un document utilisable des mois plus tard, parce que chaque affirmation renvoie à un système, à un réglage ou à une pièce, pas à une impression.

À quelle fréquence refaire un audit

La réponse honnête est que l'intervalle suit le changement, pas le calendrier. Une entreprise qui ouvre un service public, migre vers un nouvel hébergeur, crée une filiale ou change de fournisseur d'identité a modifié son exposition, et le rapport précédent décrit un système qui n'existe plus. Une entreprise dont les systèmes n'ont pas bougé peut attendre plus longtemps sans prendre beaucoup de risque nouveau.

Le rythme courant est une revue complète par an, plus une passe plus étroite après chaque changement significatif. La revue complète couvre l'inventaire, l'architecture et la configuration. La passe étroite vérifie ce qui a bougé : un nouvel endpoint, un nouveau client, une nouvelle intégration, et les comptes arrivés avec elle.

Entre deux audits, ce qui garde un rapport à jour est la surveillance : la configuration correspond-elle toujours à la base, de nouveaux hôtes sont-ils apparus, un compte a-t-il été créé hors du processus. Un audit répété une fois par an et jamais surveillé entre-temps mesure l'entreprise le jour de la visite et ne dit rien des autres jours.

Ce que vous recevez à la fin

Le livrable est un document de travail pour celui qui doit agir, pas un certificat à ranger. Quatre choses séparent un rapport qui sert d'un rapport qui se classe.

• Un inventaire avec un statut par élément : dans le périmètre et revu, dans le périmètre et non revu, hors périmètre et pourquoi.
• Un écart par élément, nommant le système, le réglage et la référence à laquelle il a été comparé, avec la preuve jointe ou citée.
• Un ordre de priorité qui suit l'impact pour cette entreprise, pas l'ordre alphabétique d'une liste de contrôle.
• Une direction de correction que l'équipe peut appliquer sans seconde mission, et une façon annoncée de vérifier que la correction a tenu.
• Un résumé écrit pour celui qui signe, disant ce que l'audit a couvert et ce qu'il n'a pas couvert.

Tout ce que l'auditeur n'a pas pu vérifier va dans une annexe séparée avec sa raison. Une suspicion déguisée en constat coûte à l'équipe autant de temps qu'un vrai constat, et lui apprend à se méfier du rapport suivant.

Qui le lit

• L'exploitation lit l'inventaire et les écarts de configuration, parce que ce sont ceux qu'elle peut fermer.
• Le responsable de l'application lit l'ordre de priorité et la direction de correction.
• Celui qui arbitre le budget lit le résumé, et a plus besoin du périmètre que de la liste des constats.
• Un auditeur externe ou un assureur lit la méthode et les références, et c'est pour cela que les deux sont écrites plutôt que sous-entendues.

D'où viennent les références

Quatre documents publics font l'essentiel du travail, et aucun n'est le nôtre. L'ISO/IEC 27001 définit les exigences d'un système de management de la sécurité de l'information, le cadre dans lequel une entreprise décide qui est responsable de quoi et comment les décisions sont consignées. L'OWASP Application Security Verification Standard donne une liste d'exigences techniques pour une application web, de l'authentification à la protection des données, et c'est la référence qui transforme une revue de configuration floue en une suite d'énoncés vérifiables.

L'OWASP Top 10 est un document de sensibilisation, pas un plan de test : il nomme les catégories de risque que les applications web partagent le plus souvent, et il sert à expliquer un constat à quelqu'un qui ne lit pas de code. L'ANSSI publie des guides destinés aux organisations françaises, dont des documents écrits pour les petites et moyennes entreprises qui n'ont pas d'équivalent dans la documentation de la plupart des éditeurs de sécurité.

La directive NIS2 étend les obligations de cybersécurité à davantage de secteurs et à davantage de types d'entités dans l'Union européenne, et elle demande aux entités concernées de gérer un risque plutôt que d'acheter un produit. Un audit est l'une des façons de répondre à cette obligation. Il n'est pas l'obligation elle-même, et aucun rapport ne remplace les décisions que l'entité doit prendre.

Une référence se choisit avant le début du travail et se nomme dans le rapport. Un audit qui choisit son référentiel après les constats mesure les préférences de l'auditeur.

Sources

Chaque affirmation technique de cette page suit l'un de ces documents publics.

• ISO/IEC 27001 — exigences du système de management de la sécurité de l'information
• OWASP Application Security Verification Standard — les exigences techniques auxquelles une application web est comparée
• OWASP Top 10 — les catégories de risque que les applications web partagent le plus souvent
• ANSSI, publications — les guides de l'agence nationale française, dont ceux écrits pour les petites entreprises
• Directive NIS2 — le texte européen qui étend les obligations de cybersécurité

Là où une phrase de cette page n'est adossée à aucun de ces documents, elle décrit notre façon de travailler et non une règle du métier.