BLOG | BUREAU DU CTO

Ce que Hollywood m’a appris sur le Zero Trust

Miniature de Ken Arora
Ken Arora
Publié le 05 mai 2022


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 :

UN.     Vérifiez toujours explicitement « qui » : Que c'est l'acteur qui tente d'interagir avec votre système.

B.     Par défaut, le moindre privilège requis est requis : Une fois l’identité établie, accordez à cet acteur uniquement les privilèges nécessaires pour interagir avec le système pour la transaction commerciale spécifique en cours d’exécution, avec les privilèges requis énumérés par la conception.

C. Surveiller et (ré ) évaluer en permanence : La vérification de l’identité et les droits de privilège ne doivent pas être une chose statique et ponctuelle ; au contraire, ces décisions doivent être continuellement évaluées et réévaluées.

D. Et, encore une fois, supposons que vous ayez été compromis : Enfin, malgré les trois points ci-dessus, présumez qu’un adversaire sophistiqué a réussi à franchir les défenses. Le système doit donc également réfléchir à la manière d’identifier et d’isoler les éléments ou identités compromis, ainsi qu’à une stratégie de confinement et/ou de correction de leur impact sur le système.

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.

Confiance zéro

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é confirmée, attribuez-lui un niveau de confiance via les droits de contrôle d’accès associés. Appliquez le principe du moindre privilège : ne donnez que les droits minimaux nécessaires pour que l’utilisateur accomplisse son rôle dans le système. Un contrôle d’accès idéal permet une définition précise des droits accordés, par exemple : Le rôle <X> donne accès aux API <1>, <3> et <4>, ainsi que des droits de lecture sur les objets des classes <Y> et <Z>. Privilégiez la bonne pratique qui consiste à masquer les scénarios complexes de contrôle d’accès aux ressources applicatives derrière des API, plutôt que d’accorder un accès direct aux objets, fichiers et ressources réseau.
     
  3. Visibilité : Abordons maintenant la phase « surveillance » de cette approche—une étape essentielle pour la « réévaluation continue »—vous devez assurer une visibilité permanente et en temps réel sur les comportements de chaque acteur du système. Dans ce cadre, le principe « si vous ne l’avez pas vu, cela ne s’est pas produit » est indiscutable. Par ailleurs, la « télémétrie » collectée doit non seulement rester visible, mais aussi pouvoir être exploitée dans un cadre facilitant le partage et la mise en contexte des informations rapportées. Vous pouvez ainsi combiner et corréler efficacement des données issues de multiples sources, ce qui renforce la qualité et l’efficacité de l’évaluation des risques.
     
  4. Analyse contextuelle assistée par ML : Vous devez bénéficier de cette visibilité pour appliquer efficacement le principe de « réévaluation continue ». Pour cela, vous avez besoin non seulement de visibilité, mais aussi d’analyse — généralement sur plusieurs sources de données (ce qui requiert un cadre adapté au partage, comme mentionné précédemment) en quasi temps réel. Nous utilisons souvent des systèmes d’apprentissage automatique IA pour détecter les acteurs aux comportements anormaux, afin d’identifier toute compromission potentielle du système. Enfin, un moteur d’analyse puissant vous fournira une réponse plus précise qu’un simple oui/non — idéalement une évaluation des risques accompagnée d’un score de confiance.
     
  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 élément du cadre « pourquoi, comment, quoi » est le « quoi » : vous pouvez atteindre vos objectifs et prévenir ou atténuer les catégories d’attaques grâce aux outils et techniques présentés. Nous détaillerons une taxonomie complète de toutes les cyberattaques dans un prochain article ; en attendant, les « pourquoi » et « comment » exposés ici couvrent bien le spectre des « menaces avancées » sophistiquées. Par exemple, une démarche zéro confiance peut contrer les menaces liées aux rançongiciels, même si elles proviennent de composants logiciels dits « de confiance » (aussi appelées attaques de la chaîne d’approvisionnement). Concrètement, appliquez le principe du moindre privilège, inscrit dans votre politique de contrôle d’accès, pour restreindre les droits de lecture/écriture uniquement aux acteurs qui en ont besoin, afin d’empêcher le chiffrement des fichiers. De plus, si un acteur — tel un composant logiciel autorisé à écrire sur les fichiers — venait à être compromis via une attaque de la chaîne d’approvisionnement, et tentait de chiffrer rapidement un grand nombre de fichiers, une analyse et une réévaluation continues détecteraient rapidement ce comportement anormal en observant l’étendue et la cadence d’accès aux fichiers. Cette détection, combinée à une réponse automatisée, vous permet de bloquer promptement ce type d’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) .