Transcription

• Speaker #0

  Imagine, tu es confiant de ton analyse de risque. L'auditeur arrive et il te met une non-conformité majeure. Pourtant, tout est prêt. L'analyse de risque est faite, les actifs sont identifiés, la confidentialité, l'intégrité, la dispo, tout est couvert. On a analysé les serveurs, les laptops, le cloud, les fournisseurs, la supply chain, bref, un travail sérieux. Et pourtant, l'auditeur arrive et dit non-conformité majeure. Oui, une majeure. Pourquoi ? Bonjour et bienvenue dans Compliance without coma, le podcast où la cybersécurité et la conformité ne te donnent pas envie de dormir, sur ton analyse de risque, ou te reposer sur tes lauriers. C'est toi qui vois. Je suis Fabrice De Paepe et aujourd'hui, on va parler d'un sujet un peu particulier, un sujet qui me fait encore transpirer à chaque ISMS que je déploie. Donc, abonne-toi à Compliance Without Coma, n'oublie pas de liker, partager, c'est important pour continuer à pousser le podcast. Alors, à ton avis, pourquoi l'auditeur a mis une majeure ? Et note que c'est subjectif, hein ? Il aurait pu mettre une mineure, car il y avait des choses en place malgré tout. Ah, mais si je dis mineure... Cela veut dire qu'il manque un truc dans ton analyse de risque. Alors tu te rappelles de l'intro ? A ton avis, il manque quoi ? Ou plutôt, si tu ne trouves pas, via l'intro, l'intro a mis le focus sur quoi ? Exact, uniquement des contrôles. Et donc ça fait un peu trop ISO 27002, un peu trop de contrôle de l'annexe A, mais rien par rapport à l'ISMS. Et d'ailleurs, la norme dit... Lors de la planification du SMSI, l'organisation doit prendre en compte les points mentionnés dans la clause 4.1 et les exigences aussi mentionnées dans la clause 4.2. Les points 4.1 et 4.2, tu sais, les enjeux internes et externes de ton entreprise. Et aussi déterminer les risques et opportunités à traiter afin de garantir que le SMSI atteigne ses objectifs. On peut s'arrêter déjà, car tu as mis tous les contrôles. Tu as peut-être choisi les 93 dans ta SOA. Mais aucun objectif de ton SMSI ne se retrouve dans ton analyse de risque. Bon, pour la suite, j'ose espérer que t'as bon. C'est-à-dire prévenir ou réduire les effets indésirables, assurer une amélioration continue, planifier les actions à entreprendre pour gérer ces risques et opportunités, et la manière d'intégrer et de mettre en œuvre ces actions dans les processus de ton SMSI. Sans oublier d'évaluer l'efficacité de ces actions. Donc, pourquoi une majeure ? Parce que ton organisation n'a pas identifié les risques qui pourraient empêcher le SMSI lui-même d'atteindre ses objectifs. Tu saisis la nuance ? Et là, incompréhension générale. Parce que l'équipe sécurité répond, mais on a analysé tous les risques. Oui, tous les risques techniques. Mais ISO 27001 ne parle pas seulement de sécurité technique. Elle parle d'un système de management. Et un système de management peut échouer pour des raisons très différentes. Par exemple, un manque d'engagement de la direction. Un manque de ressources pour l'équipe sécurité, un changement organisationnel majeur, une dépendance excessive à un fournisseur cloud, une évolution réglementaire comme NIS2 ou DORA. Et là, tu vas devoir intégrer tout ça dans ton SMSI. Ce sont des risques qui ne concernent pas directement un serveur ou une application, on est d'accord. Ils concernent la capacité du SMSI à fonctionner. Et c'est exactement ce que l'auditeur cherche. Maintenant, une autre question arrive souvent. Est-ce qu'il faut relier chaque risque à un objectif de sécurité ? Ben non, c'est pas toujours faisable non plus. Ce que la norme attend, c'est une logique. Donc tu vas avoir ton contexte, avec ton SWOT, ton PESTEL. Attention, certains auditeurs les demandent au lieu de demander l'analyse, alors que c'est pas requis comme doc dans la norme. Tu vas regarder avec tes sources de risques, tes registres des risques, tes traitements, tes objectifs, par exemple. On peut... Faire une analyse de tout ce qui est threat intelligence, donc le renseignement sur la menace, qui va évoluer vers les risques en termes de ransomware, par rapport à un objectif, et l'objectif ce serait de dire, ok, améliorer la détection et la réponse aux incidents. C'est un des objectifs. Et tu vois que tu as une source de risque ici que je te donne, par exemple. Mais il n'y a aucune obligation de faire un mapping artificiel pour chaque ligne de ton registre des risques. Par contre, il y a un autre piège. Le jour où quelqu'un dit « on a tout traité, il n'y a plus de risque » , là, l'auditeur commence à se méfier. Parce qu'un SMSI sans risque, ça n'existe pas. Le contexte change, la réglementation change, les menaces changent. Les organisations elles-mêmes changent, le business évolue, donc les risques évoluent. Un ISMS mature ne prouve pas qu'il n'a plus de risques, il prouve qu'il continue à les détecter. Et là j'ai un souci avec certains auditeurs qui veulent que je clôture tous les risques. Mais bon, j'en ai déjà parlé et peut-être qu'on y reviendra. Mais c'est ça la vraie maturité. Parce que dans un système de management, le problème n'est pas d'avoir des risques, le problème c'est de croire qu'il n'y en a plus. Et c'est souvent là que les majeures commencent. Donc voici quelques pièges à éviter. Le premier piège, c'est confondre analyse de risque de sécurité et risque du SMSI. Beaucoup d'organisations analysent uniquement les risques liés aux actifs, serveurs, applications, données, etc. mais oublient les risques qui pourraient empêcher le SMSI de fonctionner correctement. Le deuxième piège, ignorer le contexte de l'organisation. Les risques doivent aussi venir du contexte identifié dans les fameuses clauses 4.1 et 4.2, organisationnelle, légale, économique, dépendance externe, et j'en passe. pense qu'on descend un peu comme en waterfall de la clause 4 à la clause 10. Ainsi, tu ne loupes rien. Troisième piège, ne pas relier les risques aux objectifs du SMSI. L'auditeur attend de voir comment les risques peuvent empêcher d'atteindre les objectifs de sécurité définis par la direction. D'accord, tu peux en avoir sur des assets précis, mais tu peux aussi avoir une contrainte budgétaire d'un groupe qui veut que tu fasses plus avec moins de ressources. C'est un risque. Le quatrième piège, et c'est le but de ce podcast-ci, se limiter aux risques techniques. Les normes ISO attendent aussi des risques organisationnels, humains et stratégiques. Donc voici quelques exemples de risques qui auraient pu être identifiés et qui auraient probablement évité la non-conformité majeure. Un risque de gouvernance, un manque d'engagement de la direction pouvant compromettre l'allocation de ressources nécessaires au SMSI. Mais c'est parfois compliqué à faire valider par la direction elle-même, donc je te laisse à tes talents de psy pour faire passer la pilule. Un risque organisationnel, un turnover élevé dans l'équipe sécurité entraînant une perte de compétence critique pour le fonctionnement du SMSI. Ou bien, tu sais, le know-how d'une boîte de 30 personnes qui est sur trois têtes. Un risque de dépendance fournisseur, une dépendance excessive à un prestataire cloud unique pouvant affecter la continuité des opérations de sécurité. Un risque réglementaire, évolution des exigences réglementaires, NIS2, DORA. je ne vais pas toutes les citer ici, pouvant rendre les contrôles actuels insuffisants. Il y a également le risque de sensibilisation. Un faible niveau de sensibilisation des employés entraînant un risque accru de phishing et compromettant l'efficacité du SMSI. Mais celui-là, peut-être au début de ton lancement du SMSI. Ensuite, au fur et à mesure où tu vas déployer des choses, il pourra être réduit. Il y a également un risque de ressources. Un budget insuffisant pour maintenir les outils de sécurité nécessaires à la surveillance du SMSI. Alors tu vois, ces risques ne concernent pas directement un serveur ou une application. Ils concernent la capacité du système de management à fonctionner et à atteindre ses objectifs. Et est-ce que les objectifs tiennent compte des principaux risques identifiés ? C'est précisément ce que l'auditeur cherche à voir. Donc est-ce que les risques identifiés dans ton risk universe... permettent d'empêcher le SMSI de fonctionner correctement, lui-même, qui, je te le rappelle, est censé s'aligner sur les objectifs business. Oui, car dans le cours CISM de l'ISACA, chapitre 1, il est dit qu'on doit aligner l'IT et la sécurité sur le business. Tu vois, il n'y a pas que la norme qui parle de gouvernance. Donc, par contre, j'ai beau relire la norme, elle n'impose pas une relation un risque égale un objectif. Alors, beaucoup d'organisations font un agrégat de sources de risque. Ce qui est tout à fait acceptable. Par exemple, on a le threat intelligence, on a les incidents qui se sont déjà produits, des demandes de parties intéressées, des exigences réglementaires, le contexte organisationnel, des audits internes, ou plutôt le rapport des audits internes, et le feedback et le retour du management review. Ensuite, ces éléments viennent alimenter un registre des risques global du SMSI. A partir de ce registre, il définit quelques objectifs de sécurité stratégique, par exemple. Réduire les incidents de phishing, améliorer la détection des incidents, renforcer la gestion des fournisseurs critiques, pas tous, critiques, améliorer la conformité réglementaire, et ces objectifs couvrent un ensemble de risques, pas un seul. Et ce que les auditeurs aiment voir, c'est une logique claire de type, ok, il y a un contexte, je vois des différentes sources de risques, ça vient nourrir le registre des risques, il y a un traitement. on touche aux objectifs, on est capable de mesurer si on s'améliore ou pas. Par exemple, Threat Intelligence peut pointer vers le risque d'attaque de ransomware, alors qu'un des objectifs était d'améliorer la détection et la réponse aux incidents. C'est un des objectifs. avec un des contrôles. Tu vois qu'on n'est pas forcément aligné sur un contrôle égal à un objectif et vice-versa. Donc tu n'as pas besoin de créer un mapping artificiel pour chaque risque. Et l'auditeur doit simplement pouvoir comprendre que les objectifs du SMSI répondent aux principaux risques identifiés. A toi de lui vendre ça, c'est du storytelling, mais basé sur les faits, d'accord. Et voilà pour cet épisode. Donc si tu es en train de préparer une certification ISO 27001, retiens surtout ceci. Une analyse de risque parfaite sur les serveurs, le cloud. Ou les fournisseurs ne suffit pas. L'auditeur regarde aussi ton SMSI lui-même et comment il peut fonctionner et atteindre ses objectifs. Parce qu'au final, ISO 27001 ne parle pas seulement de technologie, elle parle de management. Et pas n'importe lequel, tu as saisi la suite. Management de la sécurité de l'information. Et c'est même un système. Et dans un système de management, les vrais risques sont parfois ailleurs. La gouvernance, les ressources, les dépendances ou tout simplement l'évolution du contexte. Le CISO qui prend des cours de moto, même s'il est prudent. Des petits ennuis géopolitiques qui mènent à des DDOS. Donc la prochaine fois que tu mets à jour ton registre de risque, pose-toi une question simple. Est-ce que j'analyse seulement les risques pour mes actifs ou les risques pour mon SMSI ? Si cet épisode t'a aidé à éviter une non-conformité majeure, alors mission accomplie. Et si tu veux continuer à parler de cybersécurité, d'ISO, d'audit et de gouvernance, sans jargon inutile et sans tomber dans le coma, abonne-toi à Compliance Without Coma. N'oublie pas de liker, partager, c'est important pour continuer à pousser le podcast. On se retrouve la semaine prochaine pour un nouvel épisode de Compliance Without Comma.