Ce que Hollywood m’a appris sur le Zero Trust

Si jamais, dans une réalité alternative ou un futur fantastique, j’avais l’opportunité de concevoir les systèmes informatiques de Starfleet, je veillerais à ce que les systèmes d’armes ne soient pas connectés à des sous-programmes de survie. Ou, si je devais être le commandant d’une force d’invasion extraterrestre chargée de prendre le contrôle de la Terre – une planète avec une espèce complètement différente, remarquez – j’insisterais sur l’authentification biométrique, plutôt que sur un code d’accès ou un jeton. Et enfin, si l’un de mes officiers ou l’un de mes vaisseaux spatiaux parvenait, contre toute attente, à « échapper » miraculeusement à ses ravisseurs, je vérifierais certainement d’abord qu’il ne transporte pas de chevaux de Troie.

Alors, qu’est-ce que cela a à voir avec le Zero Trust ? Comme vous l’avez probablement deviné, Hollywood adore les intrigues qui mettent en scène les conséquences épiques qui résultent du renoncement à quelques onces de paranoïa saine au départ. Et, de mon point de vue de praticien en cybersécurité, ce même état d’esprit – maintenir une paranoïa saine – est au cœur de ce qu’est réellement la confiance zéro.

Alors, pourquoi est-ce que je choisis de me concentrer sur le Zero Trust, en particulier ? Ma motivation est basée sur une tendance dans la façon dont le terme « zero trust » est utilisé aujourd’hui. Pour revenir à une autre anecdote de production cinématographique, celle-ci de la fin des années 80, c'était l'époque où Hollywood passait des technologies analogiques traditionnelles aux normes numériques pour l'audio, la vidéo et le montage post-traitement. À cette époque et à cet endroit, de nombreux membres moins techniques de la communauté cinématographique ne comprenaient pas réellement ce que signifiait « numérique », et ne s’en souciaient pas vraiment ; au contraire, le terme « numérique » était, pour eux, effectivement synonyme de « meilleur de sa catégorie ». En conséquence, et au grand dam de mes amis techniciens qui travaillaient avec eux, les producteurs et les réalisateurs ont commencé à se demander si l’éclairage ou la construction du décor étaient « numériques », alors qu’en réalité, ils voulaient dire : « Est-ce la meilleure conception d’éclairage ou la meilleure construction de décor ? » Maintenant, pour revenir à aujourd’hui, j’entends trop souvent le terme « zero trust » utilisé au sein de la communauté des OSC de la même manière que les producteurs de films utilisaient le terme « numérique » en 1990.  

Par ailleurs, j’ai récemment découvert le cadre « Commence par le pourquoi » de Simon Sinek. Ce cadre, élaboré parallèlement aux souvenirs de la façon dont Hollywood pensait aux débuts du « numérique » et de la façon dont les films créaient des histoires basées sur des (mauvaises) pratiques en matière de sécurité, a contribué à distiller un certain nombre de réflexions que j’avais autour de la confiance zéro. Au cœur du concept de confiance zéro se trouve la morale des scénarios hollywoodiens avec lesquels j’ai commencé : renoncer à quelques onces de cyber-prévention réfléchie dans la conception et le fonctionnement de la sécurisation d’un système critique se traduira par des kilos de compromis et de souffrances ultérieurs. De même, au niveau central du « pourquoi » du cadre, la confiance zéro peut être articulée comme l’ensemble de croyances suivant :

Simplement : Ne faites pas confiance implicitement, vérifiez plutôt toujours. Et ne faites confiance qu'autant que nécessaire. Et évaluer en permanence. Et ne présumez pas que vous les attraperez tous. C’est le « pourquoi » du Zero Trust.

Bien sûr, le « pourquoi » n’est qu’une partie de l’histoire. Le « comment » — c’est-à-dire les techniques et les outils utilisés pour incarner l’état d’esprit que le « pourquoi » engendre — est une autre perspective pertinente pour le praticien ; elle découle des croyances susmentionnées. Là encore, je serai précis, formulé dans le contexte de l’ensemble actuel d’outils dont disposent les praticiens de la cybersécurité d’aujourd’hui :

1. Authentification : Tout acteur interagissant avec le système protégé doit attester d’une certaine identité ou, dans certains cas, d’un tuple d’identités, comme une identité pour le système humain ou automatisé, ainsi qu’une identité pour l’appareil ou la plateforme sur laquelle se trouve l’humain/le système, et peut-être même une identité pour le navigateur ou l’outil utilisé pour faciliter l’accès. L’état d’esprit de confiance zéro implique que toute attestation de ce type doit être vérifiée, ou « authentifiée », par un ou plusieurs moyens : un secret partagé, un jeton ou un certificat et, dans les systèmes plus modernes, en observant et en vérifiant également le modèle de comportement de cet acteur.
    
2. Contrôle d'accès : Une fois l’identité établie, il convient de lui attribuer un niveau de confiance, matérialisé par les droits de contrôle d’accès accordés à cette identité. La politique de contrôle d’accès doit suivre le principe du moindre privilège, où les seuls droits accordés sont l’ensemble minimal requis pour que l’acteur puisse jouer son rôle au sein du système. Les implémentations idéales de contrôle d’accès devraient permettre une spécification précise des droits accordés, tels que : Le rôle permet d'accéder aux API <1>, <3> et <4>, ainsi que de lire les privilèges sur les objets de classe et . Une bonne pratique à noter est que les scénarios de contrôle d’accès complexes ciblant les ressources d’application doivent être abstraits derrière des API, plutôt que d’accorder un accès direct aux objets, aux fichiers et aux ressources réseau.
    
3. Visibilité : Passant à la partie « surveiller » de l'état d'esprit — une condition préalable à la « réévaluation continue » — le système doit être capable d'avoir une visibilité continue et en temps réel sur les comportements de chaque acteur. Dans ce contexte, l’affirmation « si vous ne l’avez pas vu, cela ne s’est pas produit » est axiomatique. De plus, non seulement la « télémétrie » collectée doit être visible, mais elle doit également être consommable, dans le sens où elle doit exister dans un cadre qui permet le partage et la contextualisation de ce qui est rapporté. Cela permet de combiner et de corréler de manière significative les données provenant de sources multiples, ce qui permet une évaluation des risques plus robuste et plus efficace.
    
4. Analyse contextuelle, assistée par ML : La motivation derrière la visibilité susmentionnée est de pouvoir mettre en œuvre le principe de « réévaluation continue ». Dans sa mise en œuvre, ce précepte requiert non seulement une visibilité, mais également une analyse, généralement sur plusieurs sources de données (nécessitant le cadre convivial de partage mentionné précédemment) en temps quasi réel. Pour ce faire, l’évaluation continue nécessitera souvent l’assistance de systèmes d’apprentissage automatique d’IA pour détecter les acteurs qui agissent de manière anormale, afin d’identifier toute compromission possible du système. Enfin, un moteur d’analyse robuste devrait être capable de fournir une réponse plus nuancée qu’un simple oui/non binaire – idéalement, une évaluation des risques accompagnée d’un score de confiance associé.
    
5. Correction automatisée tenant compte des risques : Enfin, comme une partie du système de croyance est que certains adversaires sophistiqués parviendront toujours à infiltrer le système, le système doit être capable d’agir, afin de surveiller plus en profondeur et, si nécessaire, de contenir et/ou de bloquer de telles actions ou de tels acteurs. La réponse du système, allant de la simple journalisation à une inspection plus approfondie en passant par le blocage de l'action tentée, voire la tromperie de l'acteur suspecté, doit être considérée dans le contexte commercial de niveau supérieur. La probabilité et l’impact des faux positifs ou négatifs, ainsi que le risque commercial de l’action font partie de ces considérations. Par exemple, bloquer la navigation dans un catalogue de produits peut n'être approprié que s'il existe une très grande confiance dans le fait que l'acteur est un scraper de site malveillant, mais exiger une authentification supplémentaire peut être approprié pour une transaction bancaire avec un degré de confiance plus modéré. Enfin, en raison de la sophistication et de la rapidité des cyberattaques modernes, l’action de correction opérationnelle doit être automatisable, la politique spécifiée par l’homme étant décrite en termes d’objectifs axés sur l’intention.

Le dernier aspect du cadre « pourquoi, comment, quoi » est le « quoi », à savoir que les objectifs peuvent être atteints et que les classes d’attaques peuvent être évitées ou atténuées à l’aide des outils et techniques ci-dessus. Une taxonomie complète de l’ensemble des cyberattaques fera l’objet d’un prochain article. Toutefois, en guise d’aperçu des attractions à venir, le « pourquoi » et le « comment » décrits ici abordent le spectre des « menaces avancées » sophistiquées. À titre d’exemple, l’état d’esprit « Zero Trust » peut permettre de faire face aux menaces de ransomware, même si elles sont initiées par des composants logiciels « de confiance » (également appelés « attaques de la chaîne d’approvisionnement »). Plus précisément, l’application du principe du moindre privilège, intégré dans la politique de contrôle d’accès, devrait être utilisée pour limiter les autorisations de lecture/écriture de fichiers uniquement aux acteurs qui ont besoin de ce privilège, empêchant ainsi le chiffrement des ressources de fichiers. De plus, si un acteur (peut-être un composant logiciel existant avec des autorisations d’écriture de fichiers) devait être compromis (en utilisant le vecteur d’attaque de la chaîne d’approvisionnement susmentionné) et tenter de chiffrer les données à haut débit sur de nombreux fichiers, une réévaluation et une analyse continues devraient détecter le comportement anormal dans les plus brefs délais, comme le montre la notation de l’étendue des fichiers consultés et de la vitesse à laquelle ils sont consultés. La détection, couplée à une atténuation automatisée, peut être utilisée pour bloquer rapidement une telle activité. 

Alors, revenons aux mondes alternatifs avec lesquels j'ai commencé... Si tous les sous-systèmes informatiques de Starfleet fonctionnaient selon le principe du moindre privilège, l’API qui lance les torpilles à photons ne devrait pas être invocable par le sous-système de contrôle de la gravité. Et les commandes du vaisseau-mère extraterrestre n’effectueraient pas seulement une MFA basée sur la biométrie, mais les contrôles de sécurité du vaisseau-mère supposeraient également que des violations se produiront – et donc surveilleraient et réévalueraient en permanence, détectant l’anomalie d’un drone de combat qui vole à travers le vaisseau, et atténuant la menace si ce drone anormal se dirige vers le noyau du moteur. Ces quelques onces de prévention permettraient d’éviter de nombreux drames à long terme – mauvais pour Hollywood, mais bons pour les professionnels de la cybersécurité.

Pour en savoir plus sur le cadre englobant les concepts généraux autour de Zero Trust, par rapport au contexte commercial existant et à l'état d'esprit de sécurité que les chefs d'entreprise d'applications devraient adopter, lisez notre livre blanc Zero Trust Security : Pourquoi Zero Trust est important (et pour bien plus que le simple accès) .