Audit ISO 27001 : quels processus et éléments de preuve sont exigés pour la gestion des vulnérabilités ?

Séparez le périmètre en deux : infra et code. Côté infra, lancez un scanner open source une fois par mois sur vos plages IP et générez un rapport. Côté code, intégrez un outil d'analyse de dépendances directement dans votre CI/CD pour bloquer le build si une vulnérabilité critique connue est présente. Les logs du pipeline constituent la preuve technique idéale pour un auditeur.

Lors de notre audit l'an passé, nous avons fixé des délais réalistes : 7 jours pour les failles critiques, 30 jours pour les élevées et 90 jours pour les moyennes. L'auditeur est tombé sur 4 failles élevées non corrigées, mais en voyant nos formulaires d'acceptation du risque accompagnés d'une justification métier, il a validé le point sans aucune non-conformité.

Votre dossier d'audit doit obligatoirement réunir ces quatre pièces : 1) La politique de gestion des vulnérabilités avec sa grille de SLA validée, 2) Les rapports de synthèse horodatés des scans des trois derniers mois, 3) L'historique des tickets prouvant la correction des failles, 4) Les formulaires d'acceptation du risque signés pour les failles non traitées pour des contraintes techniques ou opérationnelles.

surtout ne dites jamais à l'auditeur "on n'a aucune faille", ils vont direct se méfier et creuser encore plus. le mieux c'est toujours de monterr un tableau de suivi transparent qui prouve que vous trouvez des failles, que vous les classez par niveau de gravité et que vous les corrigez.

edit : j'ai écrit depuis mon téléphone, désolé pour les fautes.

et est-ce que l'auditeur ISO accepte comme preuve officielle des rapports générés par des outls de scan open source gratuits, ou il faut obligatoirement des rapports sous licence issus de logiciels de cybersécurité d'entreprise hyper chers ?

La marque de l'outil l'auditeur s'en fiche, ce qui l'intéresse c'est la méthodologie. Scannez tout de suite toutes vos IP externes avec un outil gratuit, exportez les vulnérabilités trouvées dans un tableur assignez-les aux développeurs responsables et datez celles qui sont résolues. Si vous montrez ce cycle sur deux mois, vous passerez l'audit sans problème.

Les consultants essaient souvent de faire peur pour faire acheter des logiciels de scan hors de prix. Pourtant, la norme n'exige pas la perfection, mais un mécanisme de contrôle bien défini. Même un simple script d'automatisation fait maison et des tickets réguliers passent très bien à l'audit si c'est intégré dans un cadre logique.

Je vais essayer.

Séparons les concepts, ils sont souvent confondus. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Je suis aussi curieux de savoir si d'autres font autrement.

C'est vrai en théorie, mais ça ne marche pas ainsi en pratique. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Bon courage.

il est rare de trouver un texe qui explique les choses aussi clairement.

Je suis d'accord, j'aimerais même souligner ce point. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Bon courage.

Il y a un piège ici, je ne pouvais pas ne pas le mentionner. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Je suis aussi curieux de savoir si d'autres font autrement.

Trois points à vérifier lors de cette opération. L'erreur commise du côté de gestion des vulnérabilités est généralement réversible mais coûteuse.

Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Je vous conseille de ne pas vous presser. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

enregistré.

J'y pensais aussi. Avant de décider, regardez quelles données vous avez en main.

Tout va bien les trois premiers mois, les problèmes arrivent au quatrième. À votre place, j'irais par cette voie.

C'est noté, merci.