5min. read

Si le terme « Zero Trust » est souvent mal compris et mal employé, il désigne une approche qui contribue réellement à réduire les cyber-risques systémiques et à renforcer la résilience.

Dans ce contexte, la migration vers le cloud offre une nouvelle chance aux architectures Zero Trust.

Zero Trust : définition et idées reçues

D’après certains fournisseurs, le Zero Trust concerne avant tout la gestion des identités et des accès. Autrement dit, la façon dont les entreprises permettent aux utilisateurs autorisés d’accéder à leurs ressources. Bien qu’il s’agisse effectivement d’un volet de ce concept, la gestion IAM fait partie d’une stratégie plus large qui tient compte de toutes les surfaces d’attaque de l’entreprise, des identités à l’infrastructure, en passant par les produits, les processus et la supply chain.

Tous les professionnels de la sécurité vous le diront : la confiance sur les réseaux et les architectures technologiques a toujours été une mauvaise idée. Un réseau de confiance connecté à votre réseau de data center peut très bien être compromis. Terminal piraté, utilisateur autorisé devenu menace interne, processus OS détourné, fichier de confiance malveillant... les exemples sont légion.

Par conséquent, le Zero Trust offre une approche stratégique pour éliminer toute confiance implicite entre des entités technologiques. Si votre entreprise était une boîte de nuit, ce modèle préconiserait de déployer des videurs non seulement à l’entrée, mais aussi à l’intérieur et dans le garage, sans oublier d’embaucher des gardes du corps pour escorter vos clients hors de l’établissement. Mais estce vraiment si simple ? Le Zero Trust n’est-il qu’un modèle pour une sécurité renforcée ?

Honnêtement, la question n’a jamais été de savoir si les entreprises devraient adopter le Zero Trust, mais plutôt pourquoi cela fonctionnerait cette fois-ci, et par où commencer compte tenu des coûts importants et des traditionnelles réticences face au changement.

Le Zero Trust contre les cygnes noirs

D’après mon expérience, les entreprises qui ont réussi leur adoption du Zero Trust ont su centrer leur programme sur la gestion des risques avant tout. Ayant travaillé pendant plus de dix ans pour un grand établissement de services financiers, je connais très bien ce sujet. Et je sais que, parfois, de petits évènements peuvent saboter toute une organisation, voire tout un secteur.

Récemment, ces évènements systémiques, ou cygnes noirs, sont aussi devenus très courants dans l’univers de la cybersécurité. Les ransomwares et les incidents sur la supply chain représentent sans doute les symptômes les plus visibles des risques qui font régulièrement l’actualité. Ces risques font également un excellent point d’ancrage pour votre programme Zero Trust.

Quant aux causes racines de ces risques technologiques systémiques, elles sont diverses et variées, ou pire encore, multifacettes :

  • Points de défaillance uniques.Ils comprennent les composants d’infrastructure clé qui cimentent votre stack technologique. Une infrastructure DNS, WebSSO ou Active Directory non sécurisée ou mal conçue peut vite devenir votre pire cauchemar
  • Monocultures logicielles obsolètes. Pensez aux systèmes d’exploitation, aux firmwares et aux logiciels qui affichent un excellent taux d’adoption dans votre organisation, mais dont les correctifs ne sont pas régulièrement installés. Une seule vulnérabilité peut vous exposer à des ransomwares ou des risques de sabotage catastrophiques.
  • Effet des réseaux « à plat ». Cela concerne les entreprises sans une bonne segmentation ni des contrôles réseau adaptés à travers leurs ressources IT (en particulier les appareils non gérés), OT et IoT. Ainsi, elles facilitent la tâche des attaquants, virus et ransomwares.

Pyramide Zero Trust

En règle générale, les entreprises traditionnelles exposées à une combinaison de ces risques systémiques fondent leur programme Zero Trust sur deux volets : l’harmonisation de leur stack de gestion des identités et des accès et celle de leur couche de connectivité. Ainsi, elles créent les conditions nécessaires à d’autres volets Zero Trust afin d’éliminer d’autres risques comme ceux liés aux monocultures de firmware, aux applications, etc.

Modèle Zero Trust : le rôle des plateformes

Si je devais expliquer la résilience en cybersécurité, je dirais ceci : pour créer une structure résiliente, il faut répondre aux questions de sécurité au niveau des systèmes, et non des composants. Par exemple, ne vous focalisez pas trop sur l’évaluation de l’efficacité des contrôles de votre sandbox. Concentrez-vous plutôt sur la façon dont votre sandbox s’intègre aux autres contrôles de sécurité dans votre entreprise. Dans la même veine, ne dépensez pas des millions en tests d’intrusion pour votre application la plus critique si celle-ci est connectée au même réseau qu’un équipement IoT tout aussi onéreux et exécute d’autres services exposés sur le serveur.

Dans un univers décentralisé et fragmenté, où les workloads et les identités se retrouvent sur Internet, il est très difficile d’adopter une approche aussi systématique de la cybersécurité sans harmoniser un certain nombre de fonctionnalités clés pour votre sécurité. Les objectifs :

  • Une seule stack pour les identités et les politiques
  • Une même compréhension des menaces actionnables
  • Un protocole/contrôle commun à tout votre système pour l’application de vos politiques et les informations sur les menaces

Phil Venables l’a aussi très bien expliqué dans l’un de ses derniers articles de blog. « Dans de nombreuses entreprises, l’une des techniques de sécurité les plus efficaces, c’est la création d’une base de contrôles universels qui s’appliquent partout – puis l’élargissement de cette base de manière économique en réduisant le coût unitaire des contrôles (nouveaux et existants). »

Dans son article, en prenant l’exemple du secteur automobile, il suggère que la standardisation des dispositifs de sécurité des voitures de course dans les véhicules des particuliers peut se transposer dans l’univers de la cybersécurité. De fait, la sécurité réseau et la connectivité nous offrent un très bon exemple.

Auparavant, en matière de sécurité réseau, tout ce qui se trouvait dans l’enceinte d’une organisation était considéré comme sûr, tandis que tout ce qui se trouvait en dehors ne l’était pas. En clair, la sécurité s’appliquait uniquement aux frontières de cette organisation. À l’heure du télétravail, du cloud, de l’Edge Computing et des accès mobiles, ce modèle ne convient plus.

Aujourd’hui, tous ces environnements sont connectés directement à Internet. Toutefois, ils sont tous dénués de contrôles de base comme la segmentation et des systèmes de détection des intrusions. Il faut dire que les tests et le déploiement de politiques et contrôles individuels coûtent cher. La plupart des contrôles de cybersécurité sont donc hors de portée des entreprises.

C’est pourquoi les plateformes de cybersécurité s’imposent peu à peu comme le meilleur moyen de déployer des stratégies Zero Trust et de réaliser des économies à terme.

Cloud : une chance pour le Zero Trust

La modernisation de votre stack de sécurité ou de connectivité n’est pas une mince affaire. Lorsqu’elle ne fait pas partie de vos programmes cloud et de télétravail, il faut parfois un coup dur (comme un ransomware) pour l’impulser. Toutefois, elle offre également une nouvelle chance à votre programme Zero Trust, dont vous auriez tort de vous priver.

En pleine migration des workloads, des applications et des utilisateurs dans le cloud, et dans un contexte d’adoption des pratiques DevOps, les entreprises ont tout intérêt à repenser leur sécurité dès maintenant, et non après le prochain incident. Hormis la sécurité de votre environnement de production, une approche systématique vous oblige à envisager celle de votre pipeline CI/CD et l’intégration des contrôles de sécurité en amont de ce pipeline. Voici quelques questions Zero Trust à vous poser à chaque projet, si vous prenez la sécurité de vos environnements cloud et DevOps au sérieux :

  • Avez-vous des doutes sur l’intégrité de l’appareil de votre ingénieur logiciel ?
  • Avez-vous des doutes sur l’intégrité de votre référentiel de code ?
  • Avez-vous des doutes sur l’intégrité du code tout au long du processus de développement et de déploiement ?
  • Faites-vous confiance à votre modèle d’Infrastructure as Code (IaC) ou container Docker tiers ? Attention : en moyenne, la moitié contient des vulnérabilités.
  • Quid des autres dépendances applicatives utilisées dans vos projets ?
  • Avez-vous des doutes sur les droits d’accès octroyés à vos identités ?
  • Avez-vous des doutes sur la recherche de problèmes de sécurité ou d’erreurs de configuration dans votre code, comme les identifiants codés en dur, les paramètres d’accès réseau trop généreux, etc. ?
  • Avez-vous des doutes sur l’intégrité de votre orchestrateur de microservices, etc. ?

La liste de questions à poser est encore longue. En clair, les risques systémiques se multiplient dans les environnements DevOps, tant à l’horizontale qu’à la verticale. À la verticale, les risques sont beaucoup plus nombreux que dans les environnements plus traditionnels. À l’horizontale, comme de nombreuses attaques (SolarWinds, etc.) l’ont montré, l’impact d’un seul package infecté peut s’avérer catastrophique.

En somme, ne manquez pas cette occasion d’implémenter le modèle Zero Trust dès les prémisses de votre transition cloud et DevOps.