Réflexion sur les techniques et technologies pour l'adoption du Zero Trust

Au-delà du « pourquoi » : les principes directeurs¹ —du principe de confiance zéro, la prochaine préoccupation est « comment » — les techniques et les technologies utilisées pour mettre en œuvre ces principes.

D’un point de vue plus large, les principes de confiance zéro peuvent être appliqués à l’ensemble du cycle de vie de développement d’applications, y compris la conception du système, les plates-formes matérielles utilisées et les procédures d’approvisionnement.² Cependant, cet article aborde les aspects opérationnels de la mise en œuvre de la confiance zéro pour la défense des applications et des données en cours d’exécution. 

D'une manière générale, la sécurité Zero Trust utilise des technologies pour atteindre l'un des trois objectifs distincts suivants :

1. Appliquer les contraintes transactionnelles : Qui peut faire quoi à qui .
2. Fournir une connaissance de la situation à l’opérateur du système humain.
3. Effectuez des mesures de réduction/correction des risques plus avancées, en vous basant sur les indicateurs de suspicion assistés par l’apprentissage automatique (ML) et sur le profil risque-récompense de la ou des transactions en question.

Le graphique suivant illustre ce modèle transactionnel global de sécurité Zero Trust, les sections suivantes approfondissant chaque classe de technologies.

Les deux premières technologies, l’authentification et le contrôle d’accès, sont étroitement liées et directement motivées par les principes de « vérification explicite » et de « moindre privilège », puisque ces technologies sont au cœur de l’application de la règle « Qui peut faire quoi ». Des implémentations d’authentification plus sophistiquées surveillent le comportement continu d’un acteur, capturant l’état d’esprit d’« évaluation continue ». 

Les technologies d’authentification visent à renforcer la confiance dans une identité attestée : Qui agit dans une transaction. Le processus d’authentification comporte trois éléments : 

1. Il y a une attestation, ou une déclaration, faite par l’acteur, précisant son identité.
2. Certaines données, généralement fournies par l’acteur, permettent de prouver la véracité de l’attestation.
3. Le système produit un verdict ou une décision sur la probabilité que l’attestation soit correcte : l’acteur est bien celui qu’il prétend être. Le graphique ci-dessous décrit les différents aspects de l’authentification, les modèles de maturité pour chacun, et est suivi d’une discussion plus approfondie de chaque aspect. 

La forme la plus élémentaire d’attestation est souvent appelée « utilisateur » : un être humain, ou un agent agissant au nom d’un être humain, qui souhaite effectuer une transaction. Cependant, dans le cas d'une confiance zéro utilisée dans une application, un acteur peut être une charge de travail (comme un processus, un service ou un conteneur), de sorte que le concept généralisé d'identité doit inclure ces acteurs. Dans d’autres cas, la notion de Qui inclut non seulement l’humain ou la charge de travail, mais également des considérations ou des dimensions supplémentaires de l’identité. De ce point de vue, des dimensions supplémentaires de l’identité pourraient inclure l’appareil ou la plateforme de l’utilisateur/de la charge de travail, ou l’écosystème utilisé pour l’interaction ou la localisation de l’agent. Par exemple, un utilisateur « Alice » peut être sur un PC étiqueté « ABC- 0001 » utilisant une instance de navigateur spécifique, avec empreinte digitale, provenant de l'adresse IPv4 10.11.12.13. 

Certains systèmes permettent aux utilisateurs non authentifiés, parfois appelés « invités » ou utilisateurs « anonymes », d’effectuer un ensemble limité de transactions. Pour de tels systèmes, les étapes supplémentaires consistant à prouver l’identité et à rendre un verdict par le système ne sont pas pertinentes. Cependant, pour toute identité attestée spécifique, les méthodes suivantes sont couramment utilisées pour prendre en charge cette attestation :

• Connaissance d’un secret partagé, tel qu’un mot de passe.
• Une sorte d’attestation provenant d’un tiers de confiance, comme un certificat signé.
• Interrogation, automatisée (comme l'empreinte digitale de l'appareil) ou active (comme le défi captcha), de l'utilisateur, de la charge de travail ou de la plateforme.
• Métadonnées liées à l'acteur, telles que la géolocalisation, la réputation IP ou l'heure d'accès.
• Analyse comportementale, telle que l'analyse biométrique passive ou les modèles de flux de travail d'interaction avec les applications. 

Souvent, si un degré de confiance élevé est requis, plusieurs méthodes sont utilisées. Ceci est démontré par le modèle Google BeyondCorp,³ qui nécessite une authentification multifacteur (MFA) avant d'autoriser des transactions de valeur supérieure. Les solutions d’authentification les plus sophistiquées associent une « confiance » à chaque identité et spécifient un niveau de confiance minimum pour chaque type de transaction, en fonction de la valeur et du risque de la transaction.

Enfin, notez que certaines de ces méthodes ne sont pas des actions statiques et ponctuelles, mais peuvent et doivent être continues conformément au principe d’« évaluation continue ». Dans de tels cas, le score de confiance attribué à l’attestation d’identité peut évoluer à la hausse ou à la baisse au fil du temps. Par exemple, l’empreinte digitale du navigateur ou l’adresse IP peuvent changer au cours d’une même session utilisateur, ce qui peut être considéré comme suspect et réduire la confiance ; ou à mesure que davantage de données sont collectées sur le comportement de l’acteur au cours d’une session, le score de confiance peut augmenter ou diminuer en fonction de la façon dont le comportement actuel se compare aux observations passées.

L’authentification dynamique peut fonctionner de concert avec le contrôle d’accès dans les systèmes plus avancés. En tant que premier niveau de cette interaction, la politique de contrôle d’accès peut spécifier un score de confiance minimum pour différentes classes de transactions, comme mentionné précédemment. Le niveau suivant de l’interaction permet au sous-système de contrôle d’accès de fournir un retour d’information au sous-système d’authentification, demandant généralement une authentification supplémentaire pour augmenter le score de confiance jusqu’au seuil minimum.

Après avoir utilisé des techniques d'authentification pour déterminer qui agit dans une transaction, les questions suivantes sont : Qu'est-ce que cet acteur a le droit de faire ? Et à qui ? C’est le domaine des technologies de contrôle d’accès.

Pour prendre une analogie avec la sécurité physique, imaginez que vous vouliez visiter une base militaire. Après que les gardes aient déterminé avec certitude si vous êtes un civil, un politicien ou un soldat, ils utiliseraient cette détermination pour décider dans quels bâtiments vous pourriez entrer et si vous pourriez apporter une caméra dans chaque bâtiment dans lequel vous seriez autorisé à entrer. La politique régissant ces choix peut être très grossière et s’appliquer à tous les bâtiments (par exemple, « les politiciens peuvent entrer dans n’importe quel bâtiment ») ou peut être plus précise (comme « les politiciens ne peuvent entrer que dans les bâtiments <A> et <B> mais ne peuvent apporter des caméras que dans <A> »).

Appliquées au contexte de la cybersécurité, les techniques de contrôle d’accès devraient incarner le principe de confiance zéro du « moindre privilège ». En d’autres termes, la politique de contrôle d’accès optimale autoriserait uniquement les privilèges dont l’acteur a besoin et interdirait tous les autres privilèges. De plus, une politique robuste idéale serait conditionnée à un niveau minimum spécifique de confiance dans l’authenticité de l’identité de l’acteur, le seuil de confiance étant spécifié à la granularité de chaque privilège autorisé.

Par conséquent, la valeur d’une solution de contrôle d’accès peut être jugée en fonction de son adéquation avec ces idéaux. Plus précisément, une solution de sécurité Zero Trust doit inclure le contrôle d’accès et doit évaluer la technologie de contrôle d’accès selon les dimensions décrites ci-dessous et décrites par la suite. 

1. Dans quelle mesure les privilèges de contrôle d’accès sont-ils précis ?

1. Quelle est la granularité de l’action ? Le quoi dans la transaction ? Est-ce que c'est :

1. Binaire : Autoriser « toutes » les transactions ou « aucune ». Dans l’analogie de la base militaire, cela correspondrait à « tous les soldats peuvent entrer dans n’importe quel bâtiment et faire ce qu’ils veulent » et « les civils ne peuvent entrer dans aucun bâtiment ».
2. Grossier : Granulaire jusqu'au point de terminaison de l'API ou au « type » de transaction (comme les E/S de fichiers, la communication réseau et les contrôles de processus). Dans notre exemple, cela permettrait un certain niveau de nuance autour de l’action autorisée, comme par exemple « les politiciens peuvent entrer dans les bâtiments mais ne peuvent pas prendre de photos ». 
3. Bien: Au niveau de la sous-API (c'est-à-dire en fonction des paramètres ou de la version de l'API) ou du « sous-type » de transaction (comme les E/S de fichiers en lecture seule ou les réceptions TCP uniquement). En reprenant notre analogie, cela permettrait des contrôles plus précis, comme par exemple : « les civils ne peuvent entrer dans les bâtiments que s’ils sont accompagnés d’un soldat. » 

2. Existe-t-il une granularité quant à la cible de l’action — le Qui dans la transaction ? Est-ce que c'est :

1. Pas de précision ciblée : La politique de contrôle d’accès ne prend pas en compte la cible de l’action. Dans notre exemple, cette approche correspondrait à la granularité consistant à autoriser l’entrée dans certains bâtiments, mais pas dans d’autres, les bâtiments étant la cible de l’action « entrer ».
2. Cible granulaire, niveau infrastructure : La politique de contrôle d'accès peut inclure la cible de l'action, mais utilise une balise/étiquette spécifique à l'infrastructure, telle que l'adresse IP, le nom DNS ou le nom du conteneur Kubernetes (K8S) pour la cible. Cela permettrait à la politique d’être granulaire au niveau des bâtiments, mais chaque base militaire pourrait avoir une convention de dénomination différente pour les bâtiments.
3. Cible granulaire, sensible à l'identité : La politique de contrôle d'accès peut inclure la cible de l'action, en identifiant la cible à l'aide du même espace de noms d'identité (par exemple, SPIFFE) utilisé pour l'acteur (le Qui). L’avantage par rapport à l’approche précédente est que toutes les bases militaires utiliseraient un système cohérent d’identification des bâtiments, ce qui rendrait la politique plus transférable.

2. Comment la solution de contrôle d’accès gère-t-elle le concept d’actions moins risquées ou plus risquées ?

1. Pas conscient du risque : La solution de contrôle d’accès traite tous les privilèges de contrôle d’accès de manière identique, en termes de décision d’autoriser ou d’interdire l’action.
2. Gestion des risques via MFA : La solution de contrôle d'accès gère le risque en permettant à la politique de spécifier que certaines transactions autorisées doivent toujours utiliser l'authentification multifacteur, en fonction de l'acteur ( Qui ), de l'action ( Quoi ) ou de la cible ( Qui ) impliqué dans la transaction.
3. La gestion des risques par la confiance : La solution de contrôle d'accès gère le risque en permettant à la politique de spécifier que toute transaction peut toujours nécessiter un niveau de confiance minimum dans l'authenticité de l'acteur, en fonction de l'action ( Quoi ) et de la cible ( Qui ) dans la transaction. L'AMF peut accroître la confiance, bien que d'autres moyens puissent être utilisés ; dans d'autres cas, la transaction peut ne pas être autorisée du tout si la valeur de la transaction est élevée et que l'authenticité de l'acteur est suffisamment incertaine.

Compte tenu du principe « d’évaluer (et de réévaluer) continuellement », toute croyance dans l’authenticité de l’acteur devrait s’ajuster au fil du temps. Dans une solution simple, il peut s’agir simplement d’un délai d’attente ; dans des systèmes plus sophistiqués, la confiance pourrait varier en fonction des observations du comportement de l’acteur au fil du temps.

Si l’authentification et le contrôle d’accès sont des mises en œuvre de l’état d’esprit « toujours vérifier » et « moindre privilège », alors la visibilité et l’analyse contextuelle sont fondamentales pour les principes « évaluer en permanence » et « supposer une violation ».

La visibilité est le précurseur nécessaire à l’analyse : un système ne peut pas atténuer ce qu’il ne peut pas voir. Ainsi, l’efficacité de la solution de sécurité Zero Trust sera directement proportionnelle à la profondeur et à l’étendue de la télémétrie qui peut être recueillie à partir des opérations du système et du contexte extérieur. Cependant, une infrastructure de visibilité moderne sera capable de fournir beaucoup plus de données, de métadonnées et de contexte potentiellement utiles que ce que n’importe quel humain raisonnable et non assisté sera en mesure de traiter en temps opportun. En raison du besoin de disposer de davantage de données et de la capacité à les distiller plus rapidement en informations, une exigence clé est l'assistance de la machine aux opérateurs humains.

Cette assistance est généralement mise en œuvre à l’aide d’algorithmes automatisés qui couvrent tout le spectre allant de l’analyse basée sur des règles aux méthodes statistiques en passant par les algorithmes avancés d’apprentissage automatique. Ces algorithmes sont responsables de la traduction du tuyau d'incendie des données brutes en une connaissance de la situation consommable et opérationnalisée qui peut être utilisée par les opérateurs humains pour évaluer et, si nécessaire, remédier à la situation. C’est pour cette raison que l’analyse assistée par ML va de pair avec la visibilité.

Le pipeline généralisé depuis les données brutes (visibilité) jusqu'à l'action (correction) est illustré ci-dessous : 

La visibilité est la mise en œuvre – le « comment » – du principe de confiance zéro « évaluer en permanence ». Il comprend la tenue d'un inventaire des entrées de données disponibles (Catalogue) et la télémétrie en temps réel ainsi que la conservation des données historiques (Collect).

La maturité d’une mise en œuvre de visibilité Zero Trust doit prendre en compte quatre facteurs : 

1. Latence : Dans quelle mesure les données sont-elles proches du temps réel ?

La latence fournit une limite inférieure à la rapidité avec laquelle une menace potentielle peut être résolue. La latence d’une solution Zero Trust doit être mesurée en secondes ou moins ; sinon, il est fort probable que toute analyse, aussi précise soit-elle, sera trop tardive pour empêcher l’impact de l’exploit, comme l’exfiltration/le chiffrement des données ou l’indisponibilité due à l’épuisement des ressources. Des systèmes plus sophistiqués peuvent permettre des atténuations synchrones et asynchrones. L’atténuation synchrone empêcherait l’achèvement de la transaction jusqu’à ce que la visibilité et l’analyse complètes soient terminées. Étant donné que l’atténuation synchrone est susceptible d’ajouter de la latence à la transaction, ce mode de fonctionnement serait réservé aux transactions particulièrement anormales ou risquées, tout en permettant à toutes les autres transactions d’envoyer de la télémétrie et d’être analysées de manière asynchrone.

2. Consommabilité : Dans quelle mesure les données peuvent-elles être facilement consommées ?
   

Cette préoccupation est pertinente si les données proviennent de plusieurs sources ou types de capteurs de données, ce qui est un scénario courant. Ce facteur se décompose généralement en deux sous-préoccupations. 

• Au niveau syntaxique, comment les données peuvent être extraites et représentées. Par exemple, si une réputation IP source arrive sous forme de champ de texte (tel que « malveillant », « suspect », « inconnu », etc.) dans un message syslog provenant d'une source, et sous forme de champ numérique codé en binaire dans un fichier de données provenant d'une autre source, alors une représentation canonique doit être identifiée. La sérialisation des données sera nécessaire pour extraire et transformer les données entrantes dans cette représentation. 

• Au niveau sémantique, différentes sources peuvent non seulement varier dans leur syntaxe et leur transport, mais aussi dans leur sémantique. En reprenant l’exemple de la réputation IP, un fournisseur peut fournir un score de menace sous forme de nombre, tandis qu’un autre fournisseur peut classer l’IP dans un compartiment tel que « nœud TOR », « contrôle DNS » ou « hameçonnage ». La solution de visibilité doit également fournir un mécanisme permettant de normaliser les données entrantes dans une syntaxe cohérente. 

3. Exhaustivité : Quelle est l’étendue et la profondeur des données disponibles ?

L’une des valeurs clés dérivées d’une solution de visibilité de haute qualité est la capacité à découvrir des activités suspectes comme indicateur d’une éventuelle violation. Pour ce faire efficacement, la solution doit recevoir la télémétrie sur toutes les « couches » pertinentes de la distribution d’applications : l’application elle-même, bien sûr, mais aussi l’infrastructure de l’application, l’infrastructure réseau, tous les services appliqués ou utilisés par l’application, et même les événements sur le périphérique client. Par exemple, l’identification d’un utilisateur venant d’un nouvel appareil, jamais vu auparavant, peut être légèrement suspecte en soi ; mais lorsqu’elle est combinée à des informations réseau (comme la cartographie GeoIP d’un pays étranger), le niveau de suspicion augmente davantage. Ce niveau de suspicion se manifeste par un score de confiance plus faible dans l’identité de l’utilisateur. Dans le cadre d'une politique de sécurité zero trust, lorsque cet acteur tente une transaction de grande valeur (comme un transfert de fonds vers un compte étranger), la solution de contrôle d'accès peut choisir de bloquer la transaction, en raison du faible niveau de confiance.

En ce qui concerne l'état d'esprit de confiance zéro, plus la solution de visibilité est profonde et complète, plus le système peut être efficace pour limiter de manière appropriée les transactions et détecter les violations.

4. Gouvernance : Dans quelle mesure les exigences légales et celles fondées sur les licences en matière d’utilisation des données sont-elles prises en charge ?

Enfin, toute collecte de données doit être conforme aux exigences légales et de licence relatives à la sécurité, à la conservation et à l’utilisation des données. Par conséquent, une solution de visibilité robuste doit répondre à chacun de ces besoins. La compréhension des contraintes d’utilisation des données impliquées par la gouvernance doit être prise en compte dans une solution de visibilité Zero Trust. Par exemple, si une adresse IP est considérée comme une information personnellement identifiable (PII), l'utilisation et la conservation à long terme des adresses IP à des fins d'analyse doivent répondre à l'utilisation autorisée des adresses IP. 

Outre la visibilité, l’autre mécanisme requis pour mettre en œuvre « l’évaluation continue » est l’outil analytique requis pour réaliser une évaluation significative, c’est-à-dire pour avoir une évaluation qui peut être opérationnalisée par une solution de confiance zéro.

L’un des éléments à prendre en compte lors de l’analyse est la portée et l’étendue des données d’entrée. Les entrées des algorithmes d'analyse peuvent être limitées à un seul flux de données provenant d'une seule source, ou peuvent porter sur plusieurs flux, y compris ceux provenant de diverses sources de données et de toutes les couches de l'infrastructure et de l'application. 

• La contextualisation la plus basique s'inscrit dans le cadre d'un seul « type » ou « flux » de données (comme un flux d'événements « informations de connexion utilisateur avec heure et adresse IP source »), généralement avec un contexte historique et/ou des données sur plusieurs utilisateurs. Cette analyse peut donner lieu à des informations de base, telles que « cet utilisateur <X> ne s'est jamais connecté à cette heure de la journée » ou « cet utilisateur <X> semble toujours se connecter immédiatement après l'autre utilisateur <Y> ». Le premier peut réduire la confiance dans l’identité ; le second peut être le signe d’un modèle de niveau supérieur, peut-être malveillant.
• Une contextualisation plus avancée prend en compte la portée temporelle et multi-instance non seulement pour un seul « type » de données, mais effectue également une corrélation temporelle entre différents « types » ou « flux » de données. Un exemple serait de corréler les données de connexion de l'utilisateur avec des actions spécifiques au niveau de la couche applicative (comme un transfert d'argent ou des mises à jour de contacts par courrier électronique) ou au niveau de la couche réseau (comme une recherche de géolocalisation basée sur IP). 

Un deuxième aspect particulièrement pertinent de l’analyse dans le cadre du Zero Trust concerne le volume et le taux de données ingérées, qui dépasseront la capacité de digestion de tout humain. Il est donc nécessaire de recourir à une forme d’assistance mécanique pour former des informations digestes pour l’homme. Une fois de plus, la sophistication de l’assistance peut être décrite comme une progression.

• Visualisation uniquement : La première étape est une simple présentation de statistiques et d’événements, généralement via des tableaux de bord disponibles sur un portail de gestion. Les données présentées sont basées sur des flux de données collectés (généralement une série chronologique ou une coupe longitudinale sur les utilisateurs/transactions dans une fenêtre temporelle fixe). Les tableaux de bord plus avancés offrent la possibilité de trier et de regrouper les données, ainsi que d'effectuer des analyses détaillées via le filtrage. Dans ce modèle, l’humain effectue toute l’exploration des données, la priorisation des événements, l’analyse et la correction, l’automatisation aidant principalement à l’exploration des données.
• Visualisation plus règles statiques configurables : L’extension la plus courante de la visualisation est la possibilité de permettre à l’humain de définir des règles spécifiées de manière statique, soit pour l’alerte, soit pour la correction. Des exemples de telles règles seraient « avertir l'humain < John > si < la charge du processeur dépasse 80 % pendant une période de 5 minutes > » ou « exiger < MFA par e-mail > si < l'API [Y] est invoquée et que le pays n'est pas [États-Unis] > ». Ces règles peuvent être limitées à celles prédéfinies spécifiées par le fournisseur de solutions, ou des sous-systèmes basés sur des règles plus avancés peuvent également autoriser des règles personnalisées écrites par un ingénieur SecOps. Dans les deux cas, toutes les règles appliquées sont généralement contrôlées (et définies, si nécessaire) via la configuration. 
• Visualisation plus assistance ML : Le niveau suivant utilise des techniques plus avancées qui détectent les anomalies comportementales et/ou les transactions qui correspondent aux modèles de transactions malveillantes précédemment identifiées. Bien qu'il existe de nombreuses techniques utilisées (et qu'une discussion approfondie des compromis techniques et commerciaux dépasse le cadre de cet article), il y a quelques points clés à prendre en compte : 

• Effort humain requis : Certaines techniques d’apprentissage automatique nécessitent une « formation » (également appelée apprentissage supervisé), ce qui signifie qu’un corpus de données de taille raisonnable doit être pré-catégorisé à l’aide d’un « classificateur » fiable et de confiance. Souvent, pour avoir une catégorisation fiable, le « classificateur » finit par être un humain ou un ensemble d’humains. Dans ces cas-là, l’effort humain requis doit être pris en considération. D'autres techniques (également appelées apprentissage non supervisé) détectent les anomalies et/ou reconnaissent des modèles par elles-mêmes, sans effort humain. 
• Explicabilité : Les résultats d’un système d’apprentissage automatique résultent de l’évaluation des données d’entrée par rapport à un modèle. Ce modèle peut être basé sur une série de questions simples et faciles à répondre, telles que : « Cet utilisateur a-t-il été vu sur cet appareil au cours du mois dernier ? » Cela pourrait également être basé sur une similitude facilement explicable, comme « cet utilisateur correspond au schéma général que j’ai observé d’utilisateurs qui ne se connectent jamais pendant les heures de travail ». Dans d’autres cas, le modèle peut être basé sur l’application d’un ensemble complexe d’opérations d’algèbre vectorielle sur les données d’entrée, sans logique de haut niveau facilement discernable. Ce dernier cas est clairement moins explicable – il s’agit davantage d’une « boîte noire » – que les deux exemples précédents. Dans certains cas, l’explicabilité est un facteur important pour la compréhension humaine ou l’auditabilité. Dans ces cas-là, un modèle explicable sera fortement préféré à un modèle impénétrable. 
• Disponibilité du score de confiance : Comme mentionné précédemment, une mesure indiquant le degré de confiance du modèle dans une décision (en d’autres termes, une idée de la probabilité relative d’un faux positif ou d’un faux négatif) est souvent très utile. Certains algorithmes sont tels qu'une sortie de mesure de confiance en résulte naturellement ; pour d'autres, comme ceux basés sur des règles, un niveau de confiance devrait être explicitement spécifié comme l'une des sorties. Dans les deux cas, les algorithmes capables de fournir un score de confiance sont plus robustes que ceux qui ne le peuvent pas. 

Comme avec l’approche basée sur des règles, l’assistance ML peut être destinée uniquement à la détection ou peut être liée à une correction automatique. De plus, l'assistance ML peut être utilisée en conjonction avec un système basé sur des règles, où le « verdict » ML (ou l'opinion ou la confiance) peut être utilisé comme entrée dans une règle, telle que « effectuer l'action <X> si <l'évaluateur ML [bot_detector_A] signale le bot avec une confiance supérieure à 90 %> ». 

Le dernier principe de l’état d’esprit « zéro rouille » est de « supposer une brèche ». Pour être clair et donner une perspective, des méthodes d’authentification et de contrôle d’accès correctement mises en œuvre sont efficaces pour empêcher l’écrasante majorité des transactions malveillantes. Cependant, il faut, par excès de paranoïa, supposer que les mécanismes d’application de l’authentification et du contrôle d’accès seront déjoués par un adversaire suffisamment motivé ou chanceux. La détection des brèches, nécessaire pour répondre à ces fuites dans les meilleurs délais, nécessite une visibilité et une analyse assistée par machine. C'est pourquoi, étant donné que les autres mécanismes d'application seront parfois déjoués, les technologies de visibilité alimentant l'analyse contextuelle assistée par ML sont un besoin essentiel pour alimenter la solution de sécurité Zero Trust de remédiation basée sur les risques. 

Dans les cas de « faux négatifs » où une transaction malveillante réelle a réussi à déjouer l’authentification et le contrôle d’accès, le mécanisme de correction automatisée basée sur les risques doit être utilisé comme mesure de protection. Mais comme cette technologie est utilisée comme protection contre les transactions qui ont passé les contrôles d’application précédents, il existe une plus grande inquiétude quant à la possibilité de signaler à tort ce qui était, en réalité, un « vrai négatif » (une transaction valide et souhaitable) comme un « faux positif » (signalé à tort comme une transaction malveillante). Pour atténuer cette préoccupation, toute action corrective déclenchée par une croyance en une éventuelle malveillance, qui n’a pas été détectée par l’authentification ou le contrôle d’accès, doit être basée sur les trois facteurs suivants :⁴

• Valeur commerciale de la transaction : Différentes transactions auront différents niveaux de risque et de récompense. Par exemple, une transaction consistant à consulter un compte bancaire est moins risquée qu’une transaction consistant à transférer de l’argent vers un compte étranger. De même, pour une compagnie aérienne, l’achat d’un billet est susceptible d’être une transaction offrant une récompense commerciale plus élevée, par rapport à une transaction qui répertorie les retards de vol actuels. La valeur commerciale est le bénéfice de la récompense commerciale potentielle pondéré par rapport au profil de risque de la transaction. Il est plus acceptable de tolérer les effets « faux positifs » d’une remédiation spéculative sur des transactions à faible récompense/à haut risque, par rapport à des transactions à haute récompense/à faible risque qui ont une valeur commerciale élevée. 
• Confiance dans la croyance en la « malveillance » : Bien entendu, toutes les suggestions de remédiation spéculative ne sont pas égales. Plus précisément, outre le rapport risque-récompense mentionné ci-dessus, l’autre facteur clé est la confiance dans les croyances entourant cette transaction, comme la confiance dans l’identité attestée de l’acteur. En gros, la probabilité d’un « faux négatif » — c’est-à-dire la probabilité que les mécanismes d’application ne se déclenchent pas, alors qu’ils auraient dû le faire — est inversement proportionnelle à la confiance dans l’acteur. Et comme la réduction des « faux négatifs » est l’objectif de la remédiation basée sur les risques, plus la confiance est faible, plus le système doit être biaisé en faveur de l’application de la remédiation.
• Impact de la remédiation : Enfin, toutes les mesures correctives ne sont pas des décisions binaires : autoriser ou bloquer. En fait, une variété de techniques de réduction des risques sont possibles, allant de certaines qui sont visibles pour l'utilisateur (par exemple, demander des informations d'identification supplémentaires/MFA, proposer un défi tel qu'un captcha), à d'autres qui sont pour la plupart invisibles pour l'utilisateur (effectuer une inspection plus approfondie du trafic telle que DLP, ou effectuer une analyse plus avancée/intensive en calcul). Par conséquent, l’impact de la mise en œuvre de ces formes supplémentaires de réduction des risques, mesuré par les frictions subies par l’utilisateur et les coûts opérationnels de l’application (comme pour la DLP ou l’analyse gourmande en ressources), est le troisième facteur à prendre en compte. Les mesures correctives à faible impact et transparentes pour le client sont préférées aux défis à impact plus élevé et visibles pour le client, et le blocage pur et simple de la transaction est l'option la moins attrayante. Toutefois, le blocage peut être approprié lorsque la confiance est élevée ou pour les transactions risquées qui ne peuvent pas augmenter suffisamment la confiance via les autres mécanismes de réduction des risques. 

La sécurité Zero Trust est une approche plus moderne des approches antérieures en matière de sécurité, telles que la défense en profondeur, qui étend l'état de la technique en adoptant une vision de la sécurité centrée sur les transactions : qui tente de faire quoi à qui . Cette approche permet non seulement de sécuriser l’accès externe à une application, mais s’applique également à la protection des éléments internes de l’application.⁵ Compte tenu de cette vision transactionnelle fondamentale, la sécurité Zero Trust repose sur un ensemble de principes fondamentaux qui sont utilisés pour défendre les applications dans l'environnement plus complexe et plus difficile d'aujourd'hui, les principes étant ensuite mappés à un ensemble de solutions au niveau du sous-système, ou de méthodes, qui incarnent ces principes. Les principes fondamentaux et la manière dont ils s’appliquent aux méthodes de résolution sont résumés ci-dessous. 

Ces outils (méthodes d’authentification, de contrôle d’accès, de visibilité, d’analyse contextuelle et de correction des risques) sont nécessaires et suffisants pour prévenir une grande variété de types d’attaques.

Télécharger le rapport