Ce qu’Hollywood m’a appris sur le Zero Trust

Ken Arora

Si jamais — dans une réalité parallèle ou un avenir fantasmé — j’avais l’occasion de concevoir les systèmes informatiques de Starfleet, je veillerais très certainement à ce que les systèmes d’armement ne soient pas reliés aux sous-programmes de maintien des fonctions vitales. Ou, si je commandais une force d’invasion extraterrestre chargée de conquérir la Terre — une planète peuplée d’une espèce totalement différente, rappelons-le —, j’exigerais une authentification biométrique plutôt qu’un code d’accès ou un jeton. Enfin, si l’un de mes officiers ou l’un de mes vaisseaux parvenait, contre toute attente, à « s’échapper » miraculeusement des mains de ses ravisseurs, je commencerais sans aucun doute par vérifier qu’il ne transporte pas de cheval de Troie.

Alors, quel est le rapport avec le modèle Zero Trust ? Comme vous l’avez sans doute deviné, Hollywood raffole des scénarios qui mettent en scène les conséquences désastreuses d’un manque de saine méfiance dès le départ. Et, de mon point de vue de professionnel de la cybersécurité, ce même état d’esprit — entretenir une saine méfiance — est au cœur même du modèle Zero Trust.

Alors, pourquoi ai-je choisi de me concentrer spécifiquement sur le zero trust ? Ma motivation tient à une tendance actuelle dans l’emploi du terme « zero trust ». Pour revenir à une autre anecdote liée à la production cinématographique, celle-ci remonte à la fin des années 1980, lorsque Hollywood abandonnait progressivement les anciennes technologies analogiques au profit de normes numériques pour l’audio, la vidéo et le montage en postproduction. À cette époque et dans ce milieu, bon nombre des membres les moins technophiles de la communauté cinématographique ne comprenaient pas vraiment ce que signifiait « numérique », et ne cherchaient d’ailleurs pas particulièrement à le savoir ; pour eux, ce terme était en pratique synonyme de « ce qui se fait de mieux ». Par conséquent — au grand désarroi de mes amis technophiles qui travaillaient avec eux — les producteurs et les réalisateurs se mettaient à demander si l’éclairage ou la construction des décors étaient « numériques », alors qu’ils voulaient en réalité savoir : « Est-ce la meilleure conception d’éclairage ou la meilleure construction de décors possible ? » Pour en revenir à aujourd’hui, j’entends trop souvent le terme « zero trust » employé au sein de la communauté des RSSI de la même manière que les producteurs de cinéma employaient le terme « numérique » en 1990.

Par ailleurs, j’ai récemment découvert le cadre « Start With Why » de Simon Sinek. Ce cadre, associé à mes souvenirs de la manière dont Hollywood envisageait les débuts du « numérique » et dont les films construisaient leurs intrigues autour de (mauvaises) pratiques de sécurité, m’a aidé à clarifier plusieurs de mes réflexions sur le modèle Zero Trust. Au cœur de ce modèle se trouve la morale des scénarios hollywoodiens évoqués en introduction : négliger quelques grammes de cyberprévention réfléchie lors de la conception et de l’exploitation des dispositifs de sécurisation d’un système critique entraînera par la suite des kilos de compromissions et de souffrances. Par analogie, au niveau du « pourquoi », qui est au centre de ce cadre, le modèle Zero Trust peut être formulé comme l’ensemble de convictions suivant :

A. Toujours vérifier explicitement « qui » : c’est-à-dire l’acteur qui tente d’interagir avec votre système.

B. Appliquer par défaut le principe du moindre privilège requis : Une fois l’identité établie, n’accordez à cet acteur que les privilèges strictement nécessaires pour interagir avec le système dans le cadre de la transaction métier spécifique en cours, les privilèges requis étant définis lors de la conception.

C. Surveiller et (ré)évaluer en continu : La vérification de l’identité et les droits d’accès ne doivent pas être statiques ni ponctuels ; au contraire, ces décisions doivent faire l’objet d’une évaluation et d’une réévaluation continues.

D. Et malgré tout, partez du principe que vous avez été compromis : Enfin, même après avoir appliqué les trois mesures ci-dessus, supposez qu’un adversaire expérimenté est parvenu à contourner les défenses. Le système doit donc également prévoir comment identifier et isoler les éléments ou identités compromis, ainsi qu’une stratégie visant à contenir et/ou à corriger leur impact sur le système.

En bref : Ne faites jamais confiance implicitement : vérifiez systématiquement. Et n’accordez que le niveau de confiance strictement nécessaire. Procédez à une évaluation continue. Et ne partez pas du principe que vous les détecterez tous. Voilà le « pourquoi » du modèle 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 concrétiser l’état d’esprit que suscite ce « pourquoi » — constitue un autre angle pertinent pour les professionnels ; il découle des convictions évoquées précédemment. Là encore, je vais être précis et m’inscrire dans le contexte de l’ensemble des outils dont disposent aujourd’hui les professionnels de la cybersécurité :

1. Authentification : tout acteur interagissant avec le système protégé doit déclarer une identité ou, dans certains cas, un ensemble d’identités — par exemple, une identité pour la personne ou le système automatisé, ainsi qu’une identité pour l’appareil ou la plateforme utilisé par cette personne ou ce système, voire une identité pour le navigateur ou l’outil permettant l’accès. L’approche Zero Trust implique que toute déclaration de ce type soit 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, l’observation et la vérification du comportement de cet acteur.
   
2. Contrôle d’accès : une fois l’identité établie, un niveau de confiance doit lui être attribué, matérialisé par les droits de contrôle d’accès qui lui sont accordés. La politique de contrôle d’accès doit respecter le principe du moindre privilège, selon lequel seuls les droits strictement nécessaires à l’acteur pour remplir son rôle au sein du système lui sont accordés. Dans l’idéal, les implémentations du contrôle d’accès doivent permettre de définir précisément les droits accordés, par exemple : Le rôle <X> permet d’accéder aux API <1>, <3> et <4>, et confère des droits de lecture sur les objets des classes <Y> et <Z>. Il convient de retenir comme bonne pratique que les scénarios complexes de contrôle d’accès ciblant les ressources applicatives 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é : Passons maintenant à la partie « surveillance » de cette approche — condition préalable à une « réévaluation continue » — : le système doit offrir une visibilité continue et en temps réel sur les comportements de chaque acteur au sein du système. Dans ce contexte, l’affirmation « si vous ne l’avez pas vu, cela ne s’est pas produit » fait figure d’axiome. En outre, la « télémétrie » recueillie doit non seulement être visible, mais aussi exploitable, c’est-à-dire s’inscrire dans un cadre permettant le partage et la contextualisation des informations rapportées. Les données provenant de plusieurs sources peuvent ainsi être combinées et corrélées de manière pertinente, ce qui permet une évaluation des risques plus robuste et plus efficace.
   
4. Analyse contextuelle assistée par l’apprentissage automatique : La visibilité susmentionnée vise à permettre la mise en œuvre du principe de « réévaluation continue ». Dans la pratique, ce principe exige non seulement de la visibilité, mais aussi une analyse — généralement menée en temps quasi réel sur plusieurs sources de données (ce qui nécessite le cadre propice au partage évoqué précédemment). Pour ce faire, l’évaluation continue devra souvent s’appuyer sur des systèmes d’IA fondés sur l’apprentissage automatique afin de détecter les acteurs présentant un comportement anormal et d’identifier toute compromission éventuelle du système. Enfin, un moteur d’analyse robuste doit être capable de fournir une réponse plus nuancée qu’un simple oui ou non — idéalement, une évaluation des risques assortie d’un indice de confiance.
   
5. Remédiation automatisée tenant compte des risques : Enfin, puisque ce modèle repose notamment sur l’idée que certains adversaires sophistiqués parviendront malgré tout à infiltrer le système, celui-ci doit être en mesure d’agir afin de renforcer la surveillance et, si nécessaire, de contenir et/ou de bloquer ces actions ou ces acteurs. La réponse du système — de la simple journalisation à une inspection approfondie, en passant par le blocage de l’action tentée, voire la tromperie de l’acteur malveillant présumé — doit être envisagée dans le contexte métier global. La probabilité et l’incidence des faux positifs ou des faux négatifs, ainsi que le risque que l’action fait peser sur l’activité, font partie des éléments à prendre en compte. Par exemple, le blocage de la consultation d’un catalogue de produits ne peut être approprié que si l’on est quasiment certain que l’acteur est un robot malveillant d’extraction de données, tandis que l’exigence d’une authentification supplémentaire peut convenir à une transaction bancaire avec un degré de certitude moindre. Enfin, compte tenu de la sophistication et de la rapidité des cyberattaques modernes, l’action de remédiation opérationnelle doit pouvoir être automatisée, la politique définie par l’humain étant formulée sous la forme d’objectifs fondés sur l’intention.

Le dernier volet du cadre « pourquoi, comment, quoi » est le « quoi » : autrement dit, les objectifs peuvent être atteints et les différentes catégories d’attaques peuvent être évitées ou atténuées grâce aux outils et techniques présentés ci-dessus. Une taxonomie exhaustive de l’ensemble des cyberattaques fera l’objet d’un prochain article. Toutefois, pour donner un aperçu de ce qui suivra, le « pourquoi » et le « comment » décrits ici couvrent bien tout le spectre des « menaces avancées » sophistiquées. Par exemple, l’approche Zero Trust permet de faire face aux rançongiciels, même lorsque ceux-ci sont lancés par des composants logiciels « de confiance » (ce que l’on appelle des « attaques de la chaîne d’approvisionnement »). Plus précisément, le principe du moindre privilège, mis en œuvre dans la politique de contrôle d’accès, doit servir à limiter les autorisations de lecture et d’écriture des fichiers aux seuls acteurs qui en ont besoin, afin d’empêcher le chiffrement des ressources de fichiers. En outre, si un acteur — par exemple un composant logiciel existant disposant d’autorisations d’écriture sur les fichiers — venait à être compromis au moyen du vecteur d’attaque de la chaîne d’approvisionnement mentionné précédemment et tentait de chiffrer rapidement un grand nombre de fichiers, une réévaluation et une analyse continues devraient permettre de détecter rapidement ce comportement anormal, notamment en observant l’étendue des fichiers consultés et la fréquence à laquelle ils le sont. Cette détection, associée à des mesures d’atténuation automatisées, permet de bloquer rapidement ce type d’activité.

Revenons donc aux mondes parallèles que j’évoquais au début… Si tous les sous-systèmes informatiques de Starfleet appliquaient le principe du moindre privilège, l’API qui lance les torpilles à photons ne devrait pas pouvoir être appelée par le sous-système de contrôle de la gravité. Quant aux commandes du vaisseau-mère extraterrestre, non seulement elles utiliseraient une authentification multifacteur biométrique, mais les dispositifs de sécurité du vaisseau partiraient également du principe que des intrusions se produiront : ils assureraient donc une surveillance et une réévaluation continues, détecteraient l’anomalie que constitue un drone de combat traversant le vaisseau et neutraliseraient la menace si ce drone anormal se dirigeait vers le cœur du réacteur. Ces quelques précautions essentielles éviteraient bien des rebondissements dramatiques — une mauvaise nouvelle pour Hollywood, mais une bonne pour les professionnels de la cybersécurité.

Pour en savoir plus sur le cadre qui englobe les grands concepts liés au Zero Trust, dans le contexte actuel des entreprises, ainsi que sur l’approche de la sécurité que les responsables des applications métier devraient adopter, consultez notre livre blanc « Sécurité Zero Trust : pourquoi le Zero Trust est essentiel (et pas seulement pour les accès) ».

À propos de l’auteur

Ken Arora

Autres articles de Ken Arora