Visibilité, évolutivité et relations dans le développement sécurisé : Phil Guimond de ViacomCBS témoigne

Je me suis récemment entretenu avec Phil Guimond, Principal Cloud Security Architect chez ViacomCBS. Il décrit son rôle comme une façon élégante de dire qu’il aime s’impliquer dans absolument tout „¢. Cela comprend la sécurité et l’architecture cloud, la sécurité des applications, les tests d’intrusion, l’investigation numérique et la réponse aux incidents, mais aussi, de temps à autre, l’évaluation des fournisseurs et la gestion des risques. Il travaille au sein d’une équipe très transversale.

Nous avons eu une excellente discussion, que je souhaitais partager avec vous. Nous avons parlé des pratiques de sécurité, des approches du développement sécurisé moderne et de bien d’autres sujets. J’espère que cet échange vous plaira autant qu’à moi.

Pour commencer, j’ai demandé à Phil quelle était son approche générale de la sécurité et quels étaient, selon lui, les principaux points à privilégier lors de la mise en place d’un programme de sécurité de l’information.

Guimond : Pour moi, la sécurité de l’information repose sur la visibilité, l’évolutivité et les relations. C’est une méthode que j’ai développée au fil des ans grâce aux nombreuses personnes formidables avec lesquelles j’ai travaillé, notamment Jonathan Keith, notre CISO chargé du streaming, qui a été un excellent mentor. Au cours des dernières années, quand j’intervenais comme consultant sur la réponse aux incidents, j’ai constaté qu’il manquait beaucoup d’informations. Pas de journaux... rien. J’avançais pratiquement toujours à l’aveugle et devais m’appuyer entièrement sur des outils CLI standard pour repérer les problèmes. Ma principale recommandation après chaque incident était de mettre en place un système de journalisation adapté pour assurer la visibilité. Peu importe combien vous dépensez en outils de sécurité si vous ne pouvez pas voir ce que vous devez protéger ni ce qui s’est passé en cas de compromission. Comment savoir ce qu’il faut protéger si vous ne pouvez pas voir ce qui s’est passé ?

La visibilité est souvent considérée comme un indicateur clé, qui nous permet de hiérarchiser les risques et les informations utiles dans toute l’organisation. Je voulais savoir comment Phil s’appuie sur les données de visibilité dans son travail au quotidien.

Guimond : La visibilité nous permet de réagir à un nombre incroyable de problèmes, où qu’ils surviennent, qu’il s’agisse de menaces anciennes, nouvelles ou émergentes. Elle ouvre tellement de possibilités qu’on en est parfois surpris. C’est particulièrement enthousiasmant lorsqu’on rencontre une situation inédite et que les outils de visibilité montrent exactement ce qui s’est passé. La visibilité améliore considérablement la réponse aux incidents, les tests d’intrusion, la sécurité des applications et du cloud, la gestion des risques et des vulnérabilités, et presque tous les autres domaines.

En cas d’attaque de la chaîne d’approvisionnement impliquant des bibliothèques open source compromises ou vulnérables, vous pouvez voir quelles applications les utilisent, puis les supprimer rapidement de vos projets, les mettre à niveau ou les corriger vous-même. Si une infrastructure cloud ou réseau est compromise, vous pouvez rapidement trouver le responsable, déterminer l’origine de l’attaque et voir ce que les attaquants ont fait avec les ressources ciblées. Et surtout, identifier la mauvaise pratique qui a conduit à cette compromission. Vous pouvez ensuite facilement isoler ces ressources de toute infrastructure et annuler toutes leurs actions non autorisées en une seule fois. Si l’ordinateur portable d’un employé a été compromis, vous pouvez voir ce que l’attaquant a fait avec ses identifiants et quelles ressources il a tenté d’atteindre.

Pour mettre en place des programmes de sécurité de l’information à grande échelle, il est important d’avoir une visibilité aussi complète que possible. Vous devez savoir quelles technologies vous utilisez, quelles bibliothèques open source sont présentes dans un projet, et connaître l’ensemble de votre infrastructure cloud, y compris les politiques IAM, les buckets, les conteneurs, l’infrastructure as code et autres éléments de ce type.

Pouvoir voir tous vos problèmes, ou presque, est un atout considérable. Vous pouvez repérer les équipes qui appliquent de bonnes pratiques et obtiennent de meilleurs résultats, ainsi que celles qui ne le font pas. Quand vous constatez que certaines équipes n’appliquent pas les bonnes pratiques, c’est l’occasion idéale de les contacter pour les aider. Dès que les ingénieurs adoptent ces pratiques, la grande majorité des vulnérabilités disparaissent. Vous avez en outre l’avantage de pouvoir les former en situation réelle. Bien sûr, la visibilité ne suffit pas à elle seule : il faut aussi pouvoir corriger les problèmes à grande échelle, sans quoi vous passerez votre temps à éteindre des incendies.

Les deux derniers points sont très importants à mes yeux. D’abord, il faut comprendre que l’objectif n’est pas seulement de trouver des problèmes, mais aussi d’agir en conséquence. Ensuite, il faut être prêt à passer à l’échelle. L’utilisation des données à l’échelle de l’organisation permet de déterminer l’état et la couverture de vos équipes produit, puis d’intégrer ces informations à votre évaluation des risques. Étendre les pratiques à plusieurs équipes avant d’y être prêt risque de propager les difficultés plutôt que les bonnes pratiques. J’ai demandé à Phil ce que l’évolutivité signifiait pour lui.

Guimond : Pour moi, l’évolutivité consiste à faire quelque chose une fois et à résoudre ainsi tous les problèmes. Par exemple, si plusieurs équipes projet ont toutes besoin d’une fonctionnalité spécifique, le plus simple pour éviter d’avoir une douzaine de bases de code qui font la même chose, avec chacune leurs propres vulnérabilités et difficultés, est de développer un projet central qui résout le problème, puis de le mettre à la disposition de toutes ces équipes. En bref, vos solutions doivent pouvoir être utilisées par le plus grand nombre d’équipes possible, avec le moins d’actions et de projets possible. Il s’agit aussi d’obtenir de meilleurs résultats en appliquant les bonnes pratiques.

Je suis également convaincu qu’une véritable évolutivité est impossible sans visibilité. Si vous ne pouvez pas voir ce que vous êtes censé protéger, comment le protéger ? Savez-vous seulement que cela existe ? Dans la plupart des cas, non, à moins de disposer d’une connaissance approfondie de l’entreprise acquise au fil des années. Que se passe-t-il si la personne qui détient toutes ces informations quitte l’entreprise ou est victime d’un accident ? Tout disparaît soudainement. Et vous n’en savez toujours pas beaucoup sur les vulnérabilités des projets. Cette approche n’est absolument pas évolutive.

Un manque d’évolutivité peut rapidement submerger votre équipe de sécurité et les ingénieurs avec lesquels vous travaillez. Ni vous ni vos développeurs n’avez le temps de procéder ainsi. L’approche actuelle des tests d’intrusion pose également un gros problème d’évolutivité. Les criminels ne se soucient absolument pas de votre périmètre ni des quelques petites zones que vous avez testées. Je ne critique pas les tests d’intrusion : je les estime indispensables. Mais un pentest classique coûte cher et n’est absolument pas évolutif. Dans un environnement cloud-first comme celui d’aujourd’hui, les tests d’intrusion doivent couvrir l’ensemble de l’infrastructure. Et être continus. 

Comme Phil l’a mentionné, une mise à l’échelle trop rapide, ou l’absence de mise à l’échelle, peut submerger l’équipe de sécurité, surtout si les processus, la documentation, etc. ne sont pas prêts à relever ce défi. Je lui ai donc demandé comment il avait réussi à passer à l’échelle.

Guimond : En donnant la priorité à la visibilité et en regroupant les outils dans un tableau de bord unique. Je sais que cela peut sembler cliché, mais ça marche vraiment. Vous devez faciliter la vie des ingénieurs, et non la compliquer. Les obliger à utiliser 25 outils de sécurité différents pour sécuriser leurs projets est absurde. C’est ainsi que vous obtenez une opposition permanente, un manque d’évolutivité et de visibilité, et des équipes métier beaucoup moins enclines à collaborer avec les équipes de sécurité.

Si vous trouvez un moyen de leur simplifier la vie en leur proposant le moins d’outils possible, capables de résoudre un maximum de problèmes de façon évolutive, vous obtiendrez de meilleurs résultats. De bien meilleurs résultats. Cela améliore la visibilité et permet, à son tour, de gérer les vulnérabilités à très grande échelle. La gestion traditionnelle des vulnérabilités n’est pas évolutive : elle est dépassée à l’ère du cloud computing. Les bonnes pratiques élimineront la plupart des problèmes. Pour ceux qui subsistent, il est important de mettre en place des mesures compensatoires lorsqu’il est impossible de les corriger sans refonte importante de l’architecture.

J’ai demandé à Phil quelles bonnes pratiques il recommanderait pour aider les autres à obtenir les données de visibilité les plus pertinentes pour leur organisation.

Guimond : Regrouper et supprimer des outils. Il vous faut des outils qui révèlent vos mauvaises pratiques ET vous aident à les corriger en un minimum d’étapes et avec le moins de solutions possible. Vous devez également vous débarrasser des outils qui n’apportent aucune réelle valeur à votre équipe de sécurité ou à vos développeurs. Si vous recrutez des personnes uniquement pour gérer un seul outil, ou un ensemble d’outils, vous risquez de créer des silos et une approche de la sécurité difficile à faire évoluer.

Votre équipe doit être aussi transversale que possible. Laissez ses membres explorer de nouveaux domaines et élargir leurs compétences, en plus de leurs responsabilités habituelles. Si les contributeurs individuels passent leurs journées en réunion, rien n’avancera. Collaborez avec des fournisseurs dont les produits disposent d’une API solide, qui donne accès à toutes les informations de leur propre tableau de bord.

Pour regrouper vos outils, vous pouvez collaborer avec des fournisseurs qui protègent une grande partie de votre infrastructure au sein d’une seule offre. Par exemple, les bibliothèques open source, les conteneurs, SAST [static application security testing], l’infrastructure as code, l’inventaire cloud, etc. Vous pouvez ensuite centraliser toutes ces données dans un tableau de bord unique, ou dans le moins de tableaux de bord possible. Vous devez pouvoir explorer les problèmes par catégorie : application, réseau, infrastructure, voire par projet.

Il est essentiel d’obtenir l’adhésion des personnes qui peuvent apporter leur soutien ou faire appliquer les décisions, ainsi que de celles qui peuvent réellement agir et faire avancer les choses. J’ai demandé à Phil qui il conseillerait de rallier avant de chercher à améliorer la visibilité dans les différentes équipes.

Guimond : Si vous mettez en place une équipe de sécurité de l’information qui accompagne les autres, vous devez d’abord établir des relations avec les équipes ou les unités métier que vous soutenez. Contactez-les, planifiez une réunion, envoyez-leur un message sur Slack — faites comme vous préférez — et discutez avec elles pour comprendre leurs difficultés. Une fois que vous les aurez comprises, vous saurez mieux comment les aider. Si une équipe a rencontré des problèmes de sécurité précis par le passé, il est important de trouver une solution pour l’aider à les corriger. Les développeurs vous écouteront si vous le faites.

Il est très important d’écouter les directeurs, les responsables, les développeurs et les ingénieurs de l’équipe, et de comprendre leur point de vue, en particulier lorsqu’il diffère du vôtre. Si vous refusez toute autre perspective et imposez votre façon de faire, personne ne voudra travailler avec vous et les résultats de votre programme de sécurité de l’information en pâtiront. Mais une fois ces relations établies, il est souvent facile d’obtenir l’adhésion dont vous avez besoin. Les gens savent que vous êtes accessible et que vous ne serez pas constamment sur leur dos. Vous pouvez alors les accompagner dans l’adoption des bonnes pratiques et des outils.

Enfin, j’ai demandé à Phil quels conseils généraux il donnerait à une personne souhaitant créer sa propre équipe et son propre programme de sécurité au sein d’une organisation.

Guimond : Recrutez une équipe diversifiée et pluridisciplinaire. Les personnes dont le parcours diffère du vôtre voient les choses autrement. Comprendre d’autres points de vue aide chacun à progresser professionnellement et permet aux équipes de continuer à innover. Par exemple, j’ai échangé avec une équipe qui avait 20 projets différents répondant exactement au même besoin. Chaque équipe utilisait sa propre base de code, avec ses propres vulnérabilités. Elles essayaient donc de corriger ces problèmes un par un. J’ai proposé de montrer précisément comment je corrigerais les vulnérabilités courantes liées à ce projet, mais l’équipe m’a surpris : elle avait non seulement fait cela, mais aussi créé un projet unique pour répondre au même besoin, que chaque équipe pouvait utiliser. Le problème des allers-retours entre toutes ces bases de code était ainsi résolu, et il n’était plus nécessaire de faire des tests d’intrusion sur 20 projets différents. Il ne restait plus qu’à en tester un seul. Ça vous dit quelque chose ? C’est l’exemple que j’ai donné plus tôt !

Il est donc important de garder l’esprit ouvert, d’écouter les approches des autres et de ne pas s’attendre à refaire la même chose dans chaque entreprise. Chaque entreprise et chaque équipe est unique.

Quant à l’importance d’une équipe pluridisciplinaire, que se passe-t-il si vous supprimez plusieurs outils dont la valeur ne justifie plus le coût ? Les équipes qui géraient ces outils devront peut-être se réorienter. Si elles ont déjà été formées à d’autres compétences, elles s’adapteront beaucoup plus vite au changement. Or, la sécurité de l’information évolue constamment. Cela leur permet de continuer à progresser dans leur carrière sans devoir partir ailleurs, et rend votre équipe de sécurité plus adaptable.

Je ne dis pas que tout le monde doit savoir tout faire, mais il est vraiment utile que plusieurs membres de l’équipe puissent assumer différents rôles tout en se spécialisant dans leur mission principale. C’est l’occasion idéale de permettre à votre équipe d’acquérir de nouvelles compétences et de la former. Offrir la possibilité d’apprendre d’autres choses et de progresser professionnellement aide à attirer des profils plus diversifiés.

Vous ne voulez pas que votre équipe se concentre entièrement sur un seul sujet : cela nuirait à son évolution professionnelle et freinerait votre programme de sécurité de l’information. En tant que manager, si vous laissez cela se produire, vous leur faites défaut, ainsi qu’à votre entreprise. Vous avez limité leurs perspectives de carrière en les cantonnant à un domaine, et votre programme de sécurité de l’information est désormais bloqué dans les limites que vous lui avez fixées. À terme, la dette technique entraînera davantage d’angles morts, une évolutivité moindre et beaucoup plus de vulnérabilités.