Le concept de Zero Trust existe depuis 2010, année où John Kindervag, analyste chez Forrester Research, a créé le modèle de sécurité Zero Trust. Pourtant, deux ans après la dévastatrice attaque contre Colonial Pipeline et malgré le ferme soutien du gouvernement américain et d’autres acteurs, nous ne sommes toujours pas plus près de voir l’architecture Zero Trust adoptée à grande échelle.
La seule exception, semble-t-il, concerne les fournisseurs de services cloud, qui affichent un bilan enviable en matière de cybersécurité grâce à des pratiques de sécurité rigoureuses, comme celle de Google consistant àappliquer continuellement des correctifs.
Les failles de sécurité continuant de se produire toutes les heures, les exigences du Zero Trust finiront tôt ou tard par être imposées à toutes les organisations, compte tenu de leur impact et de leur coût pour la société. L’administration Biden pousse déjà en faveur d’unelégislation ambitieuse en matière de cybersécurité, mais il est peu probable qu’elle aille très loin au Congrès actuel. Je suis très surpris que lesecteur de l’assurance cyber n’ait pas déjà exigé une architecture Zero Trust, mais peut-être que lejugement Merck à 1,4 milliard de dollars US rendu la semaine dernière contre le secteur contribuera à faire évoluer la situation.
La question centrale est la suivante : une organisation peut-elle mettre en œuvre une pile Zero Trust complète, acheter du matériel et des logiciels auprès de différents fournisseurs et les assembler, ou faudra-t-il tous migrer vers des fournisseurs de services cloud (CSP) pour bénéficier d’une sécurité Zero Trust ?
Les anciens arguments selon lesquels les marges bénéficiaires du cloud finiraient par faire paraître l’infrastructure informatique sur site plus économique n’avaient pas anticipé une époque où la sécurité deviendrait si difficile que seuls les fournisseurs de services cloud seraient capables de la maîtriser. Cela a d’énormes implications pour l’avenir de l’informatique, que nous allons examiner.
Les 7 principes du Zero Trust
Le NIST et le département américain de la Défense (DoD) ont tous deux publié des recommandations sur les exigences du Zero Trust. Les recommandations du NIST sont disponiblesici.
Le NIST énonce 7 principes du Zero Trust. Nous allons les passer brièvement en revue ici, mais les détails figurent à la page 16 du document.
- Toutes les sources de données et tous les services informatiques sont considérés comme des ressources.
- Toutes les communications sont sécurisées, quelle que soit la localisation sur le réseau. La seule localisation sur le réseau n’implique pas la confiance.
- L’accès aux ressources individuelles de l’entreprise est accordé pour chaque session. La confiance accordée au demandeur est évaluée avant l’octroi de l’accès.
- L’accès aux ressources est déterminé par une politique dynamique — qui tient notamment compte de l’état observable de l’identité du client, de l’application ou du service et de l’actif demandeur — et peut inclure d’autres attributs comportementaux et environnementaux.
- L’entreprise surveille et mesure l’intégrité et le niveau de sécurité de tous les actifs qu’elle possède ou qui lui sont associés. Aucun actif n’est considéré comme fiable par nature.
- Toutes les authentifications et autorisations relatives aux ressources sont dynamiques et strictement appliquées avant d’autoriser l’accès.
- L’entreprise collecte autant d’informations que possible sur l’état actuel des actifs, de l’infrastructure réseau et des communications, et les utilise pour améliorer son niveau de sécurité.
Voici une représentation de la pile du NIST issue du DoD :
Le document du DoD est très bon, car il définit des exigences et des modalités de mise en œuvre précises. Le document est disponibleici. Un bon exemple de flux de travail figure à la page 28 :
Le gouvernement américain a fait un excellent travail de direction dans ce domaine jusqu’à présent, à l’image des années 1980, lorsqu’il a contribué à piloter les normes POSIX pour les interfaces applicatives communes.
Le Zero Trust est « très complexe »
Inutile de le préciser, le Zero Trust est très complexe. Tout doit être suivi et authentifié, à commencer par les utilisateurs, qu’ils disposent de privilèges standard ou élevés. Les réseaux doivent êtresegmentés et authentifiés. Les chaînes d’approvisionnement doivent être validées. Le chiffrement doit être mis en œuvre dans l’environnement, ce qui signifie que la gestion des clés constitue elle aussi un processus très complexe.
Tout cela doit être suivi, et les politiques doivent être mises en œuvre dynamiquement pour les réseaux et les systèmes. Que se passe-t-il si une nouvelle tâche s’exécute, utilise les ressources d’une manière différente et met tout votre système hors service parce que le gestionnaire de politiques considère cette nouvelle tâche comme un intrus ? Cela pourrait très facilement arriver. À cela s’ajoute la complexité liée à la dépendance envers des tiers : que se passerait-il, par exemple, si l’un des progiciels que vous utilisez pour l’authentification multifacteur était piraté (pensez àOkta) et que quelqu’un parvenait à pénétrer dans votre système en contournant la frontière du Zero Trust ?
Tout cela est incroyablement complexe et exige, pour toute grande organisation, une équipe informatique importante ainsi qu’un environnement de test. Les grandes banques et les systèmes de santé peuvent peut-être se le permettre, car ils ne peuvent pas se permettre de ne pas le faire, mais les petites entreprises et celles dont les besoins informatiques sont moins critiques n’en ont souvent pas les moyens financiers.
Parmi les organisations qui avaient besoin du Zero Trust figurent des infrastructures critiques commeColonial Pipeline, divers systèmes scolaires ainsi que des administrations régionales et locales du monde entier qui ont été piratés, avec des conséquences pour nous tous. Même les écoles publiques locales proches de chez moi ont étépiratées. Compte tenu de la complexité des systèmes nécessaires pour traiter les charges de travail de notre monde complexe, comment une petite organisation pourrait-elle s’offrir le personnel informatique et les ressources matérielles nécessaires à la mise en œuvre d’une pile Zero Trust ?
Bien sûr, nombre des piratages commis aujourd’hui consistent simplement à cliquer sur un lien reçu par e-mail et sur lequel il ne fallait pas cliquer. Mais cela relève aussi du Zero Trust, tandis que les pirates perfectionnent leurs méthodes et gagnent chaque jour en sophistication. Si un système scolaire, par exemple, devait construire une pile Zero Trust, il lui faudrait intégrer tous les principes de cette pile pour l’ensemble du matériel et des logiciels, et mettre en œuvre uneauthentification multifacteur dans tout l’environnement. J’ai un cousin qui est administrateur informatique d’un système scolaire ; il n’a ni le budget ni les ressources nécessaires pour envisager une telle démarche et, heureusement, ses systèmes n’ont encore jamais été piratés.
À lire également : Zero Trust : le battage médiatique face à la réalité
Qu’en est-il des fournisseurs de services cloud ?
Les fournisseurs de services cloud (CSP) disposent d’un énorme avantage sur les fournisseurs traditionnels de matériel (serveurs et réseaux) et de logiciels pour plusieurs raisons :
- Ils disposent d’une pile logicielle unique qu’ils contrôlent et qu’ils développent eux-mêmes pour l’essentiel, ce qui permet de l’intégrer à des fins de supervision. Ils n’ont pas besoin de systèmes distincts de supervision du réseau, de supervision de l’authentification multifacteur, de supervision du système d’exploitation, etc. : ils intègrent, coordonnent et corrèlent eux-mêmes tous ces éléments.
- La pile matérielle est contrôlée par les fournisseurs de services cloud. Pour l’essentiel, les CSP construisent leur propre matériel et vont même jusqu’à fabriquer leurs propres processeurs. Ils fabriquent leurs propres équipements réseau, SSD NVMe et cartes mères. Ils contrôlent les micrologiciels, la signature et la chaîne d’approvisionnement. Tout est intégré par les CSP.
- Les points d’entrée sont étroitement surveillés. Lorsque vous vous connectez à un CSP, tout est contrôlé par le fournisseur de services cloud. En cas de faille, il peut la détecter avant vous, car il serait le premier à voir un comportement anormal.
Oui, les fournisseurs de services cloud coûtent probablement plus cher que la possession de votre propre infrastructure informatique. Mais ce coût s’accompagne d’une sécurité bien supérieure à ce que la plupart des organisations peuvent se permettre ou espérer atteindre, de sorte que l’écart de coût n’est peut-être plus aussi important qu’autrefois. Les CSP ont-ils été piratés ? Oui, mais la dernière attaque majeure a été lepiratage chinois de 2009 de Google. Depuis, aucune attaque de grande ampleur contre des CSP n’a été rendue publique, à l’exception d’attaques ayant commencé par l’intrusion sur les sites de clients avant de toucher le CSP, ou par des bases de données laissées ouvertes par un client d’un CSP. Il y a bien sûr des choses que nous ignorons peut-être, mais, à notre connaissance, aucune faille comparable à celle de Colonial Pipeline ne s’est produite dans les environnements des CSP.
À lire également : Construire une architecture résiliente face aux rançongiciels
Ce que tout cela signifie
De mon point de vue — je suis semi-retraité et j’ai beaucoup de temps pour réfléchir, dois-je préciser — tout cela signifie que l’une de deux choses doit se produire.
- Le groupe actuel de fournisseurs de matériel et de logiciels doit s’unir et créer un environnement Zero Trust intégré et sécurisé, que chacun puisse mettre en œuvre, des ordinateurs personnels de nos foyers aux PME et aux grandes entreprises. Des environnements de test doivent être prévus pour les entreprises et les organisations, et des budgets doivent être définis afin de garantir que les mises à niveau et les nouvelles charges de travail puissent être testées. L’une des tâches les plus difficiles consistera à développer une suite de tests pour les charges de travail, capable de reproduire les charges actuelles et futures des clients et de garantir que la génération automatique de politiques n’arrête pas inutilement les systèmes.
- Ou bien tout le monde doit migrer vers les grands fournisseurs cloud, qui disposent de piles Zero Trust, de toutes sortes de générateurs de charges de travail et, vraisemblablement, de systèmes de gestion des politiques ayant déjà traité les charges de travail actuelles et futures de leurs clients.
Il n’existe pas de juste milieu, avec toutes mes excuses au Bouddha. La situation actuelle ne peut pas perdurer ; quelque chose devra céder.
Si le Zero Trust constitue une exigence pour l’avenir — et je pense que c’est le cas —, les fournisseurs traditionnels de solutions commerciales sur étagère (COT) sur site devront tous s’unir pour développer une pile Zero Trust. Cela concerne notamment, sans s’y limiter, les fournisseurs de matériel (réseau, serveurs, stockage, pare-feu, etc.), les fournisseurs de systèmes d’exploitation (Linux et Windows) et les fournisseurs de logiciels (authentification multifacteur, métriques, politiques, etc.). Il s’agit d’une immense tâche d’intégration, à laquelle il faut ajouter la création d’un système d’émulation des charges de travail.
Certaines grandes organisations sur site, notamment dans les services financiers et la santé, disposent des exigences et des ressources nécessaires pour s’en charger elles-mêmes, mais les organisations plus petites ne le peuvent pas, et nombre d’entre elles ont été ou seront attaquées. Pour moi, l’alternative est claire : si le Zero Trust devient une exigence, les CSP ont une avance considérable sur les fournisseurs COT, qui doivent travailler ensemble pour élaborer des normes et un cadre fonctionnant sur toutes les plateformes. Il s’agit d’un investissement important que les fournisseurs CSP semblent avoir déjà réalisé.
La sécurité n’est pas gratuite
La sécurité n’est pas gratuite et l’on en a pour son argent. Je suis quelque peu surpris que les fournisseurs de services cloud ne vantent pas davantage leurs avantages en matière de sécurité, et tout aussi surpris que les fournisseurs COT ne se soient pas regroupés plus rapidement pour travailler sur le Zero Trust. Mais ce qui me surprend le plus, c’est l’absence de pression exercée sur tout le monde pour migrer vers le Zero Trust, prendre une ou deux longueurs d’avance sur les techniques d’attaque actuelles et réduire considérablement la surface d’attaque. J’attends que les compagnies d’assurance imposent le Zero Trust aux organisations qu’elles assurent. Peut-être que la décision Merck a enfin donné aux assureurs cyber l’incitation financière nécessaire pour le faire.