Le client exige une gestion des vulnérabilités conforme au BSI — que mettre en place concrètement en Allemagne ?

Dès qu'on entend parler du BSI, les petites équipes ont tendance à paniquer devant les centaines de pages des guides IT-Grundschutz. Le client ne demande très probablement pas une certification complète, juste une preuve d'exploitation à présenter lors des audits. Si le contrat n'impose pas formellement ISO 27001 ou un label BSI fournissez simplement un document de processus et des rapports de scan réguliers sans cramer tout votre budget.

Côté technique pour vous simplifier la vie, intégrez des scanners de dépendances open source en continu et des outils d'analyse de vulnérabilités au niveau serveur. Si vous branchez un webhook qui pousse directement les alertes CVE dans votre outil de ticketing, le sysadmin n'aura plus besoin de tenir de listes à la main. Les auditeurs BSI vérifient souvent s'il y a des serveurs fantômes non analysés, donc incluez bien l'ensemble des sous-machines du domaine dans le scope.

Sur un projet public équivalent, on a pris une licence de scanner de vulnérabilités à 2.200 EUR par an. Le setup complet nous a pris 3 semaines. Notre sysadmin passe 2 heures tous les lundis à éplucher les alertes BSI et CERT, plus 6 heures par mois pour rédiger les rapports. Grâce à cette routine, on a validé les deux derniers audits clients sans la moindre réserve.

Ce que vous pouvez faire dès demain au plus vite : 1) Dressez un inventaire clair de vos serveurs et bibliothèques sous forme de tableau. 2) Abonnez-vous à la newsletter gratuite du CERT-Bund. 3) Rédigez une politique de sécurité de deux pages fixant les délais de déploiement des correctifs et faites-la signer en interne. C'est le premier document que le client vous demandera lors de l'audit.

On a eu exactement la même exigence sur un appel d'offres pour un logiciel de santé à Munich. Au premier audit, ils nous ont demandé : « Vous avez mis combien de temps à corriger la faille critique du noyau le mois dernier, où est la trace ? » On avait pourtant poussé le patch en prod en 4 heures, mais comme on n'avait pas ouvert de ticket pour tracer l'heure, on s'est pris un avertissement. Tout le secret réside vraiment dans la traçabilité.

Votre client fait-il explicitement référence au module OPS.1.1.3 (Patch- und Änderungsmanagement) du BSI IT-Grundschutz dans le cahier des charges ? Si ce composant est exigé, vous devez impérativement lier votre gestion des changements (Change Management) au processus de validation des correctifs.

on est passés par là aussi, mettez des bots d'analyse de vulnérabilités auto sur vos dépôts git. du coup faut que ça scanne les libs à chaque build. même un simple organigramme monrtant que rien ne part en prod sans être au vert sur l'environnement de test suffit à rassurer le client.

Dans la mesure où votre client est lié au secteur public, il est tenu de garantir la conformité aux normes BSI dans le contrat de sous-traitance. Votre documentation doit obligatoirement inclure une matrice des responsabilités (RACI), une procédure d'application des correctifs d'urgence ainsi qu'un engagement à réaliser un audit externe annuel. Il est essentiel que ces documents soient validés par la direction de votre entreprise.

Il faut faire une distinction ici. Le temps que vous mettez à détecter un problème détermine directement son coût.

Voilà, désolé si je me suis étendu.

Comment avez-vous résolu ce point ? Le vrai problème n'est pas le chiffre mais la base sur laquelle il est calculé.

Désolé, mais ce n'est pas vrai dans tous les cas. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Bon courage.

J'ai travaillé longtemps sur ce sujet. Tous ceux qui se pressent sur bsi gestion des vulnérabilités se heurtent au même obstacle.

Merci de partager le résultat. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Je le note au cas où.

Je suis intéressé.

Il y a un point que je ne comprends pas. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Bon courage.

C'est exactement ça. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

La discussion part dans tous les sens, je recentre. Si c'est une première, commencez petit l'échelle viendra plus tard.

La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale. J'espère que cela vous sera utile.

Vous avez raison. Les décisions hâtives finissent par être corrigées six mois plus tard.

Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.