Bien sûr, voici une proposition d’article présentant les pièges à éviter lors de l’implémentation d’une norme ISO27001 dans une société.
Ca va, je rigole… et puis entre nous ChatGPT n’est pas encore prêt à vous partager les petits pièges que vous rencontrerez lors d’un projet d’implémentation. Dans le monde de ChatGPT, tout est péremptoire, tout est facile. Sorte de boss de fin de la tribu des “yakafokon”.
Car oui dans la vraie vie tout n’est pas aussi rose….
A force d’implémentation, on arrive à distinguer des écueils dans lequel tombent régulièrement les entreprises lorsqu’elles abordent ce type de projet. Entre mauvaise foi et réelles galères, petit tour d’horizon de ces cailloux dans la chaussure qui agrémenteront à coup sûr votre voyage.
Penser que tout ceci aura une fin
Voici un point que je répète à l’envi lors du démarrage d’une implémentation : “La certification n’est pas l’objectif principal. C’est une conséquence ! ” Conséquence d’une démarche de prise en compte de la sécurité dans votre pratique quotidienne et à tous les échelons de l’entreprise (métiers, techniques, RH, finance, legal). Au même titre que vous disposez d’une activité RH ou Développement vous aurez à présent une activité de sécurité qu’il va falloir piloter et vous devrez y consacrer du temps et des moyens long terme si vous voulez que cela fonctionne.
Aborder une implémentation sur la base d’une gestion de projet (avec la mise à disposition de moyens exceptionnels “le temps de”) est une erreur fondamentale. Le risque est de mobiliser fortement les équipes sur un temps court. Et vous savez quoi? Ils n’auront qu’une envie : Retourner à leurs petites habitude dès le premier certificat obtenu!
Voici à peu près la meilleure garantie pour perdre votre certification dès le premier audit de surveillance. (si vous voulez voir comment se déroule un audit, c’est par ici)
Alors avant de vous lancer, assurez vous que vous disposerez de moyens à long termes pour faire vivre cette activité.
S’imaginer qu’il suffit de documenter
“Ho bah ISO c’est assez simple, on fait une 2 ou 3 politiques et hop ça passe”…No comment.
La norme ISO27001 paye le lourd tribut de son patronyme. La perception des normes ISO est très liée aux processus de qualité et de son fer de lance la norme ISO9001 - sorte de machin dont on ne comprend pas grand chose et qui nous force à remplir 10 formulaires dès qu’on veut bouger une oreille. Cela crée beaucoup de croyances limitantes lorsqu’il s’agit de sécurité de l’information. Beaucoup de clients pensent encore qu’il suffit d’écrire un début de politique générale de sécurité dans laquelle on s’engage la main sur le cœur à faire ceci et cela.
Or, la chute risque d’être douloureuse le jour de l’audit. Finalement tout l’enjeu de cet audit est justement en partie de vérifier que tout ce que vous avez raconté dans votre politique existe bel et bien dans votre organisation. D’où la nécessité de bien mesurer la portée de ce que vous allez écrire dans votre politique et éviter autant que possible de vous tirer une balle dans le pied.
Un système de gouvernance de votre sécurité se traduira nécessairement par une empreinte sur le terrain, qu’il s’agisse de technologies, de processus, de contrôle et parfois même de formulaire. Ce qui nous amène tout naturellement au point suivant.
Croire que rien ne changera
Combien de fois ai-je entendu :
- “Alors c’est super votre truc, mais j’aimerai que vous n’embêtiez pas nos devs avec ça car ils ont déjà beaucoup à faire”
Ce à quoi je réponds :
- “Donc de votre point de vue, l’activité de développement ne doit pas être inclus au périmètre de la certification, et par conséquent on exclut votre “produit” de ce périmètre?”
La réponse se fait rarement attendre :
- “ha bah non, il faut que le produit soit inclus, c’est pour lui qu’on fait tout ça “
Ce qu’il est important de comprendre à ce stade c’est que la prise en compte (réelle) de la sécurité dans vos processus impliquera des adaptations de vos pratiques actuelles. Ces adaptations consisteront principalement à mettre en oeuvre des points de controles supplémentaires. Il n’est pas ici question de changer vos pratiques mais d’y ajouter des vérifications portant sur la sécurité de l’information. Et ceci est valable pour à peu près toutes les fonctions de votre organisation. Car la sécurité se joue partout et par absolument tout le monde dans une société.
Cette notion de changement est aussi directement liée à votre de maturité initiale. Si dans votre organisation la sécurité est une option qui n’est pas utilisée (ex: postes de travail non protégés, aucune gestion des accès logiques , méthode de dev d’un autre temps), alors forcément le changement risque d’être beaucoup perceptible et les changements plus nombreux que pour une organisation plus mature sur la question.
Penser que c’est un projet IT
J’aime beaucoup travailler le sujet de la sécurité par le prisme de la technique, mais en vérité ce n’est qu’une partie du référentiel. Lorsqu’il s’agit d’aborder les questions RH, gestion des fournisseurs, revue des exigences légales ou encore sécurité physique notre pauvre CTO peut vite se retrouver à court d’information. Et pour cause : ce n’est pas son métier !
Bien sûr que l’informatique est le support majoritaire de l’information. Mais il s’agit simplement d’un support comme un autre. Attendez vous donc à ce que vos équipes hors IT soient sollicitées tant lors du volet implémentation que lors du maintien de votre système de management en conformité. L’adage “la sécurité est l’affaire de tout le monde” n’aura jamais été aussi vrai.
Il est important de dissocier la personne qui sera en charge du projet et celle qui sera en charge de faire vivre votre système de management.
Négliger la menace interne
- “Alors tu sais Damien, chez nous on mise beaucoup sur la confiance, j’y crois pas au scénario de la menace interne…”
(Rire sarcastique)
Bon vous l’aurez compris, cet argument ne tient pas une seule seconde.
Souvent je constate que les clients bâtissent une jolie forteresse qu’ils pensent imprenables en empilant les couches techniques.
Mais dès lors qu’on a passé le pont levis de cette forteresse c’est carrément la fête du slip ! Pas ou peu de contrôle d’accès, encore moins de revue, la classification n’en parlons même pas. Comme si l’information d’une entreprise était une sorte de plat géant dans lequel tout le monde se sert. L’argument éternel est celui du “on a rien à cacher”. Or à l’usage on se rend compte que certaines données d’une entreprise sont pourtant bel et bien tenue à l’écart de ce plat commun (rien que le tableau des rémunérations est l’équivalent des codes nucléaires pour nombre de sociétés).
Que la société qui n’a jamais été victime d’une fuite de données provenant d’un interne ou d’un futur ex interne me jette la première pierre.
Au hasard (et sans ordre de préférence) : un commercial qui télécharge le fichier client, le DPO qui copie les politiques de conf pour en faire des templates, le recruteur qui récupère des CVs, le dev quelques bouts de codes. Les scénarios sont innombrables et malheureusement dans bon nombre de cas les sociétés n’ont rien prévues pour couvrir ce risque.
Par ailleurs, il ne s’agit pas seulement de préserver les actes malveillants provenant d’un interne. Imaginez un instant que l’identité de l’interne ai pu être corrompue, si vous n’avez mis aucun mécanisme de contrôle en place, vous offrez à l’attaquant la possibilité d’accéder à toute l’information de votre boite avec un seul compte : Merci pour lui il n’en demandait pas tant...
Jouer petit bras
Et pour finir, je dirai que la plus grosse erreur serait de jouer petit bras. Partez du principe que la sécurité est une démarche couteuse, chronophage, complexe. Et votre niveau de sécurité n’aura d’égal que l’investissement et l’importance que vous lui apporterez. Je vois encore trop de société qui perdent complètement de vue le principe fondamental d’amélioration continue. Cela signifie qu’il ne faut pas avoir peur de se projeter à moyens et longs termes. Un exemple tout bête, combien de sociétés se contentent d’un petit pentest en black box tous les ans ? En vérité presque toutes, alors qu’une réelle démarche consisterait à définir des objectifs (sur une durée de 3 ans par exemple ) et d’adapter la démarche d’audit sur ces 3 ans, en multipliant par exemple les approches (une année en black box, une année en white box, une année en pentest interne) bref de ne pas avoir peur de se challenger. Notez que cet exemple est adaptable à peu près tous les pans de votre système de management.
L’autre phénomène que je constate est le manque d’outillage sur tous ces aspects de sécurité technique ou de maintien de conformité. Ces outils peuvent grandement vous faciliter la vie (bien que ça ne soit pas magique, j’en parlais justement ici)
En synthèse : gardez en tête que le temps est votre allié, alors tachez de bien l’utiliser!
Allez un peu de transparence, c'est anonyme ;)
En toute franchise, dans quel piège seriez vous tombé ?
J'aurai pensé qu'il y avait une fin à ce type de démarche.
Que la documentation aurait suffit.
Que le projet aurait pu se faire dans un coin.
J'aurai confié cela uniquement à l'IT.
You can vote for more than one answer.