Revue des techniques et technologies pour l’adoption de la confiance zéro

En partant du « pourquoi » — les principes directeurs¹ — de la confiance zéro, il faut ensuite s’interroger sur le « comment », autrement dit, les techniques et technologies utilisées pour mettre en œuvre ces principes.

Sous l’angle le plus large, les principes de confiance zéro peuvent être appliqués à l’ensemble du cycle de développement des applications, en incluant la conception du système, les plates-formes matérielles utilisées et les procédures d’acquisition.² Cependant, ce document traite des aspects opérationnels de la mise en œuvre de la confiance zéro dans le but de défendre les applications et les données pendant l’exécution.

De manière générale, la sécurité confiance zéro utilise des technologies pour atteindre trois objectifs distincts :

1. Appliquer les contraintes transactionnelles : qui peut faire quoi à qui.
2. Fournir une connaissance de la situation à l’opérateur humain du système.
3. Effectuer une réduction/remédiation plus avancée des risques, sur la base d’indicateurs de suspicion assistés par l’apprentissage automatique (ML) et du profil risque/récompense des transactions en question.

Le graphique suivant décrit ce modèle transactionnel global de sécurité confiance zéro, les sections suivantes approfondissant chaque catégorie de technologies.

Les deux premières technologies, l’authentification et le contrôle d’accès, sont étroitement liées et sont 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 du principe « qui peut faire quoi ». Des implémentations plus sophistiquées de l’authentification surveillent le comportement d’un acteur en continu, selon le principe de « l’évaluation continue ».

Les technologies d’authentification ont pour but de renforcer la confiance dans une identité attestée : qui agit dans une transaction. Le processus d’authentification comporte trois éléments :

1. L’acteur présente une attestation ou une déclaration pour indiquer son identité.
2. Il existe des données, généralement fournies par l’acteur, qui prouvent la véracité de l’attestation.
3. Le système produit un verdict ou une décision quant à la probabilité que l’attestation soit correcte — et donc que l’acteur soit 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 d’eux, et est suivi d’une discussion plus approfondie de chaque aspect.

La forme la plus élémentaire d’attestation est souvent désignée par le terme « utilisateur » — un humain, ou un agent agissant au nom d’un humain, qui souhaite effectuer une transaction. Cependant, dans le cas de la confiance zéro utilisée au sein d’une application, l’acteur peut être une charge de travail (un processus, un service ou un conteneur) : le concept généralisé d’identité doit donc inclure de tels acteurs. Dans d’autres cas, la notion d’identité n’inclut pas seulement l’humain ou la charge de travail, mais des considérations ou des dimensions supplémentaires de l’identité. Dans ce contexte, les dimensions supplémentaires de l’identité peuvent inclure le dispositif ou la plate-forme de l’utilisateur/charge de travail, l’écosystème utilisé pour l’interaction ou encore l’emplacement de l’agent. Par exemple, un utilisateur « Alice » peut se trouver sur un PC étiqueté « ABC- 0001 » et utiliser une instance de navigateur spécifique à empreinte digitale, provenant de l’adresse IPv4 10.11.12.13.

Certains systèmes permettent à des utilisateurs non authentifiés, parfois appelés « invités » ou « anonymes », d’effectuer un ensemble limité de transactions. Dans ces systèmes, les étapes supplémentaires consistant à prouver l’identité et à rendre un verdict ne sont pas pertinentes. Toutefois, dans le cas d’une identité attestée, l’attestation est couramment étayée à l’aide des méthodes suivantes :

• La connaissance d’un secret partagé, un mot de passe par exemple.
• Une forme de justificatif provenant d’un tiers de confiance, comme un certificat signé.
• Une interrogation — automatisée (via l’empreinte digitale du dispositif) ou active (avec un captcha, par exemple) — de l’utilisateur, de la charge de travail ou de la plate-forme.
• Des métadonnées relatives à l’acteur : géolocalisation, réputation de l’IP ou heure d’accès.
• Une analyse comportementale, comme l’analyse biométrique passive ou les schémas d’interaction avec l’application.

Lorsqu’il est impératif d’avoir un haut degré de confiance, on peut utiliser plusieurs méthodes simultanément. C’est ce que montre le modèle BeyondCorp de Google³, qui exige une authentification multifacteurs (AMF) avant d’autoriser des transactions de valeur élevée. 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, il convient de noter que certaines de ces méthodes ne sont pas des actions statiques et ponctuelles, mais peuvent et doivent être permanentes, conformément au principe de « l’évaluation continue ». Dans ce 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 peut changer au cours d’une même session utilisateur, ce qui peut être considéré comme suspect et réduire le degré de confiance. Autre approche : au fil de la collecte de données sur le comportement de l’acteur au cours d’une session, le score de confiance peut augmenter ou diminuer, sur la base de la comparaison entre le comportement actuel et les observations antérieures.

L’authentification dynamique peut fonctionner de concert avec le contrôle d’accès dans des systèmes plus avancés. À titre de 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, généralement pour demander une authentification supplémentaire avant d’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 se posent : à quoi cet acteur est-il autorisé ? Et pour qui ? C’est le domaine des technologies de contrôle d’accès.

Pour faire une analogie avec la sécurité physique, imaginez que vous vouliez visiter une base militaire. Après avoir établi avec confiance si vous êtes un civil, un politicien ou un soldat, les gardes s’appuient sur cette information pour déterminer dans quels bâtiments vous pouvez entrer, et si vous pouvez introduire un appareil photo dans ces différents bâtiments. 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 plus fine (par exemple, « les politiciens ne peuvent entrer que dans le bâtiment et , et les appareils photo ne sont autorisées que dans  »).

Appliquées au contexte de la cybersécurité, les techniques de contrôle d’accès doivent concrétiser le principe de confiance zéro du « moindre privilège ». En d’autres termes, la politique de contrôle d’accès optimale n’accorde que les privilèges dont l’acteur a besoin et le prive de tous les autres. En outre, une politique robuste idéale serait conditionnée par un niveau minimum de confiance dans l’authenticité de l’identité de l’acteur, le seuil de confiance étant défini spécifiquement pour 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 degré d’alignement sur ces idéaux. Plus précisément, une solution de sécurité à confiance zéro doit inclure le contrôle d’accès et doit évaluer sa technologie selon les dimensions illustrées et décrites ci-dessous.

1. Quel est le degré de finesse des privilèges de contrôle d’accès ?

1. Quelle est la granularité de l’action — le quoi dans la transaction ? Est-ce qu’elle est :

1. Binaire : autoriser « toutes » les transactions ou « aucune ». Dans l’analogie de la base militaire, cela correspondrait à « tous les personnels militaires 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. Grossière : définie à l’échelle du point de terminaison de l’API ou du « type » de transaction (E/S de fichiers, communication réseau, contrôles de processus). Dans notre exemple, cela permettrait d’apporter de la nuance au sujet de l’action autorisée, comme « les politiciens peuvent entrer dans les bâtiments mais ils ne peuvent pas prendre de photos ».
3. Fine : au niveau inférieur à celui de l’API (c’est-à-dire en fonction des paramètres ou de la version de l’API) ou du « sous-type » de transaction (E/S de fichier en lecture seule ou réception TCP seulement). Toujours avec notre analogie, cela permettrait des contrôles plus fins, comme « les civils ne peuvent entrer dans les bâtiments que s’ils sont accompagnés d’un personnel militaire ».

2. Y a-t-il une granularité concernant à la cible de l’action — à qui dans la transaction ?

1. Pas de granularité à l’échelle de la cible : la politique de contrôle d’accès ne tient pas compte de la cible de l’action. Dans notre exemple, cette approche correspondrait à ne pas différencier l’autorisation d’accès en fonction des bâtiments, qui constituent la cible de l’action « entrer ».
2. Granularité à l’échelle de la cible, au niveau infrastructure : la politique de contrôle d’accès peut inclure la cible de l’action, mais elle utilise une étiquette/un tag spécifique à l’infrastructure, comme l’adresse IP, le nom DNS ou le nom du conteneur Kubernetes (K8S). La politique peut ainsi être granulaire à l’échelle des bâtiments, mais chaque base militaire pourrait avoir une convention de dénomination différente des bâtiments.
3. Granularité à l’échelle de la cible, connaissance de 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 nom d’identité (par exemple, SPIFFE) que celui utilisé pour l’acteur (le Qui). L’avantage par rapport à l’approche précédente ? Toutes les bases militaires utiliseraient un même schéma cohérent pour l’identification des bâtiments, ce qui rendrait la politique plus portable.

2. Comment la solution de contrôle d’accès gère-t-elle le concept de niveau de risque de l’action ?

1. Ne tient pas compte des risques : la solution de contrôle d’accès traite tous les privilèges de contrôle d’accès de manière identique quand il s’agit d’autoriser ou d’interdire l’action.
2. Gestion des risques via l’authentification multifacteur : la solution de contrôle d’accès gère les risques en permettant à la politique de spécifier que certaines transactions autorisées doivent tout de même utiliser l’authentification multifacteur, en fonction de l’acteur (qui), de l’action (quoi) ou de la cible (à qui) impliqués dans la transaction.
3. Gestion du risque 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 encore exiger un niveau de confiance minimum dans l’authenticité de l’acteur, en fonction de l’action (Quoi) et de la cible (Qui) de la transaction. L’AMF peut augmenter le niveau de confiance, mais d’autres moyens peuvent être utilisés ; dans d’autres cas, la transaction peut ne pas être autorisée du tout si elle est de grande valeur et si l’authenticité de l’acteur est suffisamment incertaine.

Compte tenu du principe « évaluer (et réévaluer) en continu », la confiance dans l’authenticité de l’acteur devrait s’ajuster au fil du temps. Dans une solution simple, on peut fixer un délai de validité ; dans des systèmes plus sophistiqués, la confiance pourrait varier en fonction de l’observation du comportement de l’acteur dans le temps.

Si l’authentification et le contrôle d’accès concrétisent l’approche de « vérification systématique » et de « moindre privilège », la visibilité et l’analyse contextuelle sont à la base des principes « évaluer en continu » et « prendre l’hypothèse de la violation ».

La visibilité est le prérequis indispensable à l’analyse : un système ne peut atténuer ce qu’il ne voit pas. Ainsi, l’efficacité de la solution de sécurité à confiance zéro 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. Toutefois, une infrastructure de visibilité moderne sera capable de fournir beaucoup plus de données, de métadonnées et de contexte potentiellement utiles qu’aucun être humain raisonnable et non assisté ne pourra jamais traiter en temps voulu. Face à l’envie d’obtenir toujours plus de données et de pouvoir les convertir en informations plus rapidement, l’assistance des machines devient incontournable pour les opérateurs humains.

Cette assistance est généralement mise en œuvre à l’aide d’algorithmes automatisés qui vont 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 chargés de traduire le flux de données brutes en une connaissance de la situation consommable et opérationnalisée, qui sera utilisée par les opérateurs humains pour évaluer et, si nécessaire, pour remédier. C’est pourquoi l’analyse assistée par ordinateur va de pair avec la visibilité.

Le pipeline global allant des données brutes (visibilité) à l’action (remédiation) est présenté ci-dessous :

La visibilité est la mise en œuvre — le « comment » — du principe de confiance zéro « évaluer en continu ». Elle implique la tenue d’un inventaire des entrées de données disponibles (catalogue), la télémétrie en temps réel et la conservation des données historiques (collecte).

La maturité de la mise en œuvre d’une visibilité confiance zéro doit tenir compte de quatre facteurs :

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

La latence détermine la limite inférieure de la rapidité de réaction à une menace potentielle. La latence d’une solution de confiance zéro doit être mesurée en secondes ou moins ; sinon, il est fort probable que toute analyse, aussi précise soit-elle, arrivera trop tard pour empêcher l’impact de l’exploit — exfiltration ou chiffrement des données, indisponibilité due à l’épuisement des ressources. Des systèmes plus sophistiqués permettent d’appliquer des mesures d’atténuation synchrones et asynchrones. L’atténuation synchrone empêchera l’achèvement de la transaction jusqu’à ce qu’une visibilité complète soit obtenue et qu’une analyse ait été effectuée. L’atténuation synchrone étant susceptible d’ajouter de la latence à la transaction, ce mode de fonctionnement devra être 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é : avec quelle facilité avec laquelle les données peuvent être 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 aspects.

• Le premier se situe au niveau syntaxique et concerne la façon dont les données peuvent être extraites et représentées. Par exemple, si une réputation d’IP source arrive sous forme de champ de texte (« malveillant », « suspect », « inconnu », etc.) dans un message syslog d’une source, et sous forme de champ numérique codé en binaire dans un fichier de données d’une autre source, il faut identifier une représentation canonique. La sérialisation des données sera nécessaire pour extraire et transformer les données entrantes dans cette représentation

• Le deuxième aspect se situe au niveau sémantique. En effet, les différentes sources peuvent varier non seulement dans leur syntaxe et leur transport, mais aussi sur la sémantique. En reprenant l’exemple de la réputation d’IP, un fournisseur peut donner un score de menace sous forme de nombre, tandis qu’un autre fournisseur peut classer l’IP dans une catégorie telle que « nœud TOR », « contrôle DNS » ou « phishing ». 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 principales valeurs dérivées d’une solution de visibilité de haute qualité est la capacité de découvrir des activités suspectes comme indicateur d’une éventuelle violation. Pour y parvenir efficacement, la solution doit recevoir des données télémétriques sur toutes les « couches » pertinentes de l’application : l’application elle-même, bien sûr, mais aussi l’infrastructure applicative, l’infrastructure du réseau, tous les services appliqués à l’application ou utilisés par elle, et même les événements sur le périphérique client. Par exemple, l’identification d’un utilisateur avec un nouvel appareil, jamais vu auparavant, peut être légèrement suspecte en soi ; mais lorsqu’elle est associée à des informations sur le réseau (comme la cartographie GeoIP d’un pays étranger), le niveau de suspicion augmente. Ce niveau de suspicion se manifeste par une baisse du score de confiance dans l’identité de l’utilisateur. Dans le contexte d’une politique de sécurité confiance zéro, 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, sur la base du faible niveau de confiance.

Selon la philosophie confiance zéro, plus la solution de visibilité est profonde et complète, plus le système parvient efficacement à limiter les transactions de manière appropriée et détecter les violations

4. Gouvernance : Dans quelle mesure les exigences statutaires et celles liées à l’utilisation des données sous licence 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. Une solution de visibilité confiance zéro doit donc comprendre les contraintes entourant l’utilisation des données impliquées par la gouvernance. Par exemple, si l’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 être conformes à l’usage autorisé des adresses IP.

Outre la visibilité, l’autre mécanisme nécessaire à la mise en œuvre de l’« évaluation continue » est l’outillage analytique requis pour procéder à une évaluation significative, c’est-à-dire une évaluation exploitable par une solution de confiance zéro.

L’un des aspects à prendre en compte pour l’analyse est la portée et l’ampleur des données d’entrée. Les données d’entrée des algorithmes d’analyse peuvent se limiter à un seul flux provenant d’une seule source, mais elles peuvent aussi être réparties sur plusieurs flux, et provenir de diverses sources de données et de toutes les couches de l’infrastructure et de l’application

• La contextualisation la plus élémentaire s’effectue dans le cadre d’un seul « type » ou « flux » de données (par exemple un flux d’événements « informations de connexion de l’utilisateur avec l’heure et l’adresse IP source »), généralement avec un contexte historique et/ou des données concernant plusieurs utilisateurs. Cette analyse peut donner lieu à des observations de base : « cet utilisateur ne s’est jamais connecté à cette heure de la journée » ou « cet utilisateur semble toujours se connecter immédiatement après un autre utilisateur . » Le premier cas peut réduire la confiance dans l’identité ; le second peut trahir un motif de plus haut niveau, potentiellement malveillant.
• Une contextualisation plus avancée envisage non seulement une perspective temporelle et multi-instance pour un seul « type » de données, mais effectue également une corrélation temporelle entre différents « types » ou « flux » de données. Par exemple, on pourrait corréler les données de connexion de l’utilisateur avec des actions spécifiques au niveau de la couche application (un transfert d’argent ou la modification d’un courriel de contact) ou au niveau de la couche réseau (recherche de géolocalisation basée sur l’IP).

Un deuxième aspect particulièrement pertinent de l’analyse dans le cadre de la confiance zéro est le traitement du volume et du rythme des données ingérées, qui dépassent la capacité d’assimilation de tout être humain. Par conséquent, il est indispensable de recourir à l’assistance de la machine pour produire des renseignements intelligibles par l’homme. Une fois encore, la sophistication de cette assistance peut être décrite comme une progression.

• Visualisation uniquement : la première étape est la 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 reposent sur la collecte de flux (généralement une série chronologique, ou bien une coupe transversale longitudinale des 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, mais aussi d’effectuer des recherches par filtrage. Dans ce modèle, l’homme se charge de l’exploration des données, de la hiérarchisation des événements, de l’analyse et de la correction, l’automatisation facilitant principalement l’exploration des données.
• Visualisation et règles statiques configurables : ensuite, l’extension la plus courante de la visualisation consiste à permettre à l’humain de définir des règles spécifiées de manière statique, que ce soit pour l’alerte ou la remédiation. Pour donner un exemple, « informer l’humain <Untel> si <la charge de CPU dépasse 80 % pendant une période de 5 minutes> » ou « demander une <MFA par courriel> si <l’API [Y] est invoquée dans un pays qui n’est pas [États-Unis]> ». Ces règles peuvent se limiter à celles que le fournisseur de la solution aura prédéfinies, mais des sous-systèmes plus avancés basés sur les règles peuvent également permettre à un ingénieur SecOps de rédiger des règles personnalisées. Dans les deux cas, les règles appliquées sont généralement contrôlées (et définies, si nécessaire) par la configuration
• Visualisation et assistance ML : le niveau suivant utilise des techniques plus avancées qui repèrent des anomalies comportementales et/ou des transactions correspondant à des modèles de transactions malveillantes précédemment identifiées. Bien que de nombreuses techniques soient utilisées (et une discussion approfondie des compromis techniques et commerciaux dépasse le cadre de cet article), quelques points clés doivent être pris en compte :

• Effort humain requis : Certaines techniques de ML nécessitent un « entraînement » (apprentissage supervisé). Autrement dit, un corpus de données de taille raisonnable doit être pré-catégorisé à l’aide d’un « classificateur » fiable. Souvent, pour obtenir une catégorisation fiable, le « classificateur » finit par être un humain ou un ensemble d’humains. Dans ce cas, l’effort humain requis doit être pris en considération. D’autres techniques (appelées apprentissage non supervisé) détectent les anomalies et/ou reconnaissent les modèles par elles-mêmes, sans effort humain.
• Explicabilité : les résultats d’un système d’apprentissage automatique sont le produit de l’évaluation des données d’entrée par rapport à un modèle. Ce modèle peut reposer sur une série de questions simples, telles que : « Cet utilisateur a-t-il été vu sur cet appareil au cours du dernier mois ? ». Il peut également s’appuyer sur une similitude facilement explicable, par exemple : « cet utilisateur s’inscrit dans un schéma général que j’ai observé, celui des 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 nettement moins explicable que les deux exemples précédents — c’est davantage une « boîte noire ». 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 métrique indiquant le degré de confiance du modèle vis-à-vis d’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 que la métrique de confiance se manifeste naturellement ; chez d’autres, comme ceux basés sur des règles, le niveau de confiance doit être explicitement spécifié comme l’un des résultats. Dans les deux cas, les algorithmes qui peuvent fournir un score de confiance sont plus robustes que ceux qui ne le peuvent pas.

Comme dans le cas de l’approche fondée sur des règles, l’assistance du ML peut servir uniquement à la détection ou être liée à la remédiation automatique. En outre, l’assistance ML peut être utilisée en conjonction avec un système basé sur des règles, où le « verdict » du ML (ou l’opinion, ou encore la confiance) peut être utilisé comme une entrée dans une règle, telle que « faire l’action si .

Le dernier principe de la philosophie confiance zéro consiste à « partir de l’hypothèse de la violation ». Pour être clair et donner une perspective, les 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 de mise en œuvre 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 contournements en temps utile, requiert de la visibilité et une analyse assistée par ordinateur. Par conséquent, c’est parce que les autres mécanismes de mise en œuvre seront parfois mis en échec que les technologies de visibilité, qui alimentent l’analyse contextuelle assistée par ordinateur, sont indispensables pour soutenir la remédiation basée sur le risque par une solution de sécurité confiance zéro.

Pour les cas de « faux négatifs », dans lesquels une transaction malveillante réelle déjoue l’authentification et le contrôle d’accès, le mécanisme de remédiation automatisée basée sur le risque doit être utilisé comme filet de sécurité. Mais comme cette technologie s’applique en dernier recours à des transactions qui ont passé les contrôles antérieurs, cela accroît le risque qu’un « vrai négatif », une transaction valide et souhaitable, soit transformé en « faux positif », signalé à tort comme une transaction malveillante. Pour atténuer ce problème, toute action de remédiation déclenchée par la conviction d’une éventuelle malveillance qui n’aura pas été détectée par l’authentification ou le contrôle d’accès, doit s’appuyer sur les trois facteurs suivants⁴ :

• Valeur commerciale de la transaction : les transactions peuvent présenter niveaux différents de risque et de récompense. Par exemple, une transaction qui consulte un compte bancaire est moins risquée qu’une transaction qui transfère de l’argent sur un compte étranger. De même, pour une compagnie aérienne, l’achat d’un billet est susceptible d’être une transaction à plus forte valeur commerciale, qu’une transaction visant à lister les retards de vols actuels. La valeur commerciale correspond à l’avantage de la récompense commerciale potentielle, pondérée par le profil de risque de la transaction. Il vaut mieux tolérer les effets de « faux positifs » d’une correction spéculative pour les transactions à faible récompense/risque élevé, que dans le cas de transactions à forte récompense/risque faible qui ont une valeur commerciale élevée.
• Confiance dans la croyance en la « malveillance » : bien sûr, toutes les suggestions de remédiation spéculative ne se valent pas. 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. Pour dire les choses simplement, 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 le risque, plus la confiance est faible, plus le système doit être enclin à appliquer la remédiation.
• L’impact de la mesure corrective : Enfin, toutes les mesures correctives ne sont pas des décisions binaires — autoriser ou bloquer. En effet, diverses techniques de réduction des risques sont possibles : certaines sont visibles pour l’utilisateur (demande d’informations d’identification supplémentaires/MFA, présentation d’un captcha, etc.), d’autres sont pratiquement invisibles (inspection plus approfondie du trafic avec la DLP, ou analyse plus avancée/intense en calcul). Par conséquent, l’impact 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 (en particulier pour la DLP ou les analyses très consommatrices de ressources informatiques), représente le troisième facteur à prendre en compte. Les mesures correctives à faible impact et invisibles pour le client sont préférables aux défis visibles à fort impact, et le blocage pur et simple de la transaction est l’option la moins intéressante. Cependant, il peut être approprié en cas de confiance élevée, ou pour les transactions risquées qui ne peuvent pas suffisamment augmenter la confiance via les autres mécanismes de réduction des risques.

La sécurité confiance zéro est une version plus moderne des approches antérieures de la sécurité, telles que la défense en profondeur, et elle étend l’état de l’art antérieur 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 aussi de protéger les éléments internes de l’application.5 Compte tenu de cette vision transactionnelle fondamentale, la sécurité confiance zéro est ancrée dans un ensemble de principes fondamentaux qui permettent de défendre les applications dans l’environnement plus complexe et plus difficile d’aujourd’hui. Ces principes sont ensuite mis en œuvre et incarnés dans un ensemble de solutions ou de méthodes au niveau des sous-systèmes. Les principes fondamentaux et les méthodes de solution correspondantes 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 remédiation en fonction des risques — sont nécessaires et suffisants pour prévenir une grande variété de types d’attaques.

Télécharger le rapport