Vous êtes victime d’un incident de sécurité ? Contactez notre CERT

11/10/2021

Cybersecurity Insights

ZTNA et introduction au modèle Zero Trust

Ce premier article sur le Zero Trust Network Access (ZTNA) a pour but de donner les principes fondamentaux sur lesquels reposent le ZTNA. Nous allons voir une définition du modèle Zero Trust après avoir contextualisé les enjeux actuels sur les accès distants.

Selon le Gartner, en 2023, plus de 60% des entreprises adopteraient une solution ZTNA pour remplacer leur solution VPN. Le ZTNA apporte une nouvelle réponse pour offrir des accès distants aux collaborateurs accentuée pendant la crise de la COVID-19. Les accès distants sont devenus nécessaires pour assurer la continuité d’une entreprise. Le nombre de cyberattaques a d’ailleurs fortement augmenté pendant cette période. La sécurité des accès distants est donc de plus en plus préoccupante.

Contexte actuel

Le modèle périmétrique adopté depuis plusieurs années pour sécuriser les infrastructures réseaux ne suffit plus. Le modèle consiste à autoriser ou à bloquer les flux entre une zone réseau définie et une autre. Un attaquant peut se déplacer à l’intérieur du réseau en utilisant les flux autorisés sans qu’aucune vérification supplémentaire ne soit effectuée :

ZTNA

La notion de périmètre a évolué avec l’apparition des solutions d’accès à distance et le Cloud. La solution d’accès à distance la plus répandue est le VPN SSL. A l’origine, seuls les administrateurs y avaient accès. Désormais, les collaborateurs les utilisent aussi depuis des accès internet personnels pour télétravailler.

Le Cloud donne aux entreprises la possibilité d’héberger une partie ou l’ensemble de leurs ressources chez le fournisseur Cloud. Le périmètre à sécuriser n’est plus limité aux ressources hébergées sur site mais aussi chez le fournisseur Cloud. Les accès depuis des réseaux non gérés par l’entreprise sont de plus en plus nombreux et représentent des vecteurs d’attaques potentiels.

Pour répondre à ces problématiques, le ZTNA ne repose plus sur le modèle périmétrique mais sur le modèle Zero Trust.

Une définition du modèle Zero Trust

Les notions de flux autorisés et de périmètres accordent une confiance implicite que le modèle Zero Trust refuse. Dans les années 2000, le Jericho Forum ainsi que le projet Black Core initié par le Département de la Défense des États-Unis proposent des pistes de réflexion sur un nouveau modèle de sécurité. L’accès dépendrait désormais de l’identité de l’utilisateur. En 2010, John Kindervag, analyste chez Forrester, reprend ces idées pour définir le modèle Zero Trust. Ce modèle n’accorde aucune confiance mais des accès en imposant plusieurs vérifications. Ces vérifications forment un contexte.

Le contexte est composé de l’identité de l’utilisateur, du rôle de l’utilisateur et de la vérification de conformité du terminal utilisé, aussi appelée Device Posture. L’authentification multi-facteurs est imposée à l’utilisateur qui doit saisir ses identifiants et effectuer une seconde action :

  • Saisie du code envoyé par SMS, mail ou généré via une application (OTP)
  • Validation de la demande d’accès via une application (PUSH)
  • Utilisation du jeton RSA ou de clé d’authentification

Le rôle de l’utilisateur est analysé pour appliquer un principe de moindres privilèges et un principe de besoin d’en connaître au strict nécessaire limitant la visibilité et l’accès à certaines ressources. Pour s’assurer que l’accès n’expose pas l’infrastructure à des menaces externes, une vérification granulaire du terminal est effectuée.

Vérification granulaire de la conformité du terminal

Aucune distinction n’est faite entre des utilisateurs qui se connectent depuis des réseaux gérés et non gérés par l’entreprise. Les vérifications sont appliquées de la même manière pour ne pas accorder de confiance implicite. Le modèle donne aussi la possibilité à l’ensemble des terminaux et à l’ensemble des réseaux d’accéder aux ressources de l’entreprise.

La vérification est continue et ne s’arrête pas au moment où l’accès à une ressource a été accordé. La conformité du terminal utilisé peut changer, ce qui conduit à une réévaluation de l’accès accordé. Le trafic est aussi surveillé pour détecter une action malveillante.

En 2014, Google intègre le concept du modèle Zero Trust dans un projet de refonte de l’infrastructure. Ce projet s’intitule BeyondCorp en référence au nom de l’architecture à implémenter au sein de Google. BeyondCorp désigne aussi la solution Zero Trust que Google propose à ses clients. Cette décision a été prise à la suite d’une cyberattaque : l’Opération Aurora.

Article sur l’Opération Aurora : https://cyware.com/news/everything-you-need-to-know-about-operation-aurora-5c5f5b99

L’objectif est de protéger l’accès aux services web et SSH depuis des terminaux gérés par Google. La même année, la Cloud Security Alliance présente le Software-Defined Perimeter pour proposer un second modèle d’architecture Zero Trust.

L’architecture Zero Trust

Le modèle Zero Trust est un concept et ne représente pas une solution qu’une entreprise peut appliquer en tant que tel. Néanmoins, le NIST a déterminé les composants logiques permettant d’obtenir un début d’architecture Zero Trust dans son état de l’art. Une architecture Zero Trust est divisée en deux parties : le Control Plane et le Data Plane.

Composants logiques d’une architecture Zero Trust selon le NIST

Le Control Plane

Le Control Plane représente l’ensemble des composants chargés de collecter les informations nécessaires à la retranscription du contexte et chargés de la prise de décision. Il est composé du Policy Decision Point, lui-même composé du Policy Engine et du Policy Administrator. Le Policy Engine applique les politiques d’accès en s’appuyant sur les données collectées : le contexte. Le Policy Administrator génère les identifiants nécessaires à la communication entre le terminal et la ressource.

Dans le Control Plane, d’autres éléments sont aussi présents pour compléter la constitution d’un contexte comme les logs d’activité, les inventaires d’identité pour les utilisateurs et les terminaux ou encore la PKI pour vérifier l’authenticité d’un certificat. La centralisation des logs et la remontée d’alertes assurent la surveillance continue de l’ensemble du trafic avec le SIEM. Pour protéger le dispositif mis en place, la Threat Intelligence peut aussi être utilisée.

Le Data Plane

Le reste des composants se trouve dans le Data Plane. Le Data Plane représente l’ensemble des composants avec lesquels l’utilisateur peut interagir. L’utilisateur peut interagir avec le Policy Enforcement Point mais pas avec le Policy Decision Point qui est dans le Control Plane.

Lorsqu’un utilisateur veut accéder à une ressource, il est obligé de passer par le Policy Enforcement Point. Le Policy Enforcement Point envoie une demande au Policy Decision Point qui va renvoyer la décision prise. Ce composant ne collecte que l’information transmise par le Policy Decision Point et applique la décision renvoyée.

Pour revenir à BeyondCorp et au Software-Defined Perimeter (SDP), les architectures sont différentes mais utilisent ces composants logiques. BeyondCorp utilise un portail pour imposer les décisions renvoyées par le Data Plane et imposer l’authentification à l’utilisateur. Pour l’authentification, BeyondCorp utilise aussi un serveur RADIUS et le SSO. Le SDP utilise un autre système pour authentifier l’utilisateur avec l’envoi de Single-Packets Authorization.

Le Single-Packet Authorization

Le Single-Packet Authorization (SPA) s’appuie sur le principe du port-knocking. Le port-knocking consiste à ouvrir un port lorsqu’une séquence d’envoi de paquets sur certains ports est réalisée. Un port est un numéro unique codé sur 16 bits pour indiquer que l’information envoyée ou reçue est destinée à une application en particulier. Le port répond à un besoin de distinguer une information d’une autre pour une même machine ayant la même adresse IP. De cette manière, une connexion en SSH est possible sur le port 22 à un serveur Web pour l’administrer, et l’accès au service web est possible sur le port 80 depuis un navigateur web.

Avec le port-knocking, le service est inaccessible et aucune preuve de son fonctionnement n’est visible tant que la séquence n’a pas été exécutée. Par exemple pour ouvrir le port 22 correspondant au SSH, l’utilisateur doit d’abord envoyer un paquet TCP ou UDP sur le port 800, 400 puis 6523. Un utilisateur qui ne connaît pas la séquence ne peut pas ouvrir le port. De cette manière, le pare-feu a des règles dynamiques avec une politique default-drop. Le pare-feu n’accepte aucune connexion entrante à part celles qui sont déjà établies par défaut et ajoute une règle lorsque la séquence est respectée.

Fonctionnement du Port-Knocking

Le projet open-source fwknop implémente le SPA en suivant le principe du port-knocking pour donner un accès à un ou plusieurs services. La seule différence entre le SPA et le port-knocking est la génération du paquet authentifié et chiffré remplaçant l’usage de l’envoi de paquets sur une séquence de ports spécifiques. De cette manière, le SPA porte les informations permettant d’authentifier l’utilisateur et le terminal contrairement au port-knocking.

Dans ce premier article, nous avons donné une définition du modèle Zero Trust et le contexte historique derrière ses principes. Nous avons ensuite vu les composants d’une architecture Zero Trust et un projet open-source permettant d’implémenter le SPA utilisé par l’architecture Software-Defined Perimeter (SDP).

Dans le prochain article, nous verrons l’importance du SDP et de BeyondCorp dans les solutions ZTNA et nous allons définir les caractéristiques d’une solution ZTNA, cliquez-ici pour consulter le second article.

Références

Jérémy LANOË

Consultant Infrastructure Security

Voir les derniers Cybersecurity Insights

13 novembre 2023
Version révisée (Edition 4) de la norme ISO/CEI 27005 : Almond vous propose un top 3 des changements normatifs et des précisions sur leurs implications directes dans les travaux des Risk Managers au sein des organisations.
19 octobre 2023
C’est ce que tente d’éclairer cet article en explorant les avantages d’une approche ISO 27001 pour structurer les réponses attendues par vos clients dans les questionnaires SSI qu’ils vous transmettent.
16 octobre 2023
L'authentification multi-facteurs, un sujet toujours d'actualité à ne pas négliger !
11 octobre 2023
Chez Almond, nous préconisons de parachever les pratiques de contrôle par une approche par les risques pour améliorer la qualité du portefeuille des fonds d’investissement.
5 octobre 2023
Did you ever imagine that you or your colleagues could be a serious threat to your company? Discover our study: Insider Threat !
29 septembre 2023
Découvrez la solution SASE de Zscaler avec Benoit Vérove, Partner et Lead Security Integration chez Almond et Reda Nedjar, Principal Sales Engineer chez Zscaler au travers d'une démonstration technique au cœur de l'outil Zscaler Zero Trust Exchange™!
16 juin 2023
Le SASE en 7 min chrono : décrypter le SASE, sa fonction et ses usages. Pour y voir plus clair, nous vous proposons d’entrer en immersion dans les plateformes SASE des experts du secteur. Découvrons ensemble, la solution SASE proposée par Cato Networks. Joseph Fernando, SE Manager South EMEA, chez Cato Networks réalise une démonstration technique de la solution Cato SASE Cloud, au côté de Benoit Vérove, Partner et Lead Security Integration chez Almond.
12 juin 2023
Comme chaque année, SWIFT met à jour son standard CSCF et apporte son lot de nouveautés. Nous vous proposons ici quelques clés de lecture associées aux changements fondamentaux apportés par le CSCF v2023
5 juin 2023
Depuis 2021, tous les clients SWIFT se trouvent dans l’obligation de réaliser une évaluation de conformité dans le cadre du Customer Security Program (CSP) de SWIFT.
2 juin 2023
Décryptez la technologie SASE, au travers d'une démonstration technique de la solution Harmony Connect proposée par Check Point.

Jour 4 : Quel type d'attaque peut être qualifié de "triple extorsion" ?

  • Réponse 1 : Une attaque par ransomware
  • Réponse 2 : Une attaque par hameçonnage
  • Réponse 3 : Une attaque par déni de service
  • Réponse 4 : Une attaque par empoisonnement du cache DNS

Pour y répondre, rendez-vous sur notre page Linkedin ! A vos votes !

Jour 3 : Parmi ces quatre choix, lequel définit le mieux ce qu’est l’ISO 27001 ?

  • Réponse 1 : Un standard listant un ensemble d’exigences relatives à la sécurité des systèmes informatiques d’une entreprise
  • Réponse 2 : Une norme listant un ensemble de bonnes pratiques permettant d’optimiser la cybersécurité au sein d’une l’entreprise
  • Réponse 3 : Une norme listant un ensemble d’exigences relatives à la sécurité des informations nécessaires à une entreprise
  • Réponse 4 : Un standard listant un ensemble de méthodes pour optimiser les pratiques relatives à la sécurité des informations utilisées par une entreprise

Laïus explicatif : L’ISO 27001 est une norme internationale, dont les entreprises peuvent se prévaloir en se faisant certifier par un organisme indépendant ; elle contient un ensemble d’exigences que chaque entreprise, quels que soient sa taille et son domaine d’activité, doit impérativement appliquer pour obtenir sa certification ; ses exigences constituent donc le référentiel des audits de certification. A ne pas confondre avec la norme ISO 27002 qui est constituée de recommandations, basées sur les bonnes pratiques internationales, permettant d’aider une entreprise à appliquer les exigences de la norme ISO 27001 (donc norme qui ne donne pas lieu à une certification).

Les exigences de la norme ISO 27001 portent sur les informations nécessaires à une entreprise, recueillies et/ou traitées, quel que soit son support, électronique, papier et oral.

Les trois critères de sécurité retenus par la norme ISO 27001 sont la confidentialité, l’intégrité et la disponibilité des informations. Tout événement, qu’il soit d’origine environnementale ou humaine, intentionnelle ou involontaire, impactant un de ces trois critères, relève de cette norme.

Jour 2 : Qu'est-ce qu'une attaque DDoS?

  • Réponse 1 : Un logiciel espion qui enregistre ce qu’écrit un utilisateur
  • Réponse 2 : Un procédé visant à perturber l’accès à un site ou une application
  • Réponse 3 : Un virus informatique qui chiffre l’OS de votre ordinateur en échange d’une rançon
  • Réponse 4 : Une attaque Informatique visant à détermine votre mot de passe en testant un grand nombre de possibilité

Laïus explicatif : Une attaque DDoS ou « Distributed Denial of Service » est une attaque visant à rendre indisponible un site en le submergeant de requêtes provenant de multiples sources. Dans le cas où toutes les requêtes proviennent de la même source, on parle simplement d’attaque DoS (« Denial of Service »), ou « par déni de service ».

Jour 1 : Qu'est-ce que DORA?

  • Réponse 1 : Une jeune exploratrice bilingue
  • Réponse 2 : Un protocole de communication décrit dans le RFC 9364
  • Réponse 3 : Une organisation internationale de régulation de la cybersécurité
  • Réponse 4 : Un règlement qui s’applique aux entités financières et aux tiers prestataires de services informatiques

Laïus explicatif : DORA ou Digital Operational Resilience Act est un règlement européen publié en 2022 et en vigueur depuis janvier 2023. Le règlement traite de la résilience opérationnelle numérique du secteur financier. Il est applicable aux entités financières comme les banques, assurances, entreprises d’investissement, les établissements de paiement, etc. mais également aux tiers prestataires de services informatiques. Les entreprises concernées ont deux ans pour se mettre en conformité. Ils devront donc l’être en 2025 !

Le pilier relatif à la gestion des risques liés aux prestataires tiers de services TIC apparait comme l’un des plus difficile à mettre en place et à maintenir dans le temps pour les entreprises concernées. En quelques mots, les entreprises devront considérer ces risques comme faisant partie intégrante du risque lié aux technologies de l’information et de la communication (TIC) et notamment le risque de concentration, au niveau de l’entreprise mais également au niveau de l’ensemble du secteur financier européen. En effet, les autorités devront analyser ce risque en analysant les registres tenus et communiqués par les entreprises concernées par DORA et qui recense notamment la liste des tiers prestataires de services TIC avec lesquelles les entités financières conclues des contrats.

Pour plus d’informations, consultez notre avis d’expert sur le sujet : https://almond.eu/cybersecurity-insights/explorons-dora/