Sécurité à confiance zéro : pourquoi la confiance zéro est-elle essentielle (et pas seulement pour l’accès) ?

L’un des thèmes majeurs de l’accès aux réseaux et aux applications au cours des dernières années portait sur le concept de « confiance zéro »  Dans cet article, nous expliquons comment, au départ, la confiance zéro peut se caractériser par un petit ensemble de croyances simples que l’on peut appliquer non seulement à l’accès mais aussi, de façon plus large, à l’environnement de la cybersécurité

Cet article présente un cadre intégrant l’ensemble des concepts généraux relatifs à la confiance zéro, en les rapportant au contexte opérationnel existant qui motive les leaders professionnels actuels du domaine de la sécurité des applications.  Enfin, cet article décrit les caractéristiques du système de croyance à confiance zéro, c’est-à-dire le moteur des outils et des déploiements de sécurité visant à faire face aux menaces actuelles et émergentes, qui feront objet d’un prochain article.

L’objectif de ce document est double : d’une part, transmettre l’état d’esprit en matière de sécurité que les grands éditeurs d’applications doivent adopter et, d’autre part, présenter un cadre destiné aux professionnels de la sécurité que nous développerons dans de futurs livres blancs

Le terme « confiance zéro » est associé à un certain nombre de concepts différents à divers niveaux d’abstraction : parfois en tant qu’architecture de solution spécifique ; parfois en tant que recommandations de technologies spécifiques ; et à d’autres moments, il peut faire référence à la propriété d’un produit.  Nous estimons que la sécurité à confiance zéro est essentiellement un état d’esprit : un système de croyances, à partir duquel des techniques et des tactiques émergent et tirent parti de technologies spécifiques, qui peuvent ensuite être mises en œuvre pour faire face à un tout un éventail de menaces pour la sécurité.

Le système de croyances sous-jacent de la sécurité à confiance zéro (SCZ) peut être considéré comme l’évolution suivante des mentalités en matière de sécurité, initiée par la « défense en profondeur » plusieurs années auparavant.  La défense en profondeur repose sur la conviction que, si tout bouclier défensif unique présente une probabilité faible, mais réelle, de violation, l’ajout de couches de protection supplémentaires aux ressources stratégiques réduit cette probabilité, en ralentissant les attaquants tout en les obligeant à utiliser davantage de ressources pour mener à bien une attaque.

La confiance zéro est une maturation de cet état d’esprit en trois dimensions :

• Tout d’abord, elle fait évoluer le principe de la protection, qui n’est plus un ensemble de simples « filtres » bloquant l’accès à l’application, mais un ensemble de protections mieux adaptées aux ressources et appliquées selon le contexte à toute transaction système. L’état d’esprit de chaque transaction vise à comprendre :  Qui (exécutant) tente quelle action sur qui (cible). Le « qui (exécutant) » et le « qui (cible) » peuvent être n’importe quel composant du système ou utilisant le système, qu’il s’agisse d’un humain, d’un automate ou d’un morceau de code. Le concept d’identité est essentiel pour connaître le qui (exécutant) et le qui (cible), et la notion de privilèges accordés à une identité sert à codifier ce qui peut être réalisé.
• Ensuite, elle considère que l’évaluation des décisions en matière de sécurité n’est pas statique ni absolue, mais plutôt dynamique et adaptative, et qu’elle doit être continuellement réévaluée à la lumière des comportements observés.  La décision concernant le traitement de chaque transaction (autoriser l’interaction, la bloquer, renforcer la confiance, etc.) doit également tenir compte du contexte opérationnel plus large et, en particulier, du rapport risque/rendement.
• Enfin, il va de soi que, quel que soit le nombre de couches de protection mises en place, un adversaire suffisamment motivé ou chanceux parviendra à déjouer ou à contourner ces protections. Par conséquent, la détection rapide de toute compromission et l’atténuation des tentatives d’exploitation doivent également constituer un élément clé de la stratégie globale.

Cette évolution est, en partie, le résultat du temps et de l’expérience, mais elle est de plus en plus motivée par la confluence de deux autres tendances en matière de sécurité des applications.  Plus précisément, les architectures applicatives d’aujourd’hui ouvrent un espace potentiel beaucoup plus vaste de vulnérabilités applicatives, notamment les menaces provenant de l’« intérieur » de l’infrastructure applicative, qui peuvent être exploitées par les adversaires de plus en plus sophistiqués d’aujourd’hui.  Heureusement, les progrès simultanés des outils de sécurité, surtout lorsqu’ils sont utilisés conjointement avec les capacités modernes de collecte et d’analyse des données, ont permis la mise en œuvre pratique des composantes clés de la stratégie défensive.

Le reste de cette introduction présente une vue d’ensemble du cadre de notre approche de la sécurité à confiance zéro ainsi que de son champ d’application.  Les sections qui suivent développent l’énoncé du problème et sa relation avec d’autres approches contemporaines de la confiance zéro, menant à une discussion sur les croyances fondamentales, le « pourquoi », qui devraient guider le choix des technologies de solution et leur application.  Les prochains articles se pencheront sur le « comment », c’est-à-dire les exigences imposées à des technologies spécifiques telles que l’authentification, le contrôle d’accès et l’analyse assistée par l’intelligence artificielle, dans le cadre du modèle de maturité de la confiance zéro.

L’approche « Start with Why » (Commencer par le pourquoi) de Simon Sinek constitue un outil efficace de communication du cadre SCZ, comme l’illustre la figure 1 ci-dessous.  Vous pouvez observer ce graphique de l’extérieur vers l’intérieur, en commençant par les catégories de menaces ciblées par la SCZ, puis en détaillant les méthodes de sécurité utilisées, pour finir par condenser l’ensemble sous forme de principes communs.  Vous pouvez également l’observer de l’intérieur vers l’extérieur, en commençant par les croyances fondamentales qui constituent l’étoile polaire, d’où émergent les outils et techniques appropriés, qui vous permettent ensuite de faire face à une multitude de menaces.

Figure 1 -- Sécurité à confiance zéro : système de croyances, outils et avantages.

Les sections ultérieures se penchent sur chaque couche concentrique de ce diagramme, mais en résumé :

• Les croyances fondamentales de l’approche découlent du cadrage du cas d’utilisation comme suit :
  « Qui tente de faire quoi (action) à qui ? »
  • Afin d’établir le Qui (exécutant) et le Qui (cible), vérifiez explicitement toute attestation d’identité.
  • Une fois que vous avez déterminé le Qui (exécutant), suivez le principe du moindre privilège afin de limiter Ce qui peut être effectué.
  • Évaluez et réévaluez en permanence les trois facteurs « Qui (exécutant), quoi et qui (cible) », et continuez à les valider par rapport aux contraintes politiques.
  • Partez toujours du principe que des violations et des compromissions se produiront. Soyez prêt à intervenir si l’action (Quoi à Qui (cible)), en vous appuyant sur une analyse risque-rendement (la probabilité de fraude dans l’authentification, pondérée par l’impact commercial d’une approbation de transaction erronée), dépasse un seuil de sécurité acceptable prédéterminé.
• Les méthodes utilisées sont les suivantes :
  • L’authentification et le contrôle d’accès afin de déterminer Qui (exécutant) avec un certain niveau de confiance, puis de limiter les privilèges quant au Quoi (actions) devant être autorisé par cette identité par rapport à un Qui (cible) spécifique.
  • La Visibilité et l’analyse assistée par ML pour observer et évaluer en continu le contexte de chaque transaction dans son intégralité : Qui fait Quoi à Qui.
  • Les mesures correctives automatisées tenant compte du risque afin d’intervenir sur une transaction lorsque le rapport risque/rendement dépasse le seuil de tolérance spécifié.
• Traiter un large éventail de cyberattaques en appliquant les méthodes suivantes :
  • Attaques traditionnelles telles que le défacement ou  ’exfiltration de données : vous pouvez contrer ces attaques en détectant la compromission d’identité ou l’escalade de privilèges, à l’aide de techniques d’authentification et de contrôle d’accès permettant de limiter qui peut faire quoi par le biais de stratégies.
  • Disponibilité/Attaques DDoS : pour faire face à ces attaques, il faut combiner l’authentification et le contrôle d’accès à des mesures correctives tenant compte des risques.  Par exemple, vous bloquez (ou limitez le débit de) l’accès aux acteurs non authentifiés ou mal authentifiés qui tentent des transactions gourmandes en ressources.
  • Menaces avancées, telles que les rançongiciels (ransomeware) ou les attaques de la chaîne d’approvisionnement : vous pouvez contrer ces menaces en détectant les changements et les anomalies dans les comportements de Qui fait Quoi à Qui, toujours en association avec une remédiation adaptée aux risques.

La sécurité à confiance zéro s’étend de manière holistique à l’ensemble des applications, de l’infrastructure et de la pile de livraison, et doit couvrir l’ensemble du pipeline de développement. Plus précisément, elle doit inclure ce qui suit :

• Pile complète « descendante » des applications et des infrastructures
  • Substrat matériel de calcul, comprenant les serveurs, les cartes d’interface réseau, les coprocesseurs et les composants des cartes système
  • Micrologiciel et BIOS de couche inférieure pour le matériel.
  • Le système d’exploitation de la couche la plus basse, comme l’hyperviseur ou l’exécutif d’exécution.
  • Le système d’exploitation au niveau application/conteneur.
  • Composants d’application tiers importés, qu’ils soient commerciaux ou open source.
  • Tout logiciel d’application développé en interne ou sur mesure.
• Pile complète de fourniture d’applications « de gauche à droite »
  • La chaîne d’approvisionnement servant à la maintenance et aux mises à niveau continues de chaque élément de la pile « descendante ».
  • Tous les composants de fourniture d’applications en ligne, tels que les pare-feu, les équilibreurs de charge, les passerelles API, les contrôleurs d’entrée/de sortie/de maillage et les dispositifs d’atténuation des fraudes en ligne.
  • Tout composant de fourniture d’applications qui affecte indirectement le traitement du trafic, comme les résolveurs de DNS (Domain Name System), ou qui reçoit indirectement des métadonnées, comme les solutions de gestion des informations et des événements de sécurité (SIEM) ou les services d’identité fédérés.

Traditionnellement, l’accent sur la confiance zéro a été mis sur les équipes de développement et de fourniture d’applications, souvent représentées par les personas Dev, DevOps, DevSecOps et SRE.  Nous insistons sur ce point, principalement pour souligner l’aspect plus général, à savoir qu’une approche globale de la confiance zéro doit idéalement inclure des personas et des infrastructures non traditionnels, ainsi que des flux de travail supplémentaires, tels que la stratégie d’approvisionnement de la chaîne logistique.

L’une des principales priorités des DSI et des RSSI est de moderniser les technologies de l’information afin de contribuer à l’accélération de l’activité.  Ils jouent également un rôle clé dans la gouvernance des risques de l’entreprise.  Leur objectif est d’aider l’entreprise à satisfaire les clients grâce à de nouvelles expériences numériques, à accroître l’efficacité opérationnelle via la connectivité numérique avec des tiers, et à permettre aux employés d’être productifs de n’importe où, tout en minimisant les risques commerciaux. Pour ce faire, les DSI et les RSSI doivent libérer leur personnel afin qu’il puisse utiliser les dernières technologies, architectures et bonnes pratiques en matière d’agilité, tout en chargeant ces mêmes personnes de prendre les mesures de sécurité appropriées et de mettre en place des contrôles sur le comportement des personnes, les informations auxquelles elles accèdent et la technologie qu’elles utilisent afin de prévenir l’exposition aux pertes.

Les entreprises doivent comprendre et contrôler les risques liés aux changements du marché et des conditions macroéconomiques, au comportement des consommateurs, à la chaîne d’approvisionnement et aux expositions.  Une évaluation précise des risques et la capacité de prendre rapidement des mesures d’atténuation constituent un avantage concurrentiel pour les entreprises.  Dans ce document, nous nous concentrons sur le risque d’exposition aux attaques, qui peut notamment entraîner la perte de propriété intellectuelle, la perturbation des processus métier, la perte d’informations personnelles identifiables et des amendes de la part des autorités de réglementation.  Le risque de sécurité peut être calculé en évaluant les aspects suivants d’une situation étudiée :

1. Valeur des actifs impliqués
   Les actifs impliqués dans les transactions présentent différents niveaux d’importance. Par exemple, une base de données contenant des informations personnelles identifiables a plus de valeur qu’une base de données répertoriant les points de vente des produits fabriqués par l’entreprise.  Il est possible pour les équipes de sécurité et informatiques de faire appel à un processus déterministe pour créer un inventaire de tous les actifs, classés par un score représentant la « valeur » de l’actif.


2. Impact de la compromission
   La nature de la compromission détermine l’impact qui lui est associée.  Par exemple, l’impact de la furtivité des informations du magasin de données contenant des informations personnelles identifiables est beaucoup plus élevé que la perturbation de la disponibilité du magasin de données.  Bien que cela soit un peu plus nébuleux, il est possible d’énumérer différents types de compromissions et de leur attribuer un score d’« impact ».


3. Probabilité de compromission
   La probabilité qu’une transaction conduise à la compromission d’un actif est le facteur le moins déterministe pour évaluer le risque associé à la transaction.  L’être humain n’est pas en mesure de faire face à l’ampleur des observations requises, c’est pourquoi les organisations ont recours à l’apprentissage automatique et à l’intelligence artificielle pour accroître la confiance dans leur calcul de probabilité de compromission.

Le défi à relever consiste à calculer le risque associé à chaque transaction en temps quasi réel et à prendre les mesures d’atténuation appropriées pour contrôler l’impact d’une compromission potentielle

Figure 2 -- Les pressions commerciales engendrent de nouvelles pratiques, qui à leur tour aboutissent à un risque accru.

1. Demande d’accélération de l’activité
   1. Expériences numériques
      Les consommateurs ont un désir insatiable d’expériences numériques et ils exigent des améliorations fréquentes sur de multiples plateformes (PC, tablette, téléphones mobiles).
   2. Entreprise connectée
      Les processus commerciaux numériques nécessitent une connectivité avec les partenaires, les fournisseurs, les distributeurs et les services assurés par d’autres entreprises.
   3. Mobilité du personnel
      Les employés doivent pouvoir accéder aux applications de l’entreprise de n’importe où pour une meilleure efficacité d’exécution.


2. Pratiques permettant de répondre aux demandes des entreprises
   1. Méthodologie de développement agile
      Les entreprises ont adopté l’approche de développement agile, incrémentale et itérative, qui met fortement l’accent sur la satisfaction client, au lieu de l’approche séquentielle en cascade, axée sur la livraison de projets dans les délais.
   2. Utilisation de logiciels prêts à l’emploi
      Pour offrir de nouvelles expériences numériques aussi rapidement que possible, les développeurs réutilisent le code mis en libre accès par leurs collègues du secteur.
   3. Développement contractuel
      L’externalisation du travail à des développeurs contractuels permet aux entreprises d’augmenter leurs effectifs à la demande.
   4. Utilisation de l’infrastructure cloud
      L’agilité, la flexibilité et l’évolutivité du cloud et sa facilité d’utilisation permettent aux développeurs d’obtenir l’infrastructure nécessaire à la demande.
   5. Adoption du SaaS
      Le logiciel en tant que service (Software as a service ou SaaS) est avantageux pour les applications d’opérations commerciales, car il réduit la charge importante que représentent l’acquisition, le déploiement et la maintenance de ces applications dans des centres de données privés.
   6. Architecture en microservices
      Les équipes utilisent les microservices pour réaliser des livraisons continues et accélérer la mise sur le marché.
   7. Composants d’applications distribuées
      Les organisations gagnent en efficacité en exécutant des microservices dans une infrastructure qui offre les meilleurs outils pour développer ou fournir la fonctionnalité du service. Les extensions récentes des flux de travail hérités se font à l’aide d’architectures d’applications modernes qui doivent communiquer avec les éléments existants, et les deux s’exécutent souvent sur des infrastructures différentes.
   8. API ouvertes
      Un écosystème de services divers est plus efficace qu’une entreprise développant tous les services par elle-même.
   9. Connectivité réseau avec des tiers
      Les entreprises se connectent entre elles à l’aide de tunnels chiffrés avec leurs partenaires, fournisseurs et distributeurs dans le but d’automatiser et de rationaliser les processus commerciaux.


3. Risque accru pour la sécurité
   1. Augmentation de la surface d’attaque
      L’utilisation de logiciels tiers et de bibliothèques open-source crée des opportunités pour les attaques de la chaîne d’approvisionnement, et toutes les vulnérabilités des logiciels développés en externe sont héritées. Les développeurs contractuels sont motivés pour terminer les fonctionnalités à temps et la sécurité n’est pas leur préoccupation. En outre, une fois le logiciel livré et qu’ils ont quitté le projet, il est difficile et long pour les équipes internes d’analyser le code et de trouver les failles de sécurité. Les sprints agiles sont très efficaces pour livrer les fonctionnalités, mais la rapidité accrue du développement ne laisse pas beaucoup de temps pour des audits et des tests de sécurité détaillés. Un microservice vulnérable, ayant la capacité de communiquer avec d’autres microservices, présente un risque de sécurité accru pour l’ensemble du système.

      Bien que les entreprises interconnectées améliorent l’efficacité opérationnelle, une conséquence grave est que si l’une d’entre elles présente des failles de sécurité, l’ensemble sera impacté. Les attaquants trouvent le maillon le plus faible pour proliférer à travers le reste. Une vulnérabilité ou une lacune de sécurité dans la plateforme SaaS ou l’infrastructure en cloud devient un vecteur d’attaque supplémentaire, et le modèle de responsabilité partagée peut compliquer la détection précoce et la remédiation.

   2. Augmentation de la complexité architecturale
      Les éléments d’application distribués, développés à l’aide d’architectures variées et déployés sur de multiples infrastructures, ont des besoins différents en matière de sécurité et de conformité.  Il est donc compliqué pour les équipes de sécurité de concevoir et de déployer des mécanismes appropriés pour sécuriser les applications et les données de l’entreprise, et de répondre aux exigences de conformité réglementaires.
      
   3. Des pirates informatiques bien financés, très motivés et compétents
      De l’opération Aurora de 2010 à Solargate de 2020, nous avons connu une décennie de cyberattaques avancées qui ne sont découvertes qu’après avoir causé des dommages très importants.  Les violations se sont produites dans des organisations équipées des meilleures technologies de sécurité, gérées par des équipes de sécurité hautement qualifiées.  Les attaquants ont persisté dans l’infrastructure informatique de ces organisations pendant de longues périodes avant d’être détectés.  La propriété intellectuelle a été dérobée, des informations personnelles identifiables ont été volées, les opérations commerciales ont été perturbées, les organisations ont été prises en otage par des rançongiciels, alors même que les équipes informatiques et de sécurité faisaient plus que le nécessaire pour se conformer aux réglementations prévues pour tenir les cyberattaques en échec.

Après un barrage de cyberattaques persistantes contre diverses agences gouvernementales américaines fédérales, étatiques et locales, ainsi que contre plusieurs entreprises américaines, le président Joe Biden a publié un décret sur l’amélioration de la cybersécurité du pays le 12 mai 2021.  L’un des éléments clés de ce décret est que les agences gouvernementales doivent suivre les principes de confiance zéro pour se préparer aux cyberattaques. L’administration Biden a fait suivre ce décret d’un mémorandum de l’Office of Management and Budget (OMB) destiné aux chefs des départements et agences exécutifs le 26 janvier 2022. Ce mémorandum de l’OMB « définit une stratégie fédérale d’architecture à confiance zéro (Zero Trust architecture ou ZTA), exigeant des agences qu’elles respectent des normes et des objectifs spécifiques en matière de cybersécurité d’ici la fin de l’année fiscale (Fiscal Year — FY) 2024 afin de renforcer les défenses du gouvernement contre des campagnes de menaces de plus en plus sophistiquées et persistantes ».¹ Le décret et le mémorandum de l’OMB font tous deux référence à l’architecture confiance zéro décrite dans la publication SP 800-207 du National Institute for Standards and Technology (NIST), qui a été publiée en août 2020, et exigent que les agences gouvernementales s’y conforment.

Les leaders d’opinion des agences gouvernementales et du secteur privé ont publié des articles qui contribuent à expliquer l’architecture à confiance zéro et offrent des conseils sur la meilleure façon de l’adopter. Nous résumons ci-dessous les idées contenues dans ces documents. Nous observons que l’essence même des idées et des suggestions contenues dans ces documents est d’examiner chaque transaction afin d’évaluer Qui tente Quelle action sur Qui, et de prendre une décision en temps réel pour autoriser ou interdire la transaction d’après le calcul du risque qui lui est associé.

L’équipe du NIST énumère les principes de la confiance zéro et définit une architecture abstraite à confiance zéro (ZTA) dans son document NIST SP 800-207.² De plus, elle aborde les variantes des approches de confiance zéro et décrit différentes manières de déployer l’architecture abstraite.

Les principales abstractions abordées dans le document sont le Point de décision de la politique (PDP) et le Point d’application de la politique (PAP), qui fonctionnent de manière conjointe.  Le point de décision de la politique se compose du Moteur de la politique (MP) et de l’Administrateur de la politique (AP).  Le Moteur de la politique utilise un algorithme de confiance pour décider si l’accès à une ressource doit être accordé à un sujet.  Cette décision est exécutée par l’Administrateur de la politique, qui communique avec le Point d’application de la politique pour autoriser ou interdire une nouvelle session et pour modifier ou mettre fin à une session existante. Par ailleurs, l’article aborde les variations de l’algorithme de confiance, les composants réseau permettant un environnement à confiance zéro, et divers cas d’utilisation ou scénarios de déploiement.  Enfin, il examine les moyens par lesquels l’architecture à confiance zéro peut être contrecarrée par des attaquants, afin que les responsables de la mise en œuvre soient conscients des menaces et prennent les mesures appropriées pour protéger les composants de leur architecture à confiance zéro.

Dans le but d’aider les agences à élaborer leurs projets de confiance zéro, les leaders d’opinion de la Cybersecurity and Infrastructure Security Agency (CISA) ont publié un modèle de maturité de la confiance zéro.³  Ce travail s’appuie sur l’architecture abstraite à confiance zéro décrite dans le document NIST SP 800 -207.  Les auteurs ont identifié cinq domaines et recommandent aux organisations de progresser de façon constante dans le respect des principes de confiance zéro dans chaque domaine.  Les domaines sont (i) l’identité, (ii) le dispositif, (iii) le réseau, (iv) la charge de travail des applications et (v) les données.  Ils recommandent l’utilisation de la visibilité et de l’analyse, ainsi que de l’automatisation et de l’orchestration dans chacun de ces cinq domaines.

Le document propose un modèle de maturité de haut niveau pour les cinq piliers fondamentaux de la confiance zéro identifiés précédemment, puis approfondit chaque domaine.  Les organisations peuvent utiliser ce modèle de maturité pour comprendre leur situation actuelle et établir un parcours itératif vers l’état optimal.

Après la découverte des attaques de Solar Winds, la National Security Agency (NSA) a publié un document intitulé « Embracing a Zero Trust Security Model », dans lequel elle conseille aux équipes de cybersécurité d’adopter un modèle de sécurité à confiance zéro.⁴  Des experts de l’équipe d’ingénierie Confiance zéro de la Defense Information Systems Agency (DISA) et de la National Security Agency ont conçu l’architecture de référence Confiance zéro du Département de la défense (DOD).⁵  Les auteurs expriment la nécessité d’adopter la confiance zéro par la déclaration suivante : « Les vulnérabilités révélées par les violations de données à l’intérieur et à l’extérieur du DOD démontrent la nécessité d’un nouveau modèle de cybersécurité plus robuste qui facilite la prise de décisions éclairées fondées sur le risque »⁶

Cette architecture de référence base ses recommandations sur les abstractions définies dans le document NIST SP 800-207 sur l’architecture à confiance zéro.  Ce document présente un modèle opérationnel de haut niveau et décrit ses éléments en détail.  Il comprend également un modèle de maturité de haut niveau et la cartographie des capacités d’application des principes de confiance zéro à divers domaines d’intérêt.  Ensemble, ces documents permettant aux organisations d’évaluer leur état actuel et d’élaborer un plan.

Le fait d’adopter une attitude qui « suppose une violation » et de suivre les principes de confiance zéro peut aider les organisations dans leurs pratiques de gestion des risques et de gouvernance.  Les principes de confiance zéro de « surveillance continue » et de « vérification explicite » des acteurs impliqués dans les transactions permettent aux organisations d’établir un score de risque dynamique pour tous les acteurs et leurs activités. Cela va dans le sens de la recommandation de Gartner d’employer la méthode CARTA (Continuous adaptive risk and trust assessment – Évaluation continue et adaptative des risques et de la confiance) afin d’améliorer les programmes de sécurité existants.  L’adoption du principe consistant à n’autoriser que l’accès du moindre privilège aux ressources réduit le risque de perte, même à la suite d’une violation.  Les informations générées par la surveillance continue et la vérification explicite sont également utiles pour générer des rapports de conformité.

Cette section vise à mettre l’accent sur l’état d’esprit, le système de croyance, le « Pourquoi » qui motive la stratégie et les décisions relatives aux outils et à la conception qu’une entreprise doit adopter pour une sécurité à confiance zéro.  En effet, on peut regrouper l’impulsion de toutes les méthodes et technologies employées par les solutions de confiance zéro d’aujourd’hui en quatre principes clés simples.  Cette section s’ouvre sur une énumération de ces principes, suivie d’une discussion sur la façon dont ils peuvent être appliqués dans le contexte plus large du cycle de vie du développement des applications, c’est-à-dire, comment prendre en compte ces principes en amont, dans la phase de conception, ainsi que sur le plan opérationnel, dans le déploiement/l’exécution des applications.

Si l’on considère que les solutions de confiance zéro consistent fondamentalement à instaurer la confiance dans les interactions au sein du système : « Qui fait Quoi à Qui ? » : alors la mise en place d’un niveau de confiance approprié à l’interaction peut être décomposée en quatre éléments.

Comme son nom l’indique, l’état d’esprit de la confiance zéro consiste à « ne pas faire confiance aveuglément, toujours vérifier »  Par conséquent, tout acteur du système, le Qui (exécutant) et le Qui (cible) des interactions du système, doit pouvoir :

1. Attester de son identité, y compris dans le cas particulier d’une identité « anonyme » selon laquelle le système permet des interactions provenant ou destinées à des identités anonymes, comme les navigateurs anonymes dans un système de réservation de billets d’avion.  Pour toutes les autres identités, l’acteur doit être capable d’indiquer Qui il est, dans un espace de nom accepté par le système.
2. Recevoir et valider la « preuve » collatérale de l’identité attestée de l’acteur (pour toute identité attestée non anonyme).  La nature de la « preuve » (mots de passe, certificats, comportements, etc.) peut varier, tout comme la qualité de cette preuve, mais le système doit être capable d’établir un certain degré de confiance dans l’attestation.  Les systèmes simples peuvent avoir une vision binaire oui/non de la confiance dans la preuve, tandis que les systèmes plus avancés peuvent avoir un score de confiance numérique qui peut être référencé de manière explicite dans le cadre d’une politique basée sur le risque et le rendement.  Notez que le système peut également augmenter ou réduire la confiance par d’autres moyens, comme la réponse à un défi actif ou même l’observation passive du comportement de l’acteur.
3. Évaluer et ajuster la confiance dans l’identité attestée, sur la base d’une contextualisation supplémentaire du comportement actuel par rapport aux comportements passés.  Par exemple, le système peut conserver un historique de métadonnées concernant l’acteur, telles que sa géolocalisation précédente et actuelle, ses plateformes matérielles, ses adresses IP, sa réputation, etc., à utiliser dans le but d’augmenter ou de diminuer la confiance dans la « preuve » d’identité.

De plus, le principe de vérification explicite peut être appliqué non seulement à l’identité, mais aussi à l’action : le « Quoi » de la transaction.  Un cas d’utilisation courant est celui où l’action est exprimée sous la forme d’un appel d’API, par exemple une API pour effectuer une requête de base de données.  Dans cet exemple, le principe de vérification explicite peut être utilisé non seulement pour avoir confiance dans l’identité de l’acteur qui appelle l’API, mais aussi pour vérifier l’exactitude de l’utilisation de l’action de l’API, par exemple en vérifiant que les paramètres transmis à l’API sont conformes aux contraintes appropriées.

Dans un état d’esprit mature de confiance zéro, la « preuve » n’est presque jamais absolue.  Les identifiants peuvent être volés et les dispositifs peuvent être compromis ; les contraintes des paramètres API sont souvent incomplètes. Par conséquent, le terme « confiance » dans le contexte de la confiance zéro doit être interprété comme une indication de la probabilité que l’identité ou les paramètres de transaction attestés soient légitimes.  Ainsi, le niveau de « confiance » doit être considéré comme un facteur clé, mais pas le seul, dans la décision d’autoriser, de bloquer ou d’inspecter davantage une transaction.

Une fois qu’un niveau acceptable de « confiance » est établi dans les acteurs participant à une transaction, l’approche Confiance zéro exige que l’acteur (généralement, le demandeur, le « Qui » (exécutant)) ne se voie accorder que l’ensemble minimal de privilèges nécessaires pour qu’il puisse faire ce qu’il est censé accomplir dans ce système.  Ce principe incarne ce que l’on appelle également un « modèle de sécurité positive », une approche dans laquelle toutes les actions sont interdites par défaut, des privilèges spécifiques n’étant accordés que si le fonctionnement du système l’exige.  Par exemple, un système de réservation peut permettre à des utilisateurs anonymes de consulter les horaires de vol, mais conformément aux exigences de conception de l’application, un utilisateur anonyme ne peut être autorisé à réserver un vol.

Ces privilèges peuvent s’appliquer à des acteurs individuels ou à des classes d’acteurs.  Généralement, les consommateurs d’applications sont soit des acteurs humains, soit des mandataires d’humains, et sont regroupés en classes, telles que « utilisateurs anonymes », « clients », « partenaires » ou « employés ».  Les classes d’acteurs les moins fiables nécessitent généralement un seuil de confiance plus faible pour passer l’authentification, mais elles ont également accès à moins d’API ou à des API moins sensibles.  Les acteurs internes à l’application ou à son infrastructure, tels que des services ou des conteneurs spécifiques dans une application, peuvent souvent détenir des privilèges plus personnalisés, tels que « seuls les conteneurs et peuvent accéder à la base de données, seuls peuvent écrire dans le magasin d’objets, mais et peuvent lire à partir de celui-ci ».

Une considération importante pour la mise en œuvre du moindre privilège est de s’efforcer de l’appliquer d’une manière plus adaptée, avec prévoyance.⁷ Plus précisément, plutôt que mettre en place un ensemble générique de privilèges à tous les acteurs ou à une catégorie d’acteurs, une mise en œuvre mature de la confiance zéro doit avoir une vision plus granulaire de l’action tentée. Par exemple, à une granularité très grossière, « l’accès au système de fichiers » peut être un privilège accordé, mais « la lecture du système de fichiers » est une spécification plus précise du véritable privilège requis, ce qui permet une mise en œuvre de haute qualité du modèle de sécurité positive.

Enfin, des versions plus sophistiquées du principe de moindre privilège peuvent fonctionner en conjonction avec des implémentations matures de la « vérification explicite », en considérant les privilèges autorisés pour un acteur non pas comme absolus, mais plutôt comme dépendant de la confiance fournie par l’authentification.  Ainsi, les privilèges ne sont accordés que si la confiance dans l’identité attestée(Qui) atteint un seuil minimum, les seuils étant spécifiques à l’action qui est tentée. Par exemple, une action particulièrement lourde de conséquences (par exemple, l’arrêt du système) peut nécessiter une confiance de 90 % ou plus dans le fait que l’acteur est un administrateur.  Dans cet exemple, si la confiance du système dans l’identité n’est que de 80 % lorsque l’arrêt est tenté, le système exige une vérification supplémentaire afin d’augmenter le score de confiance dans l’identité attestée avant d’autoriser l’action.

La vérification explicite et le moindre privilège sont des concepts essentiels ; cependant, le principe d’évaluation continue rend compte du fait que ces principes doivent être évalués en permanence, en ce sens que :

1. Toutes les transactions doivent faire l’objet d’une vérification et d’un privilège.  En d’autres termes, il ne devrait pas arriver que seul un sous-ensemble de transactions soit soumis à une inspection, comme « la première transaction d’une session utilisateur » ou « les transactions qui sont initiées par la charge de travail du conteneur Docker ».  Bien que cela puisse sembler évident, de nombreuses implémentations de la confiance zéro ne valident pas toutes les transactions, soit en raison d’une mauvaise conception, soit par manque de visibilité.  Les lacunes les plus courantes dans ce domaine sont dues au fait que la confiance zéro ne s’applique qu’aux acteurs externes, mais pas aux internes, et/ou au fait qu’un verdict de confiance zéro reste vrai pendant une longue période.
2. Les facteurs clés de l’évaluation, la confiance dans l’identité de l’acteur et les droits qui lui sont accordés, doivent être considérés comme dynamiques et susceptibles de changer.  Par exemple, la confiance dans une identité peut augmenter ou diminuer au fil du temps, en fonction des comportements observés et des métadonnées de bande latérale, et toute politique basée sur la confiance doit donc également s’adapter dynamiquement à l’évolution de la confiance.  En Par ailleurs, un seuil de privilège accordé par une politique antérieure peut être révoqué un peu plus tard, ou encore la confiance minimale requise pour une certaine action peut changer.  Bien que les délais de modification de la politique varient, elle peut changer lentement (à l’échelle des processus opérationnels humains) ou rapidement (via des agents de gouvernance automatisés), le système doit être capable de répondre dynamiquement et de respecter ces changements.

Le dernier principe est ancré dans la présomption d’adversaires très motivés sur fond de paranoïa raisonnable.  Plus précisément, le principe est le suivant : « supposer avoir été victime d’une violation », le terme « violation » étant défini comme « une transaction qui aurait dû être refusée (avec une connaissance et une exécution parfaites) mais qui a été autorisée ». La cause profonde de cette fuite peut être une connaissance imparfaite (par exemple, un score de confiance élevé incorrect de l’authentification provenant d’identifications frauduleuses non détectées), ou peut être des limitations de mise en œuvre (par exemple, l’absence d’une spécification de granularité suffisamment fine des privilèges accordés, comme le fait de disposer d’une « connexion réseau ouverte » en tant que privilège, mais sans la possibilité de faire une distinction en fonction de la géolocalisation de la destination réseau), ou encore une mise en œuvre incomplète de la confiance zéro (par exemple, le fait de ne pas appliquer la confiance zéro aux composants open source vulnérables utilisés en interne).

Par conséquent, l’état d’esprit Confiance zéro doit également porter sur la meilleure façon de gérer/minimiser l’impact de telles violations.

La mise en œuvre de ce principe varie davantage que les autres principes, mais se manifeste généralement comme suit :

• Tout d’abord, identifiez toutes les transactions qui, bien que techniquement autorisées par la politique, sont suspectes.  le terme « suspect » dépend très souvent du contexte, mais les interprétations courantes sont les suivantes : (a) des transactions anormales très différentes des comportements observés par le passé, (b) des groupes de transactions qui apparaissent comme normales individuellement, mais qui collectivement sont inhabituelles ; par exemple, la lecture et l’écriture d’un fichier peuvent être courantes, mais la lecture et l’écriture à un rythme de 1 000 fichiers par seconde peuvent être inhabituelles, ou (c) des actions qui sont corrélées à un impact indésirable et non observé précédemment sur le système ; un exemple serait un modèle où une transaction spécifique ouvre une connexion réseau à un nœud TOR ou provoque une augmentation significative de la charge CPU du système.
• Ensuite, effectuez une analyse plus approfondie, soit de manière entièrement automatisée, soit au moyen d’un flux de travail hybride contrôlé par l’homme et assisté par le langage ML, afin de déterminer si ces transactions ne sont pas valides.  S’il s’avère que ces transactions ne sont pas valides, appliquez des mesures d’atténuation.  Cela peut prendre la forme d’une mise à jour de la politique générale ou, en tant que couche supplémentaire d’atténuation, d’un « filet de sécurité » pour les autres mesures d’atténuation fondées sur des politiques.

Si l’approche choisie consiste à utiliser des ajustements basés sur des politiques, les ajustements peuvent être appliqués en tirant parti de n’importe lequel des outils de politique statique disponibles.  Parmi les exemples d’ajustements basés sur des politiques, on peut citer la restriction des privilèges de contrôle d’accès granulaire aux transactions (c’est-à-dire ne plus permettre à Qui de faire Quoi à Qui) ou l’application d’une « norme de preuve » plus stricte (c’est-à-dire exiger une AMF ou un score de confiance plus élevé) pour qu’un acteur (ou une catégorie d’acteurs) puisse effectuer une action spécifique. 

Si l’on opte plutôt pour l’approche consistant à utiliser une couche de « filet de sécurité » supplémentaire, cette stratégie peut également être mise en œuvre selon une granularité « fine » ou « grossière ».  La stratégie la plus fine consisterait à bloquer exactement et uniquement les transactions qui dépassent un rapport risque-rendement spécifique, bien que cette solution puisse également ajouter des niveaux inacceptables de latence à certaines transactions autorisées si la mise en œuvre nécessite une analyse approfondie.  Des stratégies plus grossières pourraient être utilisées à la place, comme le sandboxing des futures transactions de cet acteur ou même l’interdiction totale de l’acteur au sein du le système.  Dans des cas extrêmes, des méthodes d’atténuation encore plus grossières, comme l’arrêt des E/S de fichiers, peuvent s’avérer mieux adaptées.

Bien sûr, toutes choses étant égales par ailleurs, une atténuation par filet de sécurité à granularité fine est préférable de manière générale. Cependant, il est souvent nécessaire de faire des compromis en fonction des contraintes des technologiques des solutions disponibles, et un filet de sécurité à granularité grossière est généralement préférable à son absence.  Par exemple, si la réponse grossière de prévention des rançongiciels présumés consiste à désactiver les entrées/sorties de fichiers, les effets secondaires de cette réponse peuvent encore être préférables à l’alternative, c’est-à-dire permettre à l’acteur de continuer à opérer dans le système sans contrôle, en supposant que le résultat de l’inaction entraînerait le chiffrement d’un système de fichiers par un rançongiciel.

Le meilleur point de départ pour le développement d’une application sécurisée s’appuyant sur la confiance zéro est, sans surprise, le début. Les principes fondamentaux qui permettent de rendre opérationnels les principes de confiance zéro doivent être intégrés dans la phase de conception des processus de développement d’applications.  Par conséquent, toute discussion sur une solution opérationnelle à confiance zéro intégrée dans le pipeline CI/CD doit commencer par une compréhension de ces éléments fondamentaux qui doivent faire partie des points prioritaires de la conception.

Le noyau de ces éléments fondamentaux doit capturer le comportement désiré/prévu de l’interaction des comportements du système, associé à une visibilité et un contrôle suffisants permettant de détecter les déviations et d’intervenir en conséquence.  Les interactions prévues servent à définir l’ensemble des actions souhaitées(Quoi) pour chaque acteur(Qui) vers chaque cible(Qui).  Cela dit, dans certains scénarios et environnements, les modèles d’interaction prévus sont inconnus. Dans ce cas, une organisation peut tirer parti d’une meilleure visibilité permettant de « découvrir » l’ensemble des interactions appropriées,⁸ qu’elle peut ensuite codifier dans une politique.

Par exemple, dans les solutions ZTNA actuelles, qui se concentrent sur le contrôle d’accès aux API externes d’une application en fonction de l’identité, la visibilité et les contrôles des API d’authentification sont indispensables.  Ou encore, dans le contexte d’une plateforme de protection des charges de travail cloud (Cloud Workload Protection Platform — CWPP), la détection d’une charge de travail en conteneur compromise nécessite une visibilité sur les actions effectuées par chaque conteneur, et en temps réel, dans le cas où il faudrait y remédier immédiatement.

Vous trouverez ci-dessous une liste des « catégories » de haut niveau associées aux considérations fondamentales que l’on doit intégrer au processus de conception, ainsi que des informations plus détaillées contenant des questions précises à vous poser concernant chacun des points clés :

• Quelles sont les interfaces de la boîte noire (entrées et sorties) du système ?
  • Quelles catégories d’utilisateurs (administrateurs, utilisateurs authentifiés, utilisateurs non authentifiés, partenaires) interagissent avec l’application, et que doivent-elles faire ?
  • Toutes les communications se font-elles par l’intermédiaire d’une API définie, ou existe-t-il des communications réseau « brutes » ou des communications par l’intermédiaire d’une banque de données, tel qu’une base de données ou un magasin d’objets ?
    • Pour les communications par API, dans quelle mesure l’API est-elle bien définie, en termes d’utilisateurs pouvant interagir avec elle, et de contraintes associées à ces interactions (par exemple, contraintes de paramètres, limites de débit, etc.)
    • Pour toute communication réseau, toutes les données transmises sont-elles chiffrées ?
    • S’il existe des interfaces de données « brutes » (par exemple, les informations sont partagées entre le client et l’application via un magasin d’objets ou une base de données), existe-t-il des journaux d’audit permettant de savoir qui a accédé à quelles informations et à quel moment ?
• De même, au niveau de la « boîte blanche » interne, quels sont les services qui constituent l’ensemble des applications, notamment les services fournis par des tiers, et comment communiquent-ils ?
  • Comment ces services communiquent-ils ? Quelle est l’API utilisée et quelles sont les contraintes (rôles, contrôles d’accès, limites de débit, paramètres, etc.) appliquées à ces interactions ?
    • Des questions similaires, comme celles mentionnées ci-dessus, existent autour de la formalité de l’API et de ses contraintes, ainsi que du chiffrement des communications.
    • Les communications dites « internes » (par exemple, entre charges de travail/conteneurs) sont plus susceptibles d’utiliser la mémoire partagée et les interfaces basées sur le système de fichiers ; ces interfaces doivent être identifiées.
• Quels mécanismes de contrôle le système met-il à disposition pour limiter l’accès aux interfaces de la boîte noire et aux voies de communication internes ?
  • Existe-t-il une politique indiquant qui (quels rôles) peut invoquer des API spécifiques et ce qui se passe en cas de violation de celle-ci ?  De même, quels moyens permettent de détecter et d’atténuer toute forme d’abus des API, comme des paramètres non valides ou un taux d’invocation trop élevé ?  Ces politiques peuvent-elles être mises à jour dynamiquement, en fonction d’entrées contextuelles provenant d’autres systèmes ?
  • De même, existe-t-il des politiques qui limitent les autres formes de communications entre charges de travail (systèmes de fichiers, magasins d’objets, tables de bases de données) en termes de qui peut accéder à quels fichiers/magasins/tables, et qui empêchent l’abus de ces ressources (par exemple, « SELECT * from  ») ?
    Quelle visibilité (tableaux de bord, journaux, statistiques) le système met-il à disposition, pour limiter l’accès aux interfaces de la boîte noire et aux voies de communication internes ?

    • Le système peut-il identifier qui invoque quelle API à quel moment ?  Ces données sont-elles conservées et, si oui, pendant combien de temps ?  À quelle vitesse (en temps réel, toutes les heures, etc.) ces données sont-elles mises à disposition ?  Dans quelle mesure les données sont-elles consommables ? S’agit-il d’un fichier journal non structuré, d’un fichier JSON structuré (JavaScript Object Notation) qui peut être envoyé à un service de gestion des événements et des incidents de sécurité (SEIM), ou de données enregistrées dans une table de base de données de type « Big Data » ?
    • Quelles sont les réponses aux mêmes questions lorsqu’il s’agit d’autres voies de communication comme la mémoire, les fichiers, les objets ou bases de données ?  Qui fait quoi ?  Quel est le degré du risque d’exposition de ces données ?
    Au-delà des voies de communication, quels autres contrôles et quelle visibilité le système fournit-il pour empêcher la trop forte sollicitation ou la surconsommation des ressources ?

    • Le système dispose-t-il d’une visibilité sur les mesures de consommation des ressources (CPU, mémoire, bande passante, adaptation des pods, etc.) ?  Si oui, à quelle granularité, et dans quelle mesure ces données peuvent-elles être consommées ?
    • Le système dispose-t-il de contrôles ou de garde-fous quant à la consommation des ressources (limites de la mémoire/du processeur/des entrées/sorties de fichiers par charge de travail, suivi des appels système de création de processus, limites sur la montée en puissance et la sortie des pods, limites de taux pour les API qui invoquent d’autres services) ?

    En posant explicitement ces questions, vous découvrirez où se trouvent les lacunes dans les fondements de la confiance zéro.  Souvent, le simple fait de poser la question dès le début permettra de combler les lacunes de la conception avec un effort supplémentaire minimal.  Et, lorsqu’une lacune persiste, le simple fait d’en être conscient permet d’orienter les efforts de sécurité supplémentaires ou d’identifier les surfaces de menaces vulnérables.

    La réalisation de ce type d’analyse de développement sécurisé en amont est un élément essentiel de l’état d’esprit Confiance zéro.  Malgré cet aspect, une grande partie de la confiance zéro se concentre aujourd’hui sur ce qui se passe après la conception initiale, et la majorité des entreprises mettent l’accent sur les aspects post-conception de la confiance zéro.  Pourtant, en réfléchissant, dès la phase de conception, aux exigences d’une mise en œuvre efficace de la confiance zéro, on évite les efforts incrémentiels beaucoup plus importants nécessaires pour « boucher les trous » après le déploiement des applications.

Comme l’indique le principe « Supposition de violation » de l’état d’esprit, un professionnel de la sécurité doit supposer qu’un adversaire suffisamment motivé parviendra à exécuter une transaction malveillante : une instance de « Qui fait quoi à qui » qui respecte les règles de la politique, mais qui, dans un monde idéal, n’aurait pas dû être autorisée.  Dans de tels cas, l’accent est alors mis sur la mise en place d’un mécanisme de « filet de sécurité » efficace capable de les détecter, généralement en se basant sur des observations de modèles de transactions et d’effets secondaires du système, comme décrit dans la section précédente « Supposition de violation ».

Néanmoins, à l’instar de la notion d’identité, la connaissance du caractère malveillant ou non d’une transaction précise ne sera jamais parfaite.  Par conséquent, tout comme pour l’identité, une solution idéale de confiance zéro doit rapporter un score de « confiance » dans la légitimité de la transaction. Par exemple, le fait de voir un « daemon » (programme fantôme) lire et écrire 10 fois le taux normal de fichiers pendant 10 secondes peut donner un score de confiance (de malveillance) de 70 %, mais le fait de voir le taux augmenter 100 fois, de manière soutenue pendant 1 minute, peut augmenter la confiance à 95 %. Dans cet exemple, l’action corrective consistant à inhiber les futures écritures de fichiers aura toujours une certaine chance (30 % ou 5 %) d’être une réponse erronée, un « faux positif ».  De ce fait, la décision de remédier ou non à la situation doit prendre en compte le risque de faux positifs par rapport à l’impact potentiel de l’autorisation d’un comportement éventuellement malveillant.

Le but de cet exemple est de souligner que toute décision de prendre une mesure corrective visible par l’utilisateur est en réalité une décision commerciale, qui prend en compte tous les risques, coûts et bénéfices liés à l’activité suspecte.  L’introduction de frictions supplémentaires dans la transaction augmente la probabilité de non-réception de la valeur, mais le fait de ne pas intervenir/d’additionner des frictions introduit le risque de compromission. Par conséquent, la décision d’agir (ou non) dans de tels cas est fonction de trois éléments :

1. Quel est le risque de laisser se poursuivre des transactions potentiellement malveillantes ?
   Ce risque peut être directement monétaire, comme le transfert de fonds bancaires, ou avoir des coûts indirects, qu’ils soient opérationnels (par exemple, des enregistrements clés chiffrés et rançonnés) ou d’image (par exemple, la dégradation d’un site web). Cela peut également entraîner des coûts juridiques ou de conformité, par exemple en cas de fuite de données personnelles de clients. En substance, l’attribution des risques est une question de gouvernance, et une bonne gouvernance permettra de comprendre et de quantifier les risques pour l’application.


2. Quels sont les effets secondaires de la mesure corrective ?
   Les effets secondaires peuvent être exprimés selon les dimensions (a) de la friction introduite et (b) la zone affectée. La friction est le degré de difficulté associé au déroulement d’une transaction légitime ; cela peut aller d’une légère augmentation des inconvénients (par exemple, un niveau supplémentaire d’authentification) à l’impossibilité (la transaction n’est tout simplement pas autorisée). La zone affectée fait référence à la question de savoir si d’autres transactions indépendantes seront également touchées et, le cas échéant, leur nombre.  Par exemple, le blocage d’un utilisateur spécifique n’aura un impact que sur cet utilisateur, mais l’arrêt d’un service de journalisation affectera l’auditabilité pour tous les utilisateurs et toutes les transactions.


3. Quel est le degré de confiance dans la conviction que la transaction est malveillante ? 
   Le renforcement de la confiance implique généralement la collecte d’un plus grand nombre de points de données et la corrélation entre un plus grand nombre de sources de données, ce qui prend du temps ; ce compromis se résume souvent, dans la pratique, à la question suivante : « Combien de temps dois-je observer avant de décider d’intervenir ? »

Ainsi, alors qu’une stratégie de confiance zéro doit accepter le fait que des violations se produiront, une approche réfléchie adoptera une approche risque-rendement quant à la correction des transactions autorisées mais qui semblent suspectes.  Ce compromis comprendra le niveau de risque de différentes transactions d’applications et les conséquences de la mise en œuvre de mesures correctives, que si le niveau de risque dépasse le rendement commercial prévu.

¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

² https://csrc.nist.gov/publications/detail/sp/800-207/final

³ https://www.cisa.gov/zero-trust-maturity-model

⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

⁵ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁶ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁷ La prévoyance commence dès la phase de conception, comme nous le verrons plus loin.

⁸ Ou, du moins, l’ensemble des interactions « considérées comme appropriées » que le système semble exiger.  Il y a toujours le risque que l’ensemble d’interactions dérivé de l’observation soit incomplet, ou qu’il présente un risque préexistant.  Il est donc toujours préférable de faire preuve de prévoyance lors de la conception.