Transcription

• Speaker #0

  Est-ce que cela t'est déjà arrivé de devoir évaluer un framework de contrôle interne IT et dans une institution financière ? Donc pas auditer un contrôle, pas auditer un processus IT, mais auditer un processus qui teste des contrôles. Un métaprocess, un mégalodon. On est un peu loin du standard ISO 27001 là, et là je t'avoue qu'à la place, ce serait un petit requin blanc à côté. Bonjour à toi, et bienvenue dans Compliance Without Coma, le podcast où la cybersécurité et la conformité ne te donnent pas envie de dormir. Je suis Fabrice De Paepe, et aujourd'hui, on va parler d'un sujet un peu particulier, un sujet qui fait transpirer l'âme des auditeurs expérimentés. Alors, auditer un SMSI ISO 27001, c'est déjà auditer un monstre, un peu comme un grand requin blanc. C'est impressionnant. Mais on sait à quoi s'attendre. Il a des dents, il nage vite, il peut faire mal. Mais auditer... un métaprocess, c'est autre chose. Là, tu es en face du mégalodon. Parce que tu ne vois plus directement ce que tu audites, tu dois auditer la capacité d'une organisation à savoir si ses contrôles fonctionnent. Et ça, c'est un niveau d'abstraction au-dessus. Alors l'erreur que font beaucoup d'auditeurs dans cette situation, eh bien, ils essayent d'auditer les contrôles. Mais c'est pas le sujet. Le sujet, c'est comment l'organisation sait que ses contrôles fonctionnent. C'est complètement différent. Et là, il y a une phrase clé, une phrase qui débloque tout. Tu n'audites pas les contrôles, tu n'as pas le temps. Tu audites la capacité de l'organisation à savoir si ces contrôles fonctionnent. Et quand tu comprends ça, tout devient plus clair. Alors, il y a une approche qui marche, parmi tant d'autres, c'est la tortue. Donc déjà, ça fait moins peur que le mégalodon. Tu réduis ton mégalodon à une tortue. J'adore utiliser les tortues, les turtle diagrams comme on dit. Parce qu'en fait, ça force à structurer la pensée. Même si je ne vais pas à chaque fois jusqu'à le définir formellement pour mes clients, mais ça m'aide dans les workshops. Donc, ton framework de contrôle à Internet IT avec tes 400 contrôles, prends-le comme un gros process, un mégalodon, réduis-le à un turtle diagramme et audite juste ça. Tu prends le process de testing des contrôles et tu regardes les inputs, les outputs, les acteurs. Les outils, les méthodes, les indicateurs. Et déjà, tu vois si ce mégalodon est complet. Peut-être que ton client n'aura pas ça. Mais au moins, tu sais ce que tu dois demander en termes de contenu. Alors, le Turtle Diagram, je te laisse aller voir sur ton moteur de recherche préféré. Mais en gros, ils vont te dire que c'est la bête à quatre pattes. Une tête, une queue et un corps. Mais moi ici, je vois plutôt ça comme ça. Je vais l'utiliser comme Control Testing. Pour ma tête, dans mon input, quelle est la librairie de contrôle ? Quelles sont mes politiques, mes standards ? L'appréciation du risque, et non pas l'analyse du risque. D'ailleurs, je devrais faire un podcast également sur cette différenciation. Quelles sont les exigences en termes de régulation ? DORA, BCE, Banque de France, Banque Nationale de Belgique, que sais-je ? Quels sont les findings précédents ? Ça, ce n'est rien que pour l'input. Ensuite, on prend la queue, l'output. Quels sont les résultats de test ? Quel est le niveau d'assurance, une fois que tu es sorti du process ? Est-ce que tu as trouvé de nouveaux findings ? Ou ton client a-t-il trouvé de nouveaux findings ? Ou quels sont les enjeux, les problèmes ? Est-ce qu'il y a du reporting au management ? Est-ce qu'il y a des plans de remédiation ? Et avec quoi ? Est-ce qu'il y a des outils GRC ou d'autres ? Est-ce qu'il y a des scripts, des méthodologies, des templates ? Une approche d'échantillonnage ? Avec qui ? Donc la première ligne IT, la deuxième ligne de risque, l'audit interne ? les propriétaires de contrôle, tous ceux qui sont dans les modèles de lignes de défense, en fait. Et qui est le manager du mégalodon ? Est-ce que c'est un programme directeur ? Est-ce que c'est l'head of compliance, si tu veux ? Je n'en sais rien. Mais c'est un programme avec un ensemble de projets et d'actions et de stakeholders. T'imagines, il y a 400 contrôles. Alors comment ? Comment vont-ils faire ça ? Est-ce qu'ils ont un planning annuel ? Est-ce qu'ils ont des campagnes de tests ? Ou bien de l'échantillonnage sur les contrôles ? C'est eux qui doivent le faire, l'échantillonnage. Toi, en tant qu'auditeur, tu vas leur demander. Ou tu pourrais aussi prendre des échantillons basés sur des risques d'audit. On verra ça un peu plus loin dans le podcast. Et est-ce qu'il y a une collection d'épreuves ? Est-ce qu'ils ont de la doc ? Et pour les indicateurs, on est sur une couverture, disons, de 400 contrôles. J'exagère. Mais on est à combien de pourcents ? 5, 10, 30 ? 30% de 400 contrôles, c'est quoi la roadmap ? Quels sont les contrôles testés versus ceux qui sont planifiés et donc pas encore testés ? Rien ne te choque dans la liste de ces contrôles-là ? Creuse par là, tu verras bien. Est-ce qu'on est capable de détecter des déviations ? Est-ce que si mon mégalodon part à gauche, on s'en rend compte ou pas ? Combien de temps faut-il pour remédier à ces déviations ? C'est quoi la tendance ? Elle monte, elle baisse ? Ou bien tu vas mettre NA pour Not Applicable ? Donc c'est quoi la tendance d'efficacité de leur propre contrôle, du mégalodon qui va aller vérifier ses propres contrôles ? Et surtout, imagine, je suis ton CEO, de ta boîte, de ta boîte financière ou n'importe quoi. Est-ce que je peux dormir sur mes deux oreilles ? Ou bien j'ai du souci à me faire ? Pense à ça pour auditer le mégalodon. Parce que tu n'auras pas le temps de tout faire. Alors on va voir 5 questions magiques qui peuvent te permettre de débloquer ce genre de situation quand tu dois auditer un mégalodon. La première, la couverture. Tu peux te poser à ton client comment sais-tu que tous les contrôles importants sont testés ? Et s'ils viennent avec un framework de 400 contrôles qui s'enchevêtrent, tu fais comment ? Donc pose-leur la question, qu'ils t'expliquent eux comment ils font. Fais des liens avec une CMDB, tu sais, si je parle d'ITIL, la Configuration Management Database. Fais des liens avec l'inventaire des assets, parce que tu as besoin des actifs pour aller voir où sont les risques. Et quelle est la criticité de tout ça, en termes de priorisation ? Tu auras déjà une idée s'ils maîtrisent ou pas. La deuxième question que tu peux poser, c'est sur l'échantillon. Comment est-ce que ton client va choisir ce qu'il va tester ? Est-ce qu'il va faire des rotations ? Est-ce que c'est basé sur les risques ? Est-ce que c'est complètement aléatoire ? Est-ce qu'il y a une logique ou est-ce qu'il n'y en a pas ? Est-ce que tu vois déjà un trou dans les contrôles qui te dit qu'il fait ? Troisième question, on descend à profondeur ? Si, un mégalodon, ça doit descendre profond. Donc, comment savez-vous que le contrôle fonctionne réellement ? Pas juste, oui, oui, oui, c'est en place, c'est compliant, on a décrit les process. Mais donne-moi des preuves. Et en termes de remédiation ? pour le quatrième point. Quand un contrôle échoue, que se passe-t-il ? Est-ce qu'ils ont un ticket ? Est-ce qu'ils ont un plan d'action ? Est-ce qu'ils font un retest, plus tard, avec l'audit interne ou que sais-je ? Sinon, c'est une illusion de conformité. Et le cinquième point, globalement, c'est l'assurance globale. C'est la question magique. Pourquoi êtes-vous confiant que votre framework, le mégalodon, votre framework de contrôle, fonctionne ? Tu as entendu ce silence aussi ? Il est souvent très révélateur. Parce qu'au fait, au fond, plutôt, la maturité, c'est ça qu'on évolue ici. Tu vas évaluer la maturité du mégalodon. Donc, on peut avoir plusieurs niveaux. On peut avoir un niveau 1 ad hoc. On teste quand on a le temps. On peut avoir un niveau 2 répétable. Il y a des campagnes de tests, mais la couverture, elle est floue. Un niveau 3, ok, c'est structuré, méthodologique, c'est clair. Un niveau 4, c'est basé par rapport aux risques de l'entreprise. Et donc là, la couverture, elle est démontrable. Et le niveau 5, le saint Graal, c'est un monitoring continu avec de l'automatisation. Je t'avoue que s'ils viennent de démarrer leur framework, tu n'auras pas ça. Mais ils ne peuvent pas atteindre ce niveau-là, pas tout de suite. Donc, c'est quoi le plan alors ? Quelle est la roadmap ? Est-ce qu'il y a une priorisation des contrôles pour ton client ? C'est basé sur quoi cette priorisation ? Sur quelle régulation ? Et quel est leur appétit du risque ? Et en fait, dans les institutions financières, le régulateur attend au moins que tu aies un niveau 3 ou un niveau 4 en maturité. Et je ne vais pas te lancer toutes les échelles de maturité ici, ce n'est pas le but. Par contre, pour t'aider à dépatouiller le bazar, on pourrait se baser sur est-ce qu'on a une faible maturité ou une bonne maturité. Donc les critères d'évaluation de maturité que tu pourrais utiliser seraient de dire est-ce que le mégalodon a une faible maturité ou bien une bonne maturité ? Et si tu sais que ton client démarre, oui, il faudra être patient. Donc faible maturité, testing complètement ad hoc, couverture des contrôles très floue, inconnue, échantillonnage arbitraire, pas de traçabilité, pas de retest, et une bonne maturité serait... Une planification basée sur les risques. Un risque d'audit, quoi. Une couverture et un progrès démontrables. Une méthodologie claire, une preuve standardisée. J'ai pas encore parlé de SOC 2 type 2, t'imagines. Le suivi des findings, le reporting au management. Alors, je te le concède, ça sera pas complètement tout vrai ou tout faux. Je te laisse à ton jugement d'auditeur pour évaluer tout ceci, bien sûr. Mais le vrai enjeu, finalement, pourquoi c'est important ? Parce que les organisations modernes sont complexes. Trop complexes pour vérifier chaque contrôle individuellement. Donc on met en place des systèmes d'assurance, et auditer ces systèmes, c'est auditer la confiance. D'ailleurs, il y a un petit parallèle avec l'ISO 27001, quand tu y penses, c'est que l'ISO 27001 fait déjà ça, dans la clause 9. On a le monitoring, la mesure, l'audit interne, la revue de direction. C'est déjà un méta-niveau, en quelque sorte. Mais ici, dans un méta-process, on monte encore d'un cran en abstraction, on monte d'un étage. Bon, retour au mégalodon. C'est pour ça que la métaphore du mégalodon, elle marche bien. Parce que le problème, c'est pas la taille du monstre. Le problème, c'est quand tu ne sais pas où il nage. Alors, une des approches d'audit, parmi tant d'autres, serait d'utiliser ce que moi j'appelle le top-down plus le spot-check. Donc, comprendre le process, le fameux mégalodon, vérifier la méthodologie, prendre quelques assets critiques, les IAM, notamment dans les banques, Identity and Access Management, ou dans la finance, déjà c'est très gros, revoir les preuves. Et pas rejouer techniquement, mais juste vérifier la cohérence, la traçabilité, la logique. Si tu as le temps de vérifier techniquement, ok, fais-le. Et puis, au milieu de ça, c'est toi qui connais ton client et son risque. Donc tu pourrais vouloir voir comment un contrôle en particulier sur les 400, imagine, a été testé sur ce système précis. Et regarder s'il y a des tickets, s'il y a des évidences, donc des preuves, s'il y a des logs, s'il y a des captures, s'il y a des rapports. Donc sur les 400, tu peux tester selon les risk-based approach, 3-4 contrôles, et tu fais tourner le propre framework dedans. Mais logiquement, s'ils ont une bonne maturité, c'est déjà à eux de démontrer les preuves. Après, si on parle de ce process forcément dans la finance, il y a déjà quelques gros risques à creuser, sans connaître leur analyse de risque. Tu as identifié IAM, Identity and Access Management, mais il y a aussi Asset Management et CMDB, donc la Configuration Management Database, les fournisseurs, souvent le maillon faible. les accès privilégiés, le change management, et maintenant la cerise sur le gâteau, le cloud. Je n'ai même pas parlé d'IA, pas encore. Donc, focus là-dessus, déjà. Et je pense que ça peut directement être transversal et standard à toute institution financière. Donc tu vois, tu n'audites pas les contrôles, tu audites la capacité de l'organisation à savoir si ces contrôles fonctionnent. Ça change tout. Autre chose, si par exemple tu es coincé sur l'échantillonnage IAM, essaie de regarder au niveau sélection d'assets qui change. Et si tu es coincé sur un type d'échantillon ou de l'échantillonnage, essaie de vérifier la rotation qu'ils ont utilisée. Est-ce que c'est systématiquement la même par rapport à la population ? Est-ce que la couverture est périodique ? Du style, on doit tester 50 applications critiques, et je vais tester, il y a 52 semaines dans une année, je vais donc tester une restauration, on dit une restauration par semaine, et un backup et un restore par semaine, ce qui veut dire que chaque application aura été testée au minimum une fois par an. Est-ce que ça répond bien au risque ou pas ? Donc regarde au niveau sélection de l'échantillonnage, si c'est bien basé sur le risque également. Sinon... tu risques aussi d'avoir un trou de contrôle. Donc en guise de conclusion, si un jour tu es amené à auditer un méta-process, un mégalodon, souviens-toi. Ne plonge pas dans les contrôles. Regarde la méthode, la couverture, la logique, la confiance. Parce que la vraie sécurité, c'est pas d'avoir des contrôles, c'est de savoir s'ils fonctionnent vraiment. Voilà, c'était Compliance Without Coma, le podcast où la conformité ne te met pas dans le coma. Si l'épisode t'a plu, pense à le partager, à laisser une note ou un commentaire. Et en attendant, reste agile, reste critique et surtout reste éveillé. A la semaine prochaine déjà pour un autre épisode de Compliance Without Coma.