Sécurité Zero Trust : Pourquoi le Zero Trust est important (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 a été le concept de « confiance zéro ».  Dans cet article, nous montrons comment, à la base, la confiance zéro peut être caractérisée par un petit ensemble de croyances simples qui peuvent être appliquées non seulement à l'accès mais aussi plus largement à l'espace de la cybersécurité. 

Cet article présente un cadre visant à englober les grands concepts autour de la confiance zéro, en les reliant au contexte commercial existant qui motive les chefs d’entreprise de la sécurité des applications d’aujourd’hui.  Enfin, cet article fournit une caractérisation du système de croyances Zero Trust – le moteur des outils et des implémentations de sécurité qui répondent aux menaces actuelles et émergentes, qui feront l’objet d’un article de suivi.

Les objectifs de ce document sont doubles : premièrement, transmettre l’état d’esprit de sécurité que les chefs d’entreprise du secteur des applications devraient adopter, et deuxièmement, présenter un cadre pour les praticiens de la sécurité que nous développerons dans les futurs livres blancs. 

Le terme « zero trust » est associé à un certain nombre de concepts différents à différents niveaux d’abstraction : parfois en tant qu’architecture de solution spécifique, parfois en tant que prescription pour appliquer des technologies spécifiques, et à d’autres moments lorsqu’il peut faire référence à une propriété d’un produit.  Nous pensons que la sécurité Zero Trust est, à la base, un état d’esprit – un système de croyances – à partir duquel des techniques et des tactiques émergent et exploitent des technologies spécifiques, qui peuvent ensuite être appliquées pour répondre à un large éventail de menaces de sécurité.

Le système de croyances qui sous-tend la sécurité Zero Trust (ZTS) peut être considéré comme la prochaine étape d’une évolution de l’état d’esprit en matière de sécurité qui a commencé avec la « défense en profondeur » il y a des années.  La défense en profondeur repose sur la conviction que même si tout écran défensif présente une faible mais réelle probabilité de violation, l'ajout de couches de protection accrues pour les actifs clés réduit cette probabilité, ralentissant les attaquants tout en les obligeant à utiliser davantage de ressources pour une attaque réussie.

Zero Trust est une maturation de cet état d’esprit en trois dimensions :

• Premièrement, il fait évoluer le principe de protection d’un ensemble de simples « filtres » limitant l’accès à l’application vers un ensemble de protections plus adaptées aux actifs, appliquées contextuellement à toute transaction système .  L'état d'esprit de chaque transaction est de comprendre :  Qui tente quelle action sur qui .  Le « qui » et le « qui » peuvent être n’importe quel composant du système ou utilisant le système, qu’il soit humain, automatisé ou un morceau de code.  Le concept d’identité est essentiel pour qui et qui , et le concept de privilèges accordés à une identité est utilisé pour codifier ce qui peut être fait.
• Deuxièmement, elle considère l’évaluation des décisions de sécurité non pas comme statique et absolue, mais plutôt comme dynamique et adaptative , devant être continuellement réévaluée à la lumière des comportements observés.  La décision relative à l’issue de chaque transaction (autoriser l’interaction, la bloquer, renforcer la confiance, etc.) doit également prendre en compte le contexte commercial plus large et, plus particulièrement, le rapport risque/récompense.
• Enfin, il est entendu que, quel que soit le nombre de couches de protection fournies, un adversaire suffisamment motivé ou chanceux parviendra à violer ou à contourner les 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 d’application actuelles ouvrent un espace potentiel beaucoup plus large de vulnérabilités applicatives – notamment des menaces provenant de « l’intérieur » de l’infrastructure applicative – qui sont ouvertes à l’exploitation par la sophistication accrue des adversaires d’aujourd’hui.  Heureusement, les progrès simultanés des outils de sécurité, en particulier lorsqu’ils sont utilisés en conjonction avec des capacités modernes de collecte et d’analyse de données, ont permis la mise en œuvre pratique des éléments clés de la stratégie défensive.

Le reste de cette introduction présente un aperçu du cadre de notre approche de la sécurité zéro confiance ainsi que de sa portée.  À partir de là, les sections suivantes développent l’énoncé du problème et sa relation avec d’autres approches contemporaines du zero trust, 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 » – 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’IA en relation avec le modèle de maturité de confiance zéro.

L’approche « Commencer par le pourquoi » de Simon Sinek est un outil efficace pour communiquer le cadre ZTS, comme le montre la figure 1 ci-dessous.  Vous pouvez visualiser ce graphique de l'extérieur vers l'intérieur, en commençant par les classes de menaces traitées par ZTS, puis en explorant les méthodes de sécurité utilisées et enfin en distillant le tout jusqu'aux principes communs.  Ou bien, vous pouvez l’envisager d’un point de vue de l’intérieur vers l’extérieur, en commençant par les croyances fondamentales comme l’étoile polaire, d’où émergent les outils et techniques appropriés, qui vous permettent ensuite de faire face à un large éventail de menaces.

Figure 1 – Sécurité Zero Trust : Système de croyances, outils et avantages.

Les sections suivantes se penchent sur chaque couche concentrique de ce diagramme, mais en bref :

• Les convictions fondamentales de l’approche découlent de la définition du cas d’utilisation comme suit :
  « Qui tente quoi (une action) à qui ? »
  • Pour établir Qui et Qui, vérifiez explicitement toute attestation d’identité.
  • Une fois que vous avez établi qui , utilisez le principe du moindre privilège pour limiter ce qui peut être effectué.
  • Évaluer et réévaluer en permanence les trois facteurs Qui, Quoi et Qui, et continuer à valider par rapport aux contraintes politiques.
  • Partez toujours du principe que des violations et des compromis se produiront . Soyez prêt à intervenir si l'action ( quoi à qui ), sur la base d'une analyse risque/récompense (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 :
  • Authentification et contrôle d'accès pour déterminer Qui à un certain niveau de confiance, puis limiter les privilèges autour de Quoi (actions) qui devraient être autorisés par cette identité par rapport à une cible Qui spécifique.
  • Visibilité et analyse assistée par ML pour observer et évaluer en permanence le contexte complet de chaque transaction : Qui fait quoi à qui.
  • Correction automatisée tenant compte des risques pour intervenir dans une transaction lorsque le niveau de risque-récompense dépasse le seuil de tolérance spécifié.
• Répondez à un large éventail de cyberattaques en appliquant ces méthodes :
  • Les attaques traditionnelles telles que la dégradation ou l’exfiltration de données – Vous pouvez y remédier ces attaques en détectant une compromission d'identité ou une escalade de privilèges, en utilisant les techniques d'authentification et de contrôle d'accès pour limiter qui peut faire quoi par politique.
  • Disponibilité/attaques DDoS – Traitez ces attaques en combinant l’authentification et le contrôle d’accès avec une correction tenant compte des risques.  Par exemple, vous bloquez (ou limitez) 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 ransomwares ou les attaques de la chaîne d'approvisionnement , vous pouvez répondre à ces menaces en détectant les changements et les anomalies dans les comportements de Qui fait Quoi à Qui, encore une fois couplés à une correction tenant compte des risques.

La sécurité Zero Trust s'étend de manière holistique à l'ensemble de l'application, de l'infrastructure et de la pile de livraison, et doit couvrir l'ensemble du pipeline de développement. Plus précisément, cela devrait inclure :

• Pile d'applications et d'infrastructures complète « de haut en bas »
  • Substrat de calcul matériel, comprenant des serveurs, des cartes d'interface réseau, des coprocesseurs et des composants de la carte mère
  • Micrologiciel et BIOS de couche basse pour le matériel.
  • Le système d'exploitation de couche la plus basse, tel que l'hyperviseur ou l'exécutif d'exécution.
  • Le système d'exploitation au niveau de l'application/du 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 de distribution d'application complète « de gauche à droite »
  • La chaîne d'approvisionnement utilisée pour la maintenance continue et les mises à niveau de chaque élément de la pile « de haut en bas ».
  • Tous les composants de livraison d'applications en ligne, tels que les pare-feu, les équilibreurs de charge, les passerelles API, les contrôleurs d'entrée/sortie/maillage et les dispositifs d'atténuation de la fraude en ligne.
  • Tous les composants de distribution d'applications qui affectent indirectement la gestion du trafic, tels que les résolveurs DNS (Domain Name System), ou qui reçoivent indirectement des métadonnées, telles que les solutions de gestion des événements d'informations de sécurité (SIEM) ou les services d'identité fédérés.

Traditionnellement, l'accent du Zero Trust a été mis sur les équipes de développement et de livraison d'applications, souvent représentées par les profils Dev, DevOps, DevSecOps et SRE.  Nous soulignons cela principalement pour souligner la situation dans son ensemble : une approche globale du Zero Trust devrait idéalement inclure des personnalités et des infrastructures non traditionnelles ainsi que des flux de travail supplémentaires, tels que la stratégie d’approvisionnement de la chaîne d’approvisionnement.

L’une des principales priorités des DSI et des RSSI est de moderniser les technologies de l’information pour contribuer à accélérer l’activité.  Ils jouent également un rôle clé dans la gouvernance des risques d’entreprise.  Leur objectif est d’aider l’entreprise à ravir ses clients avec 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. Cela nécessite que les organisations DSI et RSSI libèrent leur personnel pour qu'il puisse utiliser les dernières technologies, architectures et meilleures pratiques en matière d'agilité tout en chargeant simultanément ces mêmes personnes de prendre les mesures de sécurité appropriées et d'établir des contrôles sur le comportement des personnes, les informations auxquelles elles accèdent et la technologie qu'elles utilisent pour éviter toute exposition aux pertes. 

Les organisations doivent comprendre et contrôler les risques liés aux changements des conditions du marché et macroéconomiques, au comportement des consommateurs, à la chaîne d’approvisionnement et aux expositions en matière de sécurité.  Une évaluation précise des risques et la capacité à prendre des mesures d’atténuation rapides constituent un avantage concurrentiel pour les entreprises.  Dans cet article, nous nous concentrons sur le risque d’exposition à la sécurité, qui peut, entre autres, entraîner la perte de propriété intellectuelle, la perturbation des processus commerciaux, la perte d’informations personnelles identifiables et des amendes imposées par les régulateurs.  Le risque de sécurité peut être calculé en évaluant les aspects suivants d’une situation considérée :

1. Valeur des actifs concernés
   Les actifs impliqués dans les transactions ont différents niveaux d’importance. À titre d’exemple, une base de données contenant des informations personnelles identifiables est plus précieuse qu’une base de données répertoriant les points de vente qui vendent des produits fabriqués par l’entreprise.  Il est possible pour les équipes de sécurité et informatiques d’utiliser un processus déterministe pour créer un inventaire de tous les actifs, catégorisés par un score représentant la « valeur » de l’actif.


2. Impact du compromis
   La nature du compromis détermine l’impact qui lui est lié.  Par exemple, l’impact de la furtivité des informations contenues dans la banque de données contenant des informations personnellement identifiables est bien plus élevé que celui d’une perturbation de la disponibilité de la banque de données.  Bien que quelque peu plus nébuleux, il est possible de lister différents types de compromis et de leur attribuer un score « d’impact ».


3. Probabilité de compromis
   La probabilité qu’une transaction conduise à la compromission d’un actif est le facteur le moins déterministe dans l’évaluation du risque associé à la transaction.  Les humains ne sont pas en mesure de gérer 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 la probabilité de compromission.

Le défi 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’un compromis potentiel.

Figure 2 – Les pressions commerciales entraînent de nouvelles pratiques, ce qui entraîne un risque accru.

1. Demandes d'accélération des activités
   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 des partenaires, des fournisseurs, des distributeurs et des services fournis par d’autres entreprises.
   3. Main-d’œuvre mobile
      Les employés doivent pouvoir accéder aux applications professionnelles depuis n’importe où pour une efficacité d’exécution.


2. Pratiques pour répondre aux exigences des entreprises
   1. Méthodologie de développement agile
      Les entreprises sont passées à une approche de développement Agile incrémentale et itérative, mettant fortement l’accent sur la satisfaction du client, au lieu de l’approche séquentielle en cascade, qui met l’accent sur la livraison rapide des projets.
   2. Utilisation de logiciels prêts à l'emploi
      Pour proposer de nouvelles expériences numériques le plus rapidement possible, les développeurs réutilisent du code open source fourni par leurs collègues du secteur.
   3. Développement de contrats
      L’externalisation du travail auprès de développeurs contractuels aide les entreprises à adapter leur effectif à la demande.
   4. Utilisation de l'infrastructure cloud
      L'agilité, la flexibilité et l'évolutivité du cloud ainsi que 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 (SaaS) est avantageux pour les applications d’exploitation commerciale, car cela réduit considérablement la charge liée à l’approvisionnement, au déploiement et à la maintenance de ces applications dans les centres de données privés.
   6. Architecture des microservices
      Les équipes utilisent des microservices pour assurer une livraison continue avec un délai de mise sur le marché plus rapide.
   7. Composants d'application distribués
      Les organisations gagnent en efficacité en exécutant des microservices dans une infrastructure qui offre les meilleurs outils pour développer ou fournir les fonctionnalités du service. Les extensions récentes des workflows hérités sont réalisées à l’aide d’architectures d’application modernes qui doivent communiquer avec les éléments hérités, et les deux s’exécutent souvent sur des infrastructures différentes.
   8. API ouvertes
      Un écosystème de services variés est plus efficace qu’une entreprise développant elle-même tous les services.
   9. Connectivité réseau avec des tiers
      Les entreprises se connectent entre elles à l’aide de tunnels cryptés avec leurs partenaires, fournisseurs et distributeurs pour automatiser et rationaliser les processus commerciaux.


3. Risque de sécurité accru
   1. Surface d'attaque augmentée
      L’utilisation de logiciels tiers et de bibliothèques open source crée des opportunités d’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 de contrats sont motivés à terminer les fonctionnalités à temps et la sécurité n'est pas leur préoccupation.  De plus, une fois le logiciel livré et le projet terminé, il est difficile et chronophage pour les équipes internes de parcourir le code et de trouver des failles de sécurité. Les sprints agiles sont très efficaces pour fournir des fonctionnalités, mais la vitesse 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, qui a la capacité de communiquer avec d’autres microservices, augmente le risque de sécurité pour l’ensemble du système.

      Bien que les entreprises interconnectées améliorent l’efficacité opérationnelle, une conséquence grave est que les failles de sécurité dans l’une d’entre elles les impactent toutes.  Les attaquants trouvent le maillon le plus faible pour proliférer parmi les autres. Une vulnérabilité ou une faille de sécurité dans la plateforme SaaS ou l’infrastructure cloud devient un vecteur d’attaque supplémentaire, et le modèle de responsabilité partagée peut compliquer la détection et la correction précoces.

   2. Complexité architecturale accrue
      Les éléments d’application distribués, développés à l’aide d’architectures différentes et déployés sur plusieurs infrastructures, ont des besoins de sécurité et de conformité différents.  Cela complique la tâche des équipes de sécurité lorsqu’il s’agit 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églementaire.
      
   3. Des hackers bien financés, très motivés et qualifiés
      De l’opération Aurora de 2010 au Solargate de 2020, nous avons connu une décennie de cyberattaques avancées qui ne sont découvertes qu’après avoir causé de graves dommages.  Des violations se sont produites dans des organisations équipées de la meilleure technologie de sécurité, exploité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.  Des propriétés intellectuelles ont été volées, des informations personnelles identifiables ont été volées, des opérations commerciales ont été perturbées, des organisations ont été prises en otage par des ransomwares, alors même que les équipes informatiques et de sécurité ont fait tout leur possible pour se conformer aux réglementations conçues pour tenir les cyberattaques à distance.

Après une série de cyberattaques persistantes contre diverses agences gouvernementales fédérales, étatiques et locales des États-Unis, ainsi que contre plusieurs sociétés américaines, le président Joe Biden a publié un décret visant à améliorer 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 utiliser les principes de confiance zéro pour se préparer aux cyberattaques. L’administration Biden a suivi cet ordre avec un mémorandum du Bureau de la gestion et du budget (OMB) destiné aux chefs des départements et agences exécutives le 26 janvier 2022.  Ce mémorandum de l'OMB « définit une stratégie d'architecture fédérale Zero Trust (ZTA), exigeant que les agences respectent des normes et des objectifs spécifiques en matière de cybersécurité d'ici la fin de l'exercice 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 exécutif et le mémorandum de l'OMB font tous deux référence à l'architecture de confiance zéro décrite dans la publication SP 800-207 du National Institute for Standards and Technology (NIST) , publiée en août 2020, et exigent que les agences gouvernementales la suivent.

Les leaders d’opinion des agences gouvernementales et du secteur privé ont publié des articles qui aident à expliquer l’architecture Zero Trust 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 notons que l’essence critique des idées et suggestions contenues dans ces documents est d’examiner chaque transaction pour évaluer qui tente quelle action sur qui , et de prendre une décision en temps réel d’autoriser ou d’interdire la transaction en fonction du 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 de confiance zéro abstraite (ZTA) dans son article NIST SP 800-207.² En outre, ils discutent des variantes des approches de confiance zéro et décrivent différentes manières de déployer l’architecture abstraite.

Les principales abstractions abordées dans le document sont le point de décision politique (PDP) et le point d'application de la politique (PEP), qui fonctionnent en conjonction l'un avec l'autre.  Le point de décision politique est composé du moteur de politique (PE) et de l'administrateur de politique (PA).  Le moteur de 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 des politiques, qui communique avec le point d'application des politiques pour autoriser ou interdire une nouvelle session et pour modifier ou mettre fin à une session existante. En outre, l’article aborde les variations de l’algorithme de confiance, les composants réseau pour un environnement de confiance zéro et divers cas d’utilisation ou scénarios de déploiement.  Enfin, il s’agit d’examiner les moyens par lesquels l’architecture Zero Trust peut être contrecarrée par les attaquants, de sorte que les implémenteurs soient conscients des menaces et prennent les mesures appropriées pour protéger leurs composants d’architecture Zero Trust.

Dans le but d'aider les agences à développer leurs plans de confiance zéro, les leaders d'opinion de la Cybersecurity and Infrastructure Security Agency (CISA) ont publié un modèle de maturité de confiance zéro .³  Le travail s’appuie sur l’architecture abstraite de confiance zéro décrite dans l’article NIST SP 800-207.  Les auteurs ont identifié cinq domaines et recommandent aux organisations de progresser régulièrement dans le respect des principes de confiance zéro dans chaque domaine.  Les domaines sont (i) l’identité, (ii) l’appareil, (iii) le réseau, (iv) la charge de travail de l’application 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 des cinq domaines.

Le document propose un modèle de maturité de haut niveau sur les cinq piliers fondamentaux du Zero Trust identifiés précédemment, puis approfondit chaque domaine.  Les organisations peuvent utiliser le modèle de maturité pour comprendre leur état actuel et définir une trajectoire itérative vers l’état optimal.

Suite à la découverte des attaques Solar Winds, l'Agence de sécurité nationale (NSA) a publié des directives conseillant aux équipes de cybersécurité d'adopter un modèle de sécurité Zero Trust dans son document « Adopter un modèle de sécurité Zero Trust ».⁴  Des experts de l'équipe d'ingénierie Zero Trust de l'Agence des systèmes d'information de défense (DISA) et de l'Agence de sécurité nationale ont rédigé l'architecture de référence Zero Trust du ministère de la Défense (DOD).⁵  Les auteurs expriment la nécessité d’adopter le principe de confiance zéro avec 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 les risques. »⁶

Cette architecture de référence base ses recommandations sur les abstractions définies dans le document d'architecture zero trust NIST SP 800-207.  Le 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.  Collectivement, ces documents aident les organisations à évaluer leur état actuel et à élaborer un plan.

Adopter une attitude qui « suppose une violation » et 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 de construire un score de risque dynamique pour tous les acteurs et leurs activités. Cela est conforme à la recommandation de Gartner d’utiliser la méthodologie « d’évaluation adaptative continue des risques et de la confiance » (CARTA) pour améliorer les programmes de sécurité existants.  L’adoption du principe consistant à autoriser uniquement l’accès aux ressources avec le moindre privilège 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 est destinée à se concentrer sur l’état d’esprit – le système de croyances, le « Pourquoi » – qui motive la stratégie et les décisions autour des outils et de la conception qu’une entreprise doit adopter pour la sécurité Zero Trust.  En fait, on peut résumer l’impulsion de toutes les méthodes et technologies de composants employées par les solutions Zero Trust d’aujourd’hui en quatre principes clés simples.  Cette section s'ouvre par une énumération de ces principes, suivie d'une discussion sur la manière dont ils peuvent être appliqués dans le contexte plus large du cycle de vie du développement d'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 de l'application.

Si les solutions Zero Trust sont comprises comme renforçant fondamentalement la confiance dans les interactions du système – « Qui fait quoi à qui ? » – alors la construction d’un niveau de confiance approprié à l’interaction peut être décomposée en quatre composantes.

Comme son nom l’indique, l’état d’esprit de confiance zéro consiste à « ne pas faire aveuglément confiance, mais toujours vérifier ».  Par conséquent, tout acteur du système – le Qui et le Qui dans les interactions du système – doit être capable de :

1. Attester de son identité, y compris le cas particulier d’une identité « anonyme », si le système autorise les interactions provenant ou destinées à des identités anonymes – comme les navigateurs anonymes dans un système de réservation de compagnies aériennes.  Pour toutes les autres identités, l'acteur doit pouvoir indiquer qui il est, dans un espace de noms accepté par le système.
2. Recevoir et valider les « preuves » collatérales 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 force de cette preuve, mais le système doit être en mesure de garantir 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 explicitement référencé dans le cadre d'une politique basée sur le rapport risque-récompense.  Notez que le système peut également augmenter ou réduire la confiance par d’autres moyens, comme une réponse à un défi actif ou même à partir d’une observation passive du comportement de l’acteur.
3. Évaluer et ajuster la confiance dans l’identité attestée, en fonction d’une contextualisation supplémentaire du comportement actuel par rapport aux comportements passés.  Par exemple, le système peut conserver des métadonnées historiques sur l’acteur, telles que la géolocalisation précédente et actuelle de l’acteur, ses plates-formes 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, comme 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 appelant l'API, mais également 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 informations d'identification peuvent être volées et les appareils peuvent être compromis ; les contraintes des paramètres de l'API sont souvent incomplètes. Par conséquent, le terme « confiance » dans le contexte de la confiance zéro doit être interprété davantage comme une indication de la probabilité que l’identité attestée ou les paramètres de transaction 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 plus avant une transaction.

Une fois qu’un niveau acceptable de « confiance » est établi dans les acteurs participant à une transaction, l’approche de confiance zéro exige que l’acteur (généralement, le demandeur, le « Qui » ) se voie accorder uniquement les privilèges minimaux requis pour pouvoir 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 étant accordés uniquement si nécessaire au fonctionnement du système.  Par exemple, un système de réservation peut permettre aux utilisateurs anonymes de consulter les horaires de vol mais, conformément aux exigences de conception de l’application, un utilisateur anonyme peut ne pas être autorisé à réserver un vol.

Ces privilèges peuvent s’appliquer à des acteurs individuels ou à des catégories d’acteurs.  En règle générale, 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 inférieur pour réussir 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 au sein d'une application, peuvent souvent avoir des privilèges plus personnalisés, tels que « seuls les conteneurs <X> et <Y> peuvent accéder à la base de données, seul <X> peut écrire dans le magasin d'objets, mais <Y> et <Z> peuvent y lire ».

Une considération importante pour la mise en œuvre du principe du moindre privilège est de s’efforcer de l’appliquer de manière plus personnalisée, avec prévoyance.⁷ Plus précisément, plutôt que d’appliquer un ensemble générique de privilèges à tous les acteurs ou à une classe d’acteurs, une implémentation Zero Trust mature devrait avoir une vue plus granulaire de l’ action tentée.   Par exemple, à un niveau très grossier, « l’accès au système de fichiers » peut se voir accorder un privilège, mais « la lecture du système de fichiers » est une spécification plus stricte du véritable privilège requis, ce qui donne une implémentation de haute qualité du modèle de sécurité positive.

Enfin, des modes de réalisation plus sophistiqués du principe du 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 étant fondés sur 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 tentée. Par exemple, une action particulièrement impactante (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 nécessiterait une vérification supplémentaire pour 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 clés ; cependant, le principe d'évaluation continue reflète le fait que ces principes doivent être évalués en permanence, dans le sens où :

1. Toutes les transactions doivent être soumises à vérification et à privilège.  En d’autres termes, il ne devrait pas être possible qu’un seul sous-ensemble de transactions soit soumis à inspection, comme « la première transaction d’une session utilisateur » ou « les transactions initiées via la charge de travail du conteneur Docker ».  Même si cela peut paraître évident, de nombreuses implémentations Zero Trust ne valident pas toutes les transactions, soit en raison d’une mauvaise conception, soit par manque de visibilité.  Les lacunes courantes dans ce domaine proviennent du fait que le principe de confiance zéro s’applique uniquement aux acteurs externes, mais pas aux acteurs internes, et/ou que l’on suppose qu’un verdict de confiance zéro reste vrai pendant une période prolongée.
2. Les facteurs clés de l’évaluation – la confiance dans l’identité de l’acteur et les droits accordés à cet acteur – doivent être considérés comme dynamiques et sujets à changement .  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 latérales, et toute politique basée sur la confiance doit donc également s’adapter de manière dynamique à l’évolution de la confiance.  De plus, un seuil de privilège accordé par la politique plus tôt peut être révoqué un peu plus tard, ou une confiance minimale requise pour une action peut changer.  Bien que les délais de changement de politique varient (ils peuvent 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 de manière dynamique et d’honorer ces changements.

Le dernier principe repose sur la présomption d’adversaires hautement motivés sur fond de paranoïa saine.  Plus précisément, le principe est le suivant : « supposons que vous ayez été victime d’une violation », où « violation » est définie comme « une transaction qui aurait dû être refusée (en toute connaissance de cause et avec une exécution parfaite) mais qui a été autorisée ».  La cause fondamentale de cette fuite peut être une connaissance imparfaite (par exemple, un score de confiance élevé incorrect provenant de l'authentification résultant d'informations d'identification frauduleuses non détectées), ou peut être des limitations de mise en œuvre (par exemple, ne pas avoir une spécificité suffisamment fine des privilèges accordés, comme avoir une « connexion réseau ouverte » comme privilège, mais sans la capacité de faire la différence en fonction de la géolocalisation de la destination réseau), ou peut être causée par une mise en œuvre incomplète de la confiance zéro (par exemple, ne pas appliquer la confiance zéro aux composants open source vulnérables utilisés en interne).

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

La mise en œuvre de ce principe varie plus 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.  « Suspect » est souvent très contextuel, mais les interprétations courantes sont : (a) des transactions anormales très différentes des comportements observés dans le passé, (b) des groupes de transactions qui sont individuellement normales, mais qui sont collectivement 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 système indésirable et jamais vu auparavant – un exemple serait un modèle dans lequel une transaction spécifique ouvre une connexion réseau à un nœud TOR ou provoque une augmentation significative de la charge du processeur du système.
• Ensuite, effectuez une analyse plus approfondie, soit un flux de travail entièrement automatisé, soit un flux de travail hybride contrôlé par l'homme/assisté par ML, pour déterminer si ces transactions ne sont pas valides.  Si ces transactions sont ensuite jugées invalides, appliquez des mesures d’atténuation.  Cela peut prendre la forme soit d’une mise à jour de la politique générale, soit d’une couche supplémentaire d’atténuation, d’un « filet de sécurité » pour les autres mesures d’atténuation axées sur les politiques.

Si l’approche choisie consiste à utiliser des ajustements basés sur des politiques, les ajustements peuvent être appliqués en exploitant l’un des outils de politique statique disponibles.  Des exemples d'ajustements basés sur des politiques seraient de restreindre les privilèges de contrôle d'accès granulaires des transactions (c'est-à-dire de ne plus autoriser qui à faire quoi à qui ) ou d'appliquer à la place une « norme de preuve » plus stricte (c'est-à-dire d'exiger une MFA ou un score de confiance plus élevé) pour qu'un acteur (ou une classe d'acteurs) entreprenne une action spécifique. 

Si, au contraire, l’approche consistant à utiliser une couche « backstop » supplémentaire est choisie, cette stratégie peut également être mise en œuvre en mode à grain fin ou à grain grossier.  La stratégie la plus précise consisterait à bloquer exactement et uniquement les transactions qui dépassent un ratio risque-récompense spécifique, bien que cette solution ait également la possibilité d'ajouter des niveaux de latence inacceptables à certaines transactions autorisées si la mise en œuvre nécessite une analyse supplémentaire.  Des stratégies plus grossières pourraient être utilisées à la place, telles que le sandboxing des transactions futures de cet acteur ou même l'interdiction totale de l'acteur du système.  Dans les cas extrêmes, des méthodes d’atténuation encore plus grossières, telles que l’arrêt des E/S de fichiers, peuvent être appropriées. 

Bien entendu, toutes choses étant égales par ailleurs, une atténuation plus fine des risques est généralement préférable. Cependant, des compromis doivent souvent être faits en fonction des contraintes des technologies de solution disponibles, et un backstop à gros grains est généralement meilleur que l'absence de backstop.  Par exemple, si la réponse grossière pour empêcher une suspicion de ransomware consiste à désactiver les E/S de fichiers, les effets secondaires de cette réponse peuvent toujours être préférables à l'alternative - permettre à l'acteur de continuer à opérer dans le système sans contrôle - en supposant que le résultat de l'inaction serait un système de fichiers chiffré par un ransomware. 

Le meilleur point de départ pour le développement d’une application sécurisée utilisant le principe Zero Trust est, sans surprise, au début. Les principes fondamentaux qui permettent de mettre en œuvre les principes de confiance zéro doivent être intégrés dès la phase de conception des processus de développement d'applications.  Par conséquent, toute discussion sur une solution opérationnelle Zero Trust intégrée au pipeline CI/CD doit commencer par une compréhension de ces éléments fondamentaux qui devraient être des considérations de conception de premier ordre.

Le cœur de ces éléments fondamentaux doit capturer le comportement souhaité/attendu de l’interaction des comportements du système, associé à une visibilité et un contrôle suffisants pour détecter les écarts et agir en conséquence.  Les interactions prévues sont utilisées pour définir l'ensemble d'actions souhaité ( Quoi ) pour chaque acteur ( Qui ) envers chaque cible ( Qui ).  Cela dit, il peut y avoir des scénarios et des environnements dans lesquels les modèles d’interaction prévus sont inconnus. Dans de tels cas, une organisation peut tirer parti d’une visibilité plus approfondie pour « découvrir » l’ensemble des interactions appropriées,⁸ qu’elle pourra ensuite codifier en politique.

Par exemple, dans les solutions ZTNA actuelles, qui se concentrent sur le contrôle d’accès basé sur l’identité aux API externes d’une application, la visibilité et les contrôles sur les API d’authentification sont nécessaires.  Ou, dans le contexte de la plateforme de protection de la charge de travail cloud (CWPP), la détection d'une charge de travail de conteneur compromise nécessite une visibilité sur les actions effectuées par chaque conteneur, et en temps réel, si une correction en temps réel est requise.

Voici une liste des « buckets » de haut niveau liés aux considérations fondamentales qui devraient faire partie du processus de conception, avec des analyses détaillées supplémentaires pour fournir des questions spécifiques sur lesquelles réfléchir pour chacun des points clés :

• Quelles sont les interfaces boîte noire – entrées et sorties – du système ?
  • Quelles sont les classes d’utilisateurs – administrateurs, utilisateurs authentifiés, utilisateurs non authentifiés, partenaires – qui interagissent avec l’application, et que doivent-ils faire ?
  • Toutes les communications passent-elles par une API définie ou existe-t-il des communications réseau « brutes » ou des communications via un magasin de données, tel qu’une base de données ou un magasin d’objets ?
    • Pour les communications API, dans quelle mesure l'API est-elle bien définie, en termes d'utilisateurs pouvant interagir avec elle et de contraintes entourant 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 cryptées ?
    • S’il existe des interfaces de données « brutes » (par exemple, des 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 pour suivre qui a accédé à quelles informations, quand ?
• De même, au niveau interne de la « boîte blanche », quels sont les services composants qui composent les applications globales, y compris les services fournis en externe, 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.) sur ces interactions ?
    • Des questions similaires à celles ci-dessus existent autour de la formalité de l’API et de ses contraintes et du cryptage des communications.
    • Les communications « internes » (par exemple, entre charges de travail/conteneurs) sont plus susceptibles d’utiliser une mémoire partagée et des interfaces basées sur un système de fichiers ; toutes 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 boîte noire et aux chemins de communication internes ?
  • Existe-t-il une politique indiquant qui – quels rôles – peut invoquer des API spécifiques et que se passe-t-il si la politique est violée ?  De même, quels moyens existent pour détecter et atténuer toute sorte d’abus des API, comme des paramètres non valides ou invoqués à un rythme trop élevé ?  Ces politiques peuvent-elles être mises à jour de manière dynamique, en fonction des 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 base de données) en termes de qui peut accéder à quels fichiers/magasins/tables, et empêchent l’abus de ces ressources (par exemple, « SELECT * from <table> ») ?
• Quelle visibilité (tableaux de bord, logs, statistiques) le système met-il à disposition pour limiter l'accès à la fois aux interfaces black-box et aux chemins de communication internes ?
  • Le système peut-il identifier qui appelle 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 journal de fichiers non structuré, d'une notation d'objet JavaScript structurée (JSON) pouvant être envoyée à un service de gestion des événements et incidents de sécurité (SEIM) ou de données enregistrées dans une table de base de données Big Data ?
  • Quelles sont les réponses aux mêmes questions lorsqu’il s’agit d’autres chemins de communication – mémoire, fichiers, objets, bases de données ?  Qui fait quoi ?  Comment ces données sont-elles exposées ?
• Au-delà des chemins de communication, quels autres contrôles et visibilité le système fournit-il pour éviter la sursouscription ou la surconsommation des ressources ?
  • Le système a-t-il une visibilité sur les mesures de consommation des ressources (CPU, mémoire, bande passante, mise à l'échelle des pods, etc.) ?  Si oui, à quelle granularité et dans quelle mesure ces données sont-elles exploitables ?
  • Le système dispose-t-il de contrôles ou de garde-fous pour la consommation des ressources : limites d'E/S de mémoire/CPU/fichier par charge de travail, suivi des appels système de création de processus, limites de montée en charge/montée en charge des pods, limites de débit pour les API qui invoquent d'autres services ?

Poser explicitement ces questions vous aidera à découvrir où se trouvent les lacunes dans les fondations pour permettre la confiance zéro.  Souvent, le simple fait de poser la question, dès le début de la conception, permettra de combler l’écart avec un minimum d’effort de conception supplémentaire.  Et, lorsqu’un écart persiste, une simple prise de conscience de cet écart permettra d’orienter davantage l’attention sur la sécurité ou d’identifier les surfaces de menace vulnérables.

Réaliser ce type d’analyse de développement sécurisé en amont est un élément crucial de l’état d’esprit de confiance zéro.  Malgré ce fait, une grande partie de l’attention portée au Zero Trust aujourd’hui porte sur ce qui se passe après la conception initiale, et la majorité des entreprises se concentrent sur les aspects post-conception du Zero Trust.  Cependant, réfléchir, dès la phase de conception, aux exigences d’une mise en œuvre efficace du Zero Trust permettra d’éviter des efforts supplémentaires bien plus importants nécessaires pour « combler les lacunes » après le déploiement de l’application.

Comme l’incarne le principe de « supposer une violation », un praticien de la sécurité doit supposer qu’un adversaire suffisamment motivé parviendra à exécuter une transaction malveillante – un exemple de Qui fait Quoi à Qui qui répond aux règles de la politique, mais qui, dans un monde parfait, n’aurait pas dû être autorisé.  Dans de tels cas, l’accent est alors mis sur la mise en place d’un mécanisme de « protection » efficace capable de détecter ces cas, généralement sur la base d’observations des schémas de transactions et des effets secondaires du système, comme décrit dans la section précédente « Hypothèse de violation ».

Cependant, tout comme pour la notion d’identité, savoir si une transaction spécifique est malveillante ou non ne sera jamais parfait.  Par conséquent, tout comme pour l’identité, une solution Zero Trust idéale devrait signaler un score de « confiance » dans la légitimité de la transaction. À titre d'exemple, voir un démon lire et écrire 10 fois le débit de fichiers normal pendant 10 secondes peut entraîner un score de confiance (de malveillance) de 70 %, mais voir le débit augmenter de 100 fois, sur une période d'une minute, peut augmenter le score de confiance à 95 %. Dans cet exemple, prendre la mesure corrective consistant à empêcher les futures écritures de fichiers aura toujours une certaine chance (une possibilité de 30 % ou 5 %) d’être la réponse incorrecte – un « faux positif ».  Par conséquent, la décision de remédier ou non doit prendre en compte le risque de faux positifs par rapport à l’impact potentiel d’un comportement potentiellement malveillant.

L’objectif de cet exemple est de souligner que toute décision de prendre une mesure corrective visible par l’utilisateur Il s’agit en réalité d’une décision commerciale, qui prend en compte tous les risques, les coûts et les récompenses liés à l’activité suspecte.  Introduire des frictions supplémentaires dans la transaction augmente la probabilité que la valeur ne soit pas reçue, mais ne pas intervenir/ajouter de friction introduit le risque de compromis. Par conséquent, la décision d’agir (ou non) dans de tels cas est fonction de trois facteurs :

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 peut entraîner des coûts indirects, soit opérationnels (par exemple, des enregistrements clés cryptés et retenus contre rançon) soit liés à l'image de marque (par exemple, la dégradation d'un site Web). Il peut également y avoir des frais juridiques ou de conformité, par exemple en cas de fuite de données personnelles des clients. Essentiellement, l’attribution des risques est une question de gouvernance, et une bonne gouvernance permettra de comprendre et de quantifier les risques liés à l’application.


2. Quels sont les effets secondaires de la prise de mesures correctives ?
   Les effets secondaires peuvent être exprimés selon les dimensions (a) du frottement introduit et (b) de la zone d'explosion. Le frottement c'est à quel point il est plus difficile pour une transaction légitime de se dérouler ; cela peut aller d'un peu plus gênant (par exemple, un niveau d'authentification supplémentaire) à impossible (la transaction n'est tout simplement pas autorisée). La zone d'explosion indique si d’autres transactions indépendantes seront également affectées et, si oui, combien.  Par exemple, le blocage d’un utilisateur spécifique n’aura d’impact que sur cet utilisateur, mais l’arrêt d’un service de journalisation affectera l’auditabilité de tous les utilisateurs et de toutes les transactions. 


3. Quelle est la confiance dans la conviction que la transaction est malveillante ? 
   Pour renforcer la confiance, il faut généralement collecter davantage de points de données et établir des corrélations entre davantage de sources de données, ce qui prend du temps. Dans la pratique, le compromis est donc souvent le suivant : « Combien de temps dois-je observer avant de décider d’agir ? »

Ainsi, même si une stratégie de confiance zéro doit tenir compte du fait que des violations se produiront, une approche réfléchie adoptera une approche risque/récompense pour la correction des transactions autorisées mais qui semblent suspectes.  Ce compromis comprendra le niveau de risque des différentes transactions d’application et les conséquences de l’application de la correction, et l’application de la correction uniquement si le niveau de risque dépasse la récompense commerciale attendue.

¹ 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 réflexion préalable commence dès la phase de conception, comme décrit plus loin.

⁸ Ou, du moins, l’ensemble des interactions « considérées comme appropriées » que le système semble exiger.  Il existe toujours le risque que l’ensemble des interactions dérivées de l’observation soit incomplet ou comporte un risque préexistant.  Il est donc toujours préférable de bien réfléchir à la conception.