Thème

La notion de confiance dans le cadre de cet appel renvoie aux notions d’intégrité, d’innocuité, d’adéquation à l’usage, … Puis-je me fier à ces données pour agir en conséquence ? Puis-je faire confiance à ce traitement pour le laisser “s’exécuter” dans mon système ou sur mes données ? Puis-je faire confiance à cette entité pour lui permettre d’accéder à ces services et données ? Puis-je (toujours) faire confiance à un sous-système (potentiellement le mien, et potentiellement uniquement un canal de communication) pour exécuter mes traitements et gérer mes données ?

Au “bon vieux temps” des systèmes d’information atomiques clos et gardés [2] [11], les enjeux de confiance se réduisaient (très) grossièrement à la question suivante : êtes-vous (ou votre initiateur) déjà dans le système, ou êtes-vous toujours en dehors ? Toute entité à l’intérieur du système (ou processus initié de l’intérieur) est implicitement légitime pour accéder, agir sur, agir au nom ou supporter le système [13]. Chaque entité composant le système (matériel ou logiciel) a été “vérifiée” par le biais d’un processus d’approvisionnement impliquant un certain niveau (variable) d’évaluation ; les données de votre système ont été principalement produites par vous-même ; les processus de votre système sont exécutés sous votre contrôle ; et, l’accès à votre système est principalement un problème de contrôle physique (pas un problème informatique), à ​​l’exception de certains points bien identifiés tels que les sites Web et les serveurs de messagerie. L’administrateur a un contrôle (presque) total sur (presque) tout dans un périmètre clairement défini. Le jeu consiste à maintenir la confiance à l’intérieur de ce périmètre en maintenant les entités ou “ressources” non fiables à l’extérieur de ce périmètre. Cette approche de sécurisation de tels systèmes atomiques et sous contrôle est appelée le “Castle Security Model” [2] [11].

Depuis, les systèmes d’information ont beaucoup évolué. Les systèmes d’information sont de plus en plus décentralisés. Pour le cas “simple” d’un système d’information constitué de plusieurs enclaves entièrement contrôlées et interconnectées, l’utilisation de Réseaux Privés Virtuels (VPN) permet de revenir à une situation compatible avec le “Castle Security Model” (même si cela peut ne pas être pertinent pour les attaques d’aujourd’hui qui, entre autres différences, impliquent plus de mouvements latéraux qu’au “bon vieux temps”). Cependant, les systèmes d’information d’aujourd’hui sont généralement plus décentralisés que cela et ont perdu plus de contrôle sur leurs mécanismes de défense et leurs dépendances. Ils peuvent avoir des contrôles physiques plus faibles des périmètres de leurs enclaves, comme dans le cas du Travail à distance/domicile et de l’Internet des Objets (IoT). Ils s’appuient de plus en plus sur le cloud et, de l’Infrastructure as a Service (IaaS) à la Platform as a Service (PaaS), perdent de plus en plus le contrôle d’une partie de leurs interconnexions, de leur isolement des processus voisins et de la pile d’exécution, perdant même le contrôle de leur charge utile dans le cas du Software as a Service (SaaS). Ils peuvent également accepter le fait que certains de leurs “composants de support” peuvent ne pas être administrés du tout, ou du moins pas à un niveau professionnel, comme c’est le cas avec la tendance Bring Your Own Device (BYOD). Le processus de décentralisation lui-même peut ne pas être totalement maîtrisé, comme dans le cas du Shadow IT qui est l’un des principaux risques de cybersécurité selon 44% des répondants à une récente enquête sur la cybersécurité [9]. Même si l’utilisation du cloud est contrôlée, il y a des problèmes de confiance avec celui-ci, comme le manque de contrôle sur l’accès des administrateurs du fournisseur de cloud pour 45 % des répondants, et l’absence de visibilité sur la chaîne d’approvisionnement du fournisseur de cloud pour 51 % des répondants. Globalement, 86% des entreprises estiment que les outils fournis par les fournisseurs de cloud ne permettent pas de sécuriser les données et que d’autres outils spécifiques sont nécessaires [9].

Zero Trust [7] [1] est un modèle de sécurité qui répond à une partie des enjeux de cybersécurité résultant de la décentralisation des systèmes d’information. Il gagne de plus en plus de terrain dans le monde réel et est déployé dans l’industrie [10] [9] ainsi que dans les institutions publiques [3] [4]. Plutôt qu’une architecture spécifique ou un ensemble de méthodes et de technologies, Zero Trust est un ensemble de principes de conception et de stratégies de gestion de la cybersécurité [8] [7]. Son principe principal est de ne jamais compter sur la confiance implicite. En particulier, les autorisations (non seulement pour l’accès mais pour tout type de transaction) ne doivent jamais être accordées uniquement sur la base de l’emplacement de son demandeur (de quel réseau provient la demande). Cela ne signifie pas que le système ne doit pas reposer sur la confiance, mais cette confiance doit être gagnée et renouvelée [13]. “[T]rust is never granted implicitly but must be continually evaluated” [7] avant (contrôle) et postérieur (audit) à son octroi. Ce principe n’est pas nouveau et remonte au Jericho Forum [6] en 2004 [7]. D’autres principes, tels que le principe du moindre privilège [12] [15], sont encore plus anciens mais sont devenus plus prégnants avec la décentralisation et plus faciles à appliquer avec les technologies modernes. Un autre principe important de Zero Trust est d’affiner la granularité des contrôles jusqu’aux transactions unitaires. Le but est d’autoriser le moins de privilèges nécessaires juste pendant la durée du besoin [2].

Tous les principes de Zero Trust ne sont pas couverts par C&ESAR 2022. Les définitions exactes de Zero Trust varient, mais la NSA le résume en 4 points principaux [8] : a) “Coordinated and aggressive system monitoring, system management, and defensive operations capabilities”; b) “Assuming all requests for critical resources and all network traffic may be malicious”; c) “Assuming all devices and infrastructure may be compromised”; d) “Accepting that all access approvals to critical resources incur risk, and being prepared to perform rapid damage assessment, control, and recovery operations”. Dans le cadre de cette définition du concept Zero Trust, C&ESAR 2022 se concentre sur les points b et c dans un cadre hautement décentralisé : à un niveau de granularité fine, comment gagner la confiance dans les demandes de ressources, le trafic réseau, les appareils supports et l’infrastructure en général ? Sous-entendu par cette question, mais non équivalent, le problème de l’authentification est l’une des principales préoccupations du concept Zero Trust [7] [14] [1], et en général des responsables de sécurité informatique [5] [3].

Bien qu’utile pour résoudre certains des problèmes liés à la confiance dans un système décentralisé, selon la définition utilisée, certaines des questions couvertes par C&ESAR 2022 peuvent ou non être incluses dans le concept Zero Trust.

Parmi celles-ci, il y a le problème de la confiance transitive et de la propagation de la confiance. Par exemple, dans le cas d’un développeur dans une enclave contrôlée qui pousse du code vers un SaaS de contrôle de version, qui pousse ce code vers un SaaS d’Intégration Continue / Déploiement Continu (CI/CD) d’un autre fournisseur, qui lui-même pousse les “binaires” résultants à un serveur web SaaS d’encore un autre fournisseur, quelles sont les solutions potentielles pour que le développeur puisse avoir plus de confiance (contrôle et audit) dans les différents SaaS pour ne pas abuser de leurs privilèges ? Quelles sont les solutions potentielles pour que les fournisseurs SaaS fassent confiance à d’autres fournisseurs pour agir fidèlement au nom du développeur, y compris et au-delà de potentiels gestionnaires de version et de compilateurs préservant les signatures ? Plus généralement, comment faire confiance à une entité auparavant inconnue ou non vérifiée qui commence à interagir avec votre système en votre nom ou au nom d’un de vos utilisateurs ? Comment compter sur la confiance des autres pour faire confiance à une interaction ?

Sur un autre sujet, l’évaluation de la confiance nécessite des (méta)données. Dans un système très décentralisé géographiquement pouvant déplacer des charges utiles entre enclaves, comment assurer la diffusion et la synchronisation de ces (méta)données de manière sécurisée compatible avec les contraintes temporelles du système et les lois applicables au propriétaire des (méta)données données, le propriétaire de la charge utile et l’emplacement où réside l’enclave d’exécution ?