Aujourd’hui, les cyber-attaques font partie de notre quotidien et deviennent de plus en plus nombreuses et sophistiquées. 

Par ailleurs, nous évoluons vers des Systèmes d’Information construits sur une diversité d’environnements de plus en plus vaste, notamment grâce au Cloud, maintenant omniprésent dans les SI des entreprises. Cela leur permet d’élargir leurs capacités mais, d’un point de vue sécurité, accroît la surface et les risques d’attaques. 

Des techniques classiques de protection et de détection contre les intrusions existent déjà et se développent de manière exponentielle. Celles-ci sont efficaces pour les attaques les plus courantes mais ne sont bien souvent pas ou peu adaptées aux spécificités du Cloud. 

Ainsi, des questions se posent sur l’utilisation de stratégies proactives, telle que la Deceptive Security, permettant de garder une longueur d’avance sur les attaquants. Notamment dans le cadre de Cyber-Résilience : comment utiliser ce genre de technologie sur des environnements de types traditionnels et Cloud ? 

Dans quels cas utiliser des techniques de Deceptive Security ? Est-ce que les solutions de Deceptive Security dans le Cloud sont développées aujourd’hui ? Y a-t-il des stratégies spécifiques à envisager dans le cadre d’un environnement Cloud comparé au traditionnel ? 

Nous répondrons à ces questions dans une mini-série de 2 articles. Dans le premier article, nous vous montrerons comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présenterons un exemple pratique de sécurité trompeuse dans AWS.

 

Elaborer et évaluer sa stratégie de leurrage 

Ambitions de la Deceptive Security 

La Deceptive Security dans les grandes lignes 

La « Deceptive Security » (désignée par « Deceptive » dans la suite de l’article), ou « leurrage numérique », est une technique de cyberdéfense qui fait face à l’intrusion d’attaquants dans un SI (Système d’Information). Ceci fonctionne grâce à la mise en place de pièges et/ou leurres dans un SI. Ces derniers ont pour objectif d’imiter des technologiques légitimes pour ne pas être repérés. 

Cette méthode permet de détecter des intrusions en générant des alertes, d’empêcher de nuire à l’infrastructure réelle mais aussi d’observer les pratiques utilisées par l’attaquant. 

Avant d’entamer ce sujet dans les détails, il est conseillé de parcourir l’article « Deceptive Security : comment arroser l’arroseur ? » qui décrit les principaux concepts de la « Deceptive Security ». 

Les grands objectifs de la Deceptive 

L’utilisation de la Deceptive sur un SI peut avoir plusieurs objectifs : 

• Détecter une intrusion 
• Distraire l’attaquant 
• Analyser les techniques utilisées lors de l’attaque 

Cette technologie peut être utilisée à différents degrés de maturité et selon les besoins identifiés.  

Effectivement, cette technologie permet de répondre à plusieurs besoins, vus ci-dessus, or, l’objectif est de déterminer en amont nos exigences face à cette technologie. Si on restreint le besoin à de la détection, il faut noter que la configuration, le déploiement et la maintenance de la Deceptive sera bien moins complexe que si on pousse au maximum les possibilités de cette technologie (exemple : mise en place de scénarios complexes pour leurrer l’attaquant et analyse stratégique de ses faits et gestes). 

Les atouts de la Deceptive  

Pourquoi la Deceptive ? 

Comme abordé dans l’introduction, les challenges actuels de cybersécurité sont nourris par le besoin de détection et réaction face à des attaques grandissantes. 

La Deceptive ne remplace pas les solutions de cybersécurité standards existantes. Plus complexe, elle agit en complément pour couvrir tous les types d’attaques, dont les plus sophistiquées. 

Cette technologie n’est pas conçue pour prévenir une attaque, mais pour alerter les équipes de sécurité, minimiser l’effet de l’attaque et observer le modus operandi de l’intrus (« Détecter, Distraire & Analyser »). 

Honeypot VS Honeytoken 

Présentation des termes 

Les leurres peuvent être de nature différente selon le besoin et comment on prévoit de les utiliser. Dans tous les cas, ils prennent l’apparence d’attributs composants notre Système d’Information. 

Les leurres les plus connus sont les « honeypots ». Ce sont des serveurs ou postes de travail qui vont venir imiter des machines réelles sur le réseau. On retrouve également ce qu’on appelle « honeynet » : un ensemble de serveurs rassemblés en réseau.  

Un autre type de leurres intéresse de plus en plus aujourd’hui. C’est un leurre qui vient se cacher directement sur un système. On parle d’abord de « honeyfiles » qui sont généralement représentés par des documents ou autres fichiers qui ont pour rôle de déclencher une alerte lorsque que quelqu’un vient interagir avec eux. Enfin, nous avons les « honeytokens » qui sont des données, informations, souvent des secrets ou clés utilisés pour accéder à une ressource factice sur le SI (un honeypot par exemple). 

Une différence fondamentale 

L’utilisation traditionnelle d’honeypots peut permettre l’observation et la compréhension des actions de l’attaquant en plus de la détection d’une intrusion. La difficulté dans ce cas est de configurer un leurre assez attractif et crédible pour que le cyberattaquant tombe dans le piège, sans pour autant livrer des informations pouvant compromettre un composant de notre réelle infrastructure. 

L’intérêt des honeytokens est que l’on va travailler un leurre plus complexe certes mais plus fin et très crédible, pour ensuite interagir avec le reste de notre piège. Sans les honeytokens, la probabilité que l’on piège un attaquant est plus faible et les résultats d’analyses pas toujours fiables. La dépendance que créer l’honeytoken avec son environnement le rend d’autant plus attractif comparé à un honeypot seul qui ne représente qu’un piège sans possibilité d’escalade par la suite. Pour que les honeypots soient efficaces, il faut recommander le déploiement d’un ou plusieurs honeynets complets, mais le nouveau souci que l’on rencontre ici est le coût d’une telle infrastructure. 

Développement de la technologie dans le Cloud 

Le défi aujourd’hui pour les éditeurs de solutions Deceptive les plus matures, est le développement de services spécifiques dans le Cloud. 

Effectivement, les entreprises utilisent de plus en plus le Cloud pour étendre leur stockage, déployer des machines virtuelles, des conteneurs, etc. Cette mise à disposition de services est très populaire et efficace or, l’intérêt pour les cyberattaquants augmente du même temps. Les templates, ou configurations par défaut facilitent la vie des entreprises mais peuvent augmenter les risques de cybersécurité. Même si de nombreux fournisseurs Cloud évolue beaucoup sur le sujet, les configurations par défaut ne répondent pas toujours aux préconisations de sécurité informatique. 

Le Cloud est donc un nouveau terrain de jeu pour les cyberattaquants. C’est pour cela que l’on s’intéresse aujourd’hui à l’adaptation de nos connaissances de la Deceptive pour également protéger les environnements et services Cloud. 

 

Aperçu des principaux éditeurs sur le marché 

Il faut noter que la Deceptive n’est pas réservée uniquement dans des cas d’usage trop complexes. Il existe aujourd’hui toutes sortes d’offres sur le marché. Certaines proposent des services permettant d’obtenir un outil clé en main complet, alors que d’autres privilégient le sur-mesure, la qualité des leurres et donc plutôt la possibilité d’utiliser leur outil pour créer soi-même ses leurres (configuration et maintenance non gérées par la solution en elle-même). 

Voici un aperçu des principaux éditeurs et leurs solutions :  

 

Pour certains, la tendance actuelle est de s’allier à d’autres outils ou d’intégrer leur solution à des EDR (Endpoint Detection and Response) pour augmenter l’efficacité de la technologie et répondre au besoin du marché. 

Comme exprimé précédemment, le challenge que certains ont choisi de relever est de s’adapter à un environnement Cloud. Par exemple, des solutions comme « Attivo Networks », rachetée par SentinelOne, développent des offres Cloud AWS qui propose la création de leurres en lien avec le service (e.g. : EC2, S3, AWS access keys, etc.). 

 

Comment construire et placer ses leurres ? 

Les stratégies de Deceptive  

Une fois avoir pris connaissance de cette technologie et à toutes les possibilités qu’elle apporte, il devient intéressant de se demander quelle.s stratégie.s adopter quant à la quantité de pièges et/ou leurres à implémenter et à la disposition de ces derniers dans le SI. 

Pour s’adapter aux différents cas d’usages, 3 stratégies se détachent répondant à des besoins distincts : 

Effectivement, la stratégie de Deceptive à adopter est souvent sur-mesure en fonction de l’infrastructure du SI et surtout en fonction des priorités et objectifs définis au préalable. 

À titre d’exemple : Si nous sommes dans le cas d’un besoin d’enrichissement de ses technologies de détection au sein de son SI, il peut être intéressant d’étudier la stratégie de « déploiement en masse » de leurres. Ceci a pour volonté de créer un SI fantôme et, ainsi, augmenter la probabilité que le cybercriminel tombe dans un piège qui déclenchera une alerte à destination des équipes de sécurité. 

La matrice PARCS 

Le challenge lorsque l’on parle de Deceptive, et plus spécifiquement de leurres, est de répondre aux questions : Qu’est-ce qu’un bon leurre ? Comment créer un bon leurre ? Où le placer ? Combien en placer ? etc. 

L’article « HoneyWISE : stratégie d’exploitation d’honeytokens en environnement Active Directory », écrit par Augustin TOURNYOL-DU-CLOS et Nathan FAEDDA, propose une stratégie de leurrage contre certaines attaques dans un contexte précis : l’AD (Active Directory). Nous aborderons également le sujet des honeytokens, mis en comparaison avec les honeypots, dans la suite de cet article. 

Les objectifs de cette étude étaient de tester simplement l’implémentation de leurres au sein de l’AD et de mesurer leur efficacité grâce à la matrice « PARCS ». 

PARCS est ainsi née sur la base de 5 critères, pensée à l’origine dans le contexte d’un environnement AD mais applicable à tous les environnements :  

Lors du processus de réalisation d’un leurre, il est conseillé de préparer un PARCS pour vérifier sa réflexion et valider que celui-ci correspond à nos attentes. Il faut également penser aux besoins minimums illustrés par ces 5 critères : Pertinence, Risque, Crédibilité, Attractivité et Scalabilité. 

À travers cette matrice, l’objectif est d’estimer un besoin pour ensuite déterminer une balance d’importance et de priorité sur ces critères (Est-ce que l’attractivité du leurre a de l’importance dans mon cas d’usage ? Est-ce que j’ai besoin d’une solution scalable ? À quel point ? etc.).  

Exemple de l’utilisation de PARCS : scenario Kerberoasting « Voler ou falsifier des tickets Kerberos » 

Le plus parlant est surement d’illustrer la présentation de la matrice PARCS avec un exemple exposé dans l’article « HoneyWISE ». 

L’attaque de l’AD appelée Kerberoasting est, « […] en synthèse, le brute force offline (pas d’échec de logon) d’un ticket Kerberos recevant le secret d’un compte de service, sans devoir envoyer un seul paquet à ce service ni même être administrateur local du poste compromis ». 

Le « […] Kerberoasting détourne le fonctionnement natif de Kerberos afin de réaliser une attaque. Ce détournement se fait sur les étapes 3 et 4 de l’authentification Kerberos présentées par le schéma suivant : » 

Pour ce cas d’attaque, Augustin TOURNYOL-DU-CLOS et Nathan FAEDDA proposent dans leur article de déployer un honeytoken contre le Kerberoasting (voir partie 2.3 « Description des scénarios de détection » – scénario 2). 

Voici le résultat, à travers PARCS, de l’étude de ce type d’honeytoken dans le cadre d’un scénario de Kerberoasting (16/20) : 

 

• Pertinence : 4/4 
  • « Les alertes générées par ce honeytoken sont fiables. En effet, à partir du moment où un ticket TGS est demandé pour accéder à service non-utilisé et inexistant, il apparait clairement qu’une action malveillante est en cours. » 
• Attractivité : 3/4 
  • « L’attractivité de ce token repose dans le fait que la réalisation de l’attaque ne nécessite pas de privilèges et permet potentiellement d’en gagner tout en étant silencieuse (génération de trafic jugé légitime). Sous réserve que le compte choisi pour leurrer l’attaquant paraisse privilégié et géré par un utilisateur (afin que le mot de passe soit vraisemblablement simple) ce honeytoken est donc fortement attractif. » 
• Risque : 4/4 
  • « Dans notre exemple un mot de passe de 64 caractères a été défini ce qui n’est pas cassable dans un temps raisonnable. » 
• Crédibilité : 3/4 
  • « Sous réserve du choix du nom et des attributs du compte en fonction du contexte de production dans lequel il est déployé, l’attaque se basant sur un fonctionnement normal de Kerberos, il ne sera pas étonnant de pouvoir la réaliser. La crédibilité est donc forte. » 
• Scalabilité : 2/4 
  • « Le déploiement du compte de leurrage peut se faire automatiquement sur plusieurs domaines grâce à des scripts. Néanmoins pour un leurre efficace, la contextualisation reste primordiale et constituera l’obstacle majeur à un déploiement de masse efficace. Il faudra donc prendre en compte le coût d’apporter cette contextualisation et de la maintenir à jour. » 

 

Pour conclure, les solutions de Deceptive Security sont à étudier au cas par cas. Il est impératif d’avoir déterminé au préalable les objectifs à prioriser, la stratégie à adopter, le périmètre concerné etc. 

Dans certains cas d’usage, surtout pour les entreprises ayant une sécurité informatique déjà mature, il est pertinent de mettre en place des solutions du type Deceptive Security. Ceci est à appliquer en complément d’outils de sécurité standards minimums tels que les firewalls, les antivirus, les systèmes de détection et/ou de prévention d’intrusion,… L’objectif étant de couvrir tous les types de cyberattaques (type « 0-day », sans pattern connu).  

Cette technologie peut être difficile à mettre en œuvre pour les entreprises de petite taille car elles n’ont pas forcément les outils de sécurité essentiels mis en place par défaut et ne disposent pas des ressources nécessaires pour configurer (ex : designer les leurres, créer les stratégies et scénarios) et maintenir une telle solution (ex : équipes de maintenance dédiées). 

Aujourd’hui, le marché est en expansion, principalement sur les sujets de détection grâce à la Deceptive, mais pas uniquement. L’intérêt des éditeurs à construire des solutions de Deceptive est cependant centré, pour le moment, sur les environnements traditionnels. Les solutions pour le Cloud AWS, Azure, etc., sont encore peu développées.   

 

 

 

Merci à Augustin TOURNYOL DU CLOS pour sa contribution à cet article.