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 montrions comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présentons un exemple pratique de sécurité trompeuse dans AWS. 

Postulats initiaux et choix du scenario  

Grâce à l’expertise Wavestone et aux ressources partagées par notre CyberLab, nous avons conçu un scénario simple pour illustrer l’utilisation de leurres en environnement Cloud AWS. L’exemple détaillé dans la suite est inspiré par un scénario CTF (Capture The Flag) dessiné par l’équipe du CyberLab pour illustrer la propagation latérale d’un attaquant. 

De même manière que dans les scénarios traités précédemment, où nous utilisions la Deceptive pour la détection d’attaquants déjà introduits au sein du SI, il s’agit encore une fois d’éviter d’attirer des attaquants opportunistes sur notre réseau dans une optique de Deceptive « de recherche ». Ainsi, nous postulons une infection initiale quelconque, fortement probable (à fortiori dans des environnements Cloud peu maitrisés), et nous concentrons sur la détection de l’intrus en cours de déploiement sur le réseau. 

L’application de cette démarche à un environnement AWS n’est pas innocent. Un des apports du Cloud repose en effet dans la gestion des identités simplifiée et la délégation aisée des accès, mais cet atout peut toutefois tourner à l’avantage d’attaquants en cas d’exposition involontaire de ressources ou de création de liens dangereux entre zones de niveau de sécurité différents. Les mesures de durcissement et de prévention ne manquent pas et sont généreusement promues par les fournisseurs Cloud eux-mêmes mais ces vulnérabilités demeurent le lot des comptes et souscriptions peu durcis, dont l’administration obéit trop souvent à des règles encore informelles.  

Le scénario d’attaque et de leurrage associé reposera donc sur ce principe de liaison entre deux comptes AWS, ici conçus comme un environnement de production et un autre de développement, moins critique. Nous nous placerons dans un scénario où une relation d’approbation permet de se propager depuis le compte de développement vers le compte de production, via l’endossement d’un rôle cross-account.  

Scénario de leurrage 

Description du scénario  

Partons de l’idée selon laquelle un utilisateur non autorisé a obtenu des accès sur une machine EC2 (domainIntegrated-EC2) au sein du compte de test (infection initiale). Après une première connexion réussie, il tente d’accéder à des ressources couramment utilisées telles que Amazon Simple Storage Service (Amazon S3) ou essaye d’élever ses privilèges en assumant d’autres rôles (rôle chaining) liés au rôle auquel il a accès. 

Ce scénario de propagation latérale est une technique d’attaque courante dans les environnements Cloud en raison de la nature de leur architecture et du modèle de responsabilité du cloud computing, où le client est responsable de la sécurisation de ses applications, de ses données et du contrôle d’accès (alors que le fournisseur veille à la sécurité de l’infrastructure sous-jacente). 

Tel qu’illustré ci-dessous, les attaques de propagation latérale tirent parti des faiblesses des contrôles de sécurité du client, telles que des autorisations mal configurées ou l’application de mécanismes d’authentification trop faibles, pour obtenir un accès non autorisé à d’autres ressources dans l’environnement. 

Scénario du point de vue de l’attaquant 

0. Après avoir compromis une machine EC2 « domainIntegrated », l’attaquant s’aperçoit qu’un rôle lui est associé (« Semi-Admin-role ») : 

Enumération de la machine EC2 domainIntegrated 

Il énumère ensuite les droits du rôle « Semi-Admin-Role » :  

Enumération des droits du rôle Semi-Admin-Role 

Tout d’abord ce rôle a des privilèges de modification sur une ressource du compte « AWS – SHARED » : il peut en effet endosser (sts :assumeRole) et modifier (iam :UpdateRole) un rôle intitulé « LambdaAuto ». Il peut ensuite endosser (par « role chaining », étape 5 du schéma ci-dessus) un autre rôle nommé « SecurityAudit» dans un compte différent, intitulé AWS MASTER. 

L’attaquant réalise par ailleurs qu’il peut également assumer directement un autre rôle (« IAM-RO-Role ») du compte AWS – MASTER. Ce dernier rôle attire particulièrement son attention car le compte MASTER suggère par son nom un périmètre d’action bien plus important que le simple compte SHARED, et le rôle IAM-RO-Role évoque un périmètre de vision étendu sur les ressources de ce compte. 

1. L’attaquant endosse le « SemiAdmin-role » qui lui permet par la suite d’assumer le rôle « IAM-RO » et tenter d’autres actions qui lui permettront de bien analyser son champ de vision. 
2. En effet, après avoir assumé le rôle « IAM-RO », il procède à une énumération de l’IAM où il s’aperçoit des rôles et des utilisateurs dans son champ de vision :  

Liste des rôles dans le champ de vision du rôle IAM-RO 

Liste des utilisateurs dans le champ de vision du rôle IAM-RO 

Le rôle « SecurityAudit » attire particulièrement son attention grâce aux privilèges que ce nom suggère et la description du rôle qui donne des informations sur lesdits privilèges : 

Description du rôle SecurityAudit 

Toutefois, l’attaquant n’a qu’un accès en lecture sur les ressources listées. Il va donc chercher si certaines de ces ressources sont accessibles en écriture depuis le compte SHARED où il a de hauts privilèges. Par exemple, si certains rôles du comptes MASTER peuvent être endossés par des rôles du compte SHARED : 

Liste des rôles pouvant être assumés depuis un compte externe (ici le compte SHARED) 

L’attaquant investigue la relation d’approbation du rôle « SecurityAudit », qui justement, autorise un endossement par le rôle « LambdaAuto » du compte SHARED. 

3. De retour sur le compte SHARED, l’attaquant n’a plus qu’à vérifier que l’autre pendant de cette relation d’approbation, c’est-à-dire que le rôle « LambdaAuto » autorise bien dans sa politique d’approbation l’endossement du rôle « SecurityAudit ». Ce n’est pas le cas, mais le rôle « SemiAdminRole » lui permet de configurer cette autorisation. 

4. Une fois la politique d’approbation du rôle « LambdaAuto » modifiée, il peut maintenant assumer le rôle « LambdaAuto ». 

5. Puis, il endosse (par role-chaining) le rôle « SecurityAudit », le véritable leurre. 

Role chaining de l’attaquant 

Après sa tentative d’endossement du rôle « SecurityAudit » dont il espère les privilèges d’auditeur sécurité (annoncés en étape 1), l’attaquant se retrouve en réalité sans réels pouvoirs, par exemple : 

Exemple d’un accès refusé depuis le rôle SecurityAudit 

Création des leurres  

Le schéma ci-dessous révèle à présent les ajouts de leurres aux différentes étapes de l’attaque et leur configuration par le défenseur : 

Scénario du point de vue du défenseur 

0. Le rôle « Semi-Admin-Role » est le point d’entrée dans le scenario de leurrage. Il peut donc être associé à toute ressource susceptible d’être compromise (ici l’EC2 « domainIntegrated ») pour rediriger l’attaquant vers les leurres.  

Aucune alerte n’est configurée à ce niveau car la connexion du rôle Semi-Admin-Rôle à l’ensemble des ressources du compte SHARED rend probable le déclenchement d’un endossement involontaire et, par suite, d’alertes faussement positives. 

1. Une fois le rôle IAM-RO assumé, l’attaquant est donc invité dans un compte entièrement dédié au leurrage et se familiarise avec les ressources alentour, obtenant ainsi une vue d’ensemble complète de tous les rôles et utilisateurs du compte. 

2. En peuplant le champ de vision de l’attaquant, non seulement avec le leurre principal « SecurityAudit », mais également avec d’autres rôles et utilisateurs factices, nous nous assurons que l’aspect du compte semble crédible et que notre leurre-clé, le rôle SecurityAudit ne soit pas isolé. 

Nous ajoutons ainsi au sein du compte :  

• Des Users : différents noms d’utilisateurs attrayants pour l’attaquant.  
• Le rôle « LambdaFunction » : ce rôle est créé pour la simulation d’une fonction Lambda qui fait appel aux services AWS. 
• Le rôle « LogsAndS3Bucket » : un rôle créé avec objectif de faciliter l’accès aux services de journalisation et aux ressources de stockage S3 au sein du compte. 
• Le rôles « taskExecutionRole » : le rôle d’exécution des tâches pouvant être utilisé pour différents objectifs et services associés au compte. 

3. Le rôle « SemiAdminRole » a volontairement été configuré avec la permission (iam :UpdateRole) sur le rôle « LambdaAuto » lui permettant de modifier ce rôle et donc d’ajouter la relation d’approbation vers le rôle « SemiAdminRole ». Pour des raisons de surveillance, une première alerte peut être déclenchée à ce niveau lors de la mise à jour de la relation d’approbation de « LambdaAuto » permettant au « SemiAdminRole » de l’assumer. 

4. Le rôle « LambdaAuto » est créé volontairement comme la porte d’entrée vers le rôle « SecurityAudit », une fois sa relation d’approbation modifiée grâce aux privilèges du rôle « SeminAdminRole ». 

5. Le rôle « SecurityAudit » est volontairement configuré avec une relation d’approbation autorisant le rôle « LambdaAuto » du compte SHARED à l’assumer. 

6. A cette étape, l’attaquant avait supposé qu’il obtiendrait des droits d’auditeur de sécurité. Cependant, une politique de contrôle de sécurité (SCP) très restrictive a été appliquée, ne lui accordant aucun privilège sur le compte. 

La politique interdisant toutes actions depuis le rôle Security-Audit-Role 

Chaîne d’alerting 

Une chaîne d’alerting dans le cloud AWS fait référence à un moyen de communiquer des notifications ou des alertes générées par les services AWS aux utilisateurs ou aux équipes responsables de la gestion de ces services, leur permettant de prendre des mesures rapides pour résoudre les problèmes et minimiser les interruptions de service.  

Pour configurer une chaîne d’alerting, vous devez d’abord configurer les services AWS pour générer des alertes lorsque certains événements se produisent, comme un serveur en panne ou une application dépassant un seuil spécifique d’utilisation du processeur. Une fois ces alertes générées, elles peuvent être envoyées à la chaîne d’alerting appropriée en fonction des préférences de notification configurées par l’utilisateur ou l’équipe responsable de la gestion du service. 

Afin de détecter l’attaquant, nous utilisons les services AWS suivants pour créer la chaine d’alerting : 

• CloudTrail pour traquer les actions réalisées sur le compte AWS compromis ; 
• EventBridge pour détecter tout événement « AssumeRole » du rôle « SecurityAudit » et déclencher une alerte ; 
• Simple Notification Service (SNS) pour envoyer l’alerte par e-mail avec les informations recueillies lors de l’attaque. 

Illustration de la chaîne d’alerting 

Etapes de création de la chaîne d’alerting : 

Configuration de CloudTrail 

La première étape de la création d’une chaîne d’alerting sur AWS consiste à activer CloudTrail (s’il n’est pas activé) dans votre compte AWS. CloudTrail enregistre toutes les activités et calls API dans votre compte, ce qui peut être utile à des fins de sécurité, de conformité et de dépannage.  

Partant des logs générés dans CloudTrail, nous avons créé une règle EventBridge qui envoie des notifications au service SNS chaque fois que le rôle « SecurityAudit » est assumé (type d’événement : AssumeRole). 

Création d’une règle EventBridge 

Une règle permet de surveiller des types d’événements spécifiques et lorsqu’un événement correspondant se produit, il est routé vers le service associé à la règle et traitant l’événement (ici le service SNS). 

Le modèle d’événement permet de détecter tous les événements du type « AssumeRole » se produisant dans le compte utilisé et déclencher l’alerte. Afin d’éviter les faux positifs lors du déclenchement des alertes, nous avons affinés le modèle d’événement pour qu’il soit aussi précis que possible pour correspondre aux événements qui nous intéressent.  

De ce fait, il sied d’inclure des champs pertinents, tels que la source de l’événement, le type de détail ou des valeurs spécifiques, pour affiner les critères de correspondance. Cela permet de réduire les risques que des événements non liés déclenchent la règle. 

Le modèle d’événement détectant tous les événements « AssumeRole » sur le rôle « SecurityAudit » 

Le service Eventbridge doit donc être préalablement lié à la cible SNS.  

La cible liée à la règle EventBridge 

Configuration d’une rubrique SNS 

A cette étape, une rubrique SNS est créée et liée à un abonnement d’un point de terminaison par mail authentifié par la suite. Le sujet SNS sera la cible de la règle EventBridge. Après la création du sujet, on procède à l’abonnement par e-mail en sélectionnant l’adresse de messagerie comme protocole (point de terminaison) où on souhaite recevoir les alertes. 

On pourrait envisager d’autres cible que mail pour la réception de l’alerte (ServiceNow, SIEM, etc…). 

Détails de la rubrique SNS 

Personnalisation de l’alerte 

Afin de personnaliser le contenu de l’alerte et de n’afficher que les éléments importants recherchés, la fonction Transformateur d’entrée d’EventBridge a été utilisée.  

Elle permet de personnaliser le texte d’un événement avant qu’il ne soit transmis à la cible.  Pour ce faire, il sied de définir des variables JSON pour référencer des valeurs dans la source d’événement d’origine. 

Configuration du transformateur d’entrées 

Pour notre cas, les variables répertoriées ci-dessous constitueront le message de l’alerte : 

Création du transformateur d’entrée 

Modèle d’entrée 

Le modèle d’entrée va utiliser les variables définies précédemment au sein du message d’alerte final :  

 Création du modèle d’entrée 

Ainsi, après endossement du rôle « SecurityAudit », une alerte est envoyée au point de terminaison créé : 

Exemple du contenu de l’alerte par mail 

Coût des services AWS utilisés 

AWS offre une approche de paiement à l’utilisation pour la tarification de ses services cloud. Avec AWS, vous ne payez que les services dont vous avez besoin, tant que vous continuez à les utiliser et ce, sans contrat à long terme. Vous ne payez que les services que vous utilisez, et si vous cessez de vous en servir, aucun coût additionnel ou frais de résiliation ne vous sera facturé. 

Les services déployés dans le cadre de ce scénario n’ont pas vocation à être utilisé sauf dans le cas d’une intrusion donc d’un incident de sécurité. Les coûts associés sont donc négligeables. 

Evaluation du leurre avec la matrice PARCS 

Plusieurs critères permettent d’évaluer un leurre et voici les résultats de notre analyse au regard de la matrice PARCS : 

• Pertinence : 4/4 

« Diverses approches peuvent être adoptées pour efficacement repérer la compromission initiale d’une instance EC2 et la propagation latérale d’un attaquant Dans notre contexte, selon les ressources à notre disposition, une stratégie envisageable consiste à surveiller les opérations en analysant les journaux, ce qui permettra de détecter des actions malveillantes. Ces observations pourraient ensuite être utilisées pour générer des alertes destinées aux administrateurs. Par exemple, une alerte pourrait être déclenchée en cas de tentative d’intrusion via une attaque de force brute sur le service RDP des instances EC2 au sein de notre environnement AWS, grâce à GuardDuty. 

De plus, il serait possible d’utiliser une combinaison de services AWS tels que CloudTrail et EventBridge pour établir des règles de détection et d’automatisation des interventions en réponse à des activités spécifiques, notamment celles liées aux accès entre comptes (cross-account) et créer des règles de détection qui surveillent tous les événements d’endossement afin de déclencher les actions en cas d’événements correspondant.» 

• Attractivité : 4/4 

« Le leurre se distingue par un compte dédié, augmentant ainsi de manière significative son pouvoir d’attraction. En ayant accès aux métadonnées de toutes les ressources à sa portée, l’attaquant peut également vérifier divers niveaux de privilèges ce qui renforce substantiellement la crédibilité. Grâce à la capacité de visualiser les dates et heures des dernières utilisations des ressources dans son champ de vision, il peut en déduire que ces ressources sont rarement utilisées. Dans cette optique, une fonction lambda est mise en œuvre pour automatiser l’exécution de différentes ressources ou leur authentification, garantissant ainsi des preuves d’utilisation récentes. » 

• Risqué : 4/4 

« L’autorisation accordée au rôle IAM-RO ne confère des privilèges IAM à l’attaquant que dans le contexte d’un compte purement fictif. Grâce à une configuration appropriée de la SCP en amont, toutes les tentatives d’actions du rôle Security-Audit seront également contrées. Les seuls éléments délibérément introduits dans un environnement réel sont les rôles Semi-Admin et Lambda-Auto, qui sont soumis à des politiques rigoureuses empêchant toute attribution de droits ou de privilèges en cas de tentative d’utilisation malveillante. Ces politiques incluent un accès en lecture seule (IAMReadOnlyAccess) et une restriction empêchant toute modification des autorisations liées au rôle du compte, tel que défini par la SCP. » 

• Crédibilité : 3/4 

« La crédibilité du leurre peut être remise en question en raison des ressources disponibles à sa disposition et des limitations potentielles, notamment une Inline Policy qui restreint les autorisations et les actions possibles. Il est important de prendre en compte ces éléments, car ils peuvent susciter des doutes chez les attaquants et compromettre l’efficacité du leurre. Il est donc crucial de mettre en place des mesures qui rendent le leurre aussi réaliste et convaincant que possible, en veillant à ce qu’il ait accès aux ressources et aux autorisations pertinentes pour créer un scénario crédible. » 

• Scalabilité : 3/4 

« En fonction de la taille d’une infrastructure, il devient envisageable de mettre en place un déploiement et une maintenance fluides des composants, grâce à l’emploi de scripts automatisés habilités à exécuter des opérations sur les ressources. Toutefois, il est essentiel de garantir une surveillance minutieuse de l’intégralité des ressources afin de consolider la sécurité face à d’éventuelles atteintes et d’assurer une réaction rapide pour défendre un périmètre étendu. » 

En conclusion, la mise en œuvre d’un tel scénario de Deceptive Security dans le Cloud, offre une approche pour améliorer sa sécurité globale. Cela contribue à restreindre la capacité d’un attaquant à explorer et à se propager à travers le réseau en présentant des chemins trompeurs, en retardant leur progression et en permettant une détection et des réponses plus rapides. Les leurres, qui ressemblent à des cibles attrayantes, détournent l’attention et les ressources des attaquants des véritables actifs, ce qui accroît les chances de détection précoce. 

De plus, les mécanismes d’alerte jouent un rôle crucial en fournissant des informations rapides sur les intrusions potentielles aux équipes de sécurité, ce qui permet une réponse rapide aux incidents et limite l’impact des attaques. 

En combinant ces stratégies de défense, on renforce la posture de sécurité globale des environnements Cloud, on améliore leur résilience face aux cybermenaces en constante évolution et on garantit l’intégrité et la confidentialité des données sensibles.  

En utilisant ces mesures de sécurité trompeuses, les entreprises peuvent renforcer leur défense contre les cyberattaques. Toutefois, il est important de noter que la Deceptive Security ne remplace pas les solutions de cybersécurité standard existantes et que la protection contre les cyberattaques nécessite l’utilisation de techniques de sécurité complémentaires pour une défense optimale. 

ANNEXES – Services AWS 

Les définitions suivantes sont issues de la source : AWS documentation → docs.aws.amazon.com. 

 SCP – Politiques de contrôle de services : Les politiques de contrôle de services sont un type de politique permettant de contrôler de manière centrale les autorisations. Cela permet de veiller à ce que les grandes directives soient respecter pour tous les comptes AWS de l’organisation. 

EC2 – Elastic Compute Cloud : AWS EC2 permet de louer des serveurs (des instances EC2) pour répondre au mieux aux besoins de la charge de travail. 

STS – Security Token Service : AWS STS permet de demander des informations d’identification de sécurité temporaires pour les ressources AWS. Cela permet d’attribuer un accès temporaire aux ressources via des appels API, la console AWS ou le CLI (Console Line Interface) AWS. 

À noter : Chaque jeton STS possède un cycle de vie, défini lors de la création de celui-ci, pouvant aller entre 15 minutes et 36 heures. 

CloudTrail : AWS CloudTrail est un service qui enregistre les actions effectuées par un utilisateur, un rôle ou un service AWS. 

Fonction Lambda : La fonction Lambda est un service permettant d’exécuter du code. 

SNS – Simple Notification Service : Amazon SNS est un service web permettant de gérer l’envoi de messages (SMS, e-mails, HTTP.S, etc.). 

Merci à Charles BULABULA pour sa contribution à cet article. 

Cet article Deceptive Security : la solution pour une détection efficace dans le Cloud ? – Exemple d’application de la Deceptive dans le Cloud AWS  est apparu en premier sur RiskInsight.

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.

Cet article Deceptive Security : la solution pour une détection efficace dans le Cloud ? – Stratégie de leurrage est apparu en premier sur RiskInsight.

Compléter la détection avec de nouvelles approches

Raisonner identité pour détecter les comportements suspects : UEBA

Les technologies UEBA (pour User and Entity Behavioral Analysis), précédemment appelées UBA, sont parmi les derniers nés des outils venant compléter l’arsenal de détection des SOC. Comme leur nom l’indique, leur approche est claire : faire abstraction des considérations techniques des solutions actuelles (SIEM…) en analysant le comportement des utilisateurs et des entités (comprendre terminaux, applications, réseaux, serveurs, objets connectés…).

Le principe est simple, mais son implémentation l’est beaucoup moins. En effet, pour être efficace, les dispositifs UEBA ont besoin de sources nombreuses, avec des formats de données variés. Les sources traditionnelles, telles que le SIEM et le(s) gestionnaire(s) de logs, mais aussi directement certaines ressources (AD, proxy, BDD…) sont souvent utilisées.

Mais afin de parfaire la détection, les solutions UEBA interrogent aussi de nouvelles sources : informations sur les utilisateurs (applications RH, gestion des badges…), échanges entre employés (chats, échanges vidéo, emails…), ou toute autre contribution pertinente (applications métiers à surveiller…).

À partir de toutes ces informations, les solutions UEBA analysent les comportements des utilisateurs (et entités) pour identifier de potentielles menaces. Elles peuvent utiliser des règles statiques, sous forme de signatures à détecter (souvent déjà implémentées dans les solutions SIEM) : connexions simultanées depuis deux endroits différents ou hors des plages horaires classiques…

Mais la véritable force des UEBA réside dans l’utilisation d’algorithmes de Machine Learning pour détecter des modifications du comportement d’utilisateurs ou services : opération métier suspecte, accès à des applications critiques jamais utilisées auparavant lors de congés, transferts de données inhabituels…

Si, à l’origine, les UEBA étaient pensés pour lutter contre les fraudes, leur rôle s’est cependant peu à peu élargi pour couvrir certains périmètres posant habituellement des problèmes aux SIEM : vols de données, compromission -ou prêt- de comptes applicatifs, infection de terminaux ou serveurs, abus de privilèges…

Ainsi, les UEBA se positionnent aujourd’hui en compléments des SIEM, en complétant l’approche « technique » par une vision « utilisateur », et en ajoutant une couche d’intelligence supplémentaire dans l’analyse.

Au vu du marché, il probable que les solutions UEBA cessent d’exister en tant que telles dans les années à venir et s’intègrent à des solutions existantes (SIEM, EDR…), passant de produits à fonctionnalités.

Exemples d’éditeurs UEBA :

Piéger les attaquants : Deceptive Security

La Deceptive Security peut être considérée comme un passage au niveau supérieur des Honey Pots. Des leurres, sous formes de données, d’agents ou d’environnements dédiés, sont répartis à grande échelle dans tout ou partie du SI.

Selon les solutions et les besoins, les outils de Deceptive Security peuvent poursuivre deux buts. En détournant l’attention des attaquants des vraies ressources et en les dirigeants vers de fausses pistes, ils peuvent agir comme moyens de protection.

Mais surtout, la surveillance de ces leurres peut permettre de détecter des menaces se propageant au sein du SI. En effet, ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants ou de divulguer de fausses informations, toute communication avec l’un d’entre eux est nécessairement suspecte.

Ce type de solution ne remplace par les solutions existantes, mais répond à des cas d’usage bien spécifiques, pour lesquels les dispositifs de détection classiques sont peu efficaces : les APT, spécialement conçus pour les contourner, et plus largement les mouvements horizontaux au sein du SI.

Pour plus de détails sur les solutions de Deceptive Security, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs Deceptive Security :

Détecter les signaux faibles sur le réseau : sondes « Machine Learning »

Les sondes de détection classiques (IDPS), basées sur l’analyse de trafic et la comparaison avec des signatures d’attaques connues, sont peu efficaces lorsqu’il s’agit de détecter des menaces subtiles (APT…) ou inconnues (0 days…). Pour pallier ce problème, les IDPS nouvelles générations intègrent des capacités de Machine Learning (parfois présenté comme de l’Intelligence Artificielle) dans leur arsenal de détection.

Selon les solutions, deux types d’usage du Machine Learning sont à distinguer. D’une part, l’utilisation de ces algorithmes en mode supervisé, pour apprendre à reconnaître le comportement de certaines attaques ou phases d’attaque lors de leur phase active : commande & contrôle, scans, mouvements latéraux, fuite de données…

Une fois la sonde déployée, l’ajustement des seuils de détection au contexte client est lui aussi basé sur des algorithmes de Machine Learning (comme le font déjà bon nombre de solutions IDPS classiques).

Ce mode de fonctionnement permet un déploiement rapide (solution utilisable out-of-the-box et phase d’apprentissage écourtée), et une meilleure capacité à détecter les attaques caractérisées précédemment. En contrepartie, la détection des attaques non couvertes par l’apprentissage ou complètement inconnues restent difficiles.

A l’opposé de cette approche, des solutions misent sur l’apprentissage non-supervisé pour détecter les attaques. Pour cela, lors du déploiement, les sondes sont positionnées sur le réseau pour observer le trafic, et apprendre à reconnaître le trafic légitime.

Une fois la phase d’apprentissage terminée, les sondes sont capables de détecter des anomalies, et donc de lever des alertes en cas de comportement suspect. Cette approche permet de détecter des attaques inconnues, mais nécessitent généralement une phase d’apprentissage plus longue pour être efficace et atteindre un taux de fausses alertes acceptables.

Dans les deux cas, les sondes « Machine Learning » permettent de compléter l’arsenal des SOC, aujourd’hui majoritairement destiné à détecter des attaques connues, par des capacités de détection capables de distinguer des attaques complexes, méconnues, ou créés pour contourner les dispositifs de sécurité classiques.

Nos premiers retours terrains montrent que ces technologies peuvent en effet détecter des menaces passant au travers des dispositifs de sécurité classiques. Les faux positifs sont cependant très fréquents (la courbe d’apprentissage variant grandement selon les solutions et les contextes), et il reste difficile de juger de l’exhaustivité des menaces détectées.

Les sondes « Machine Learning » ont donc un avenir certain parmi les outils du SOC, même si un gain en maturité reste à réaliser pour qu’elles atteignent leur plein potentiel.

Exemples d’éditeurs de sondes ML :

Pour retrouver notre troisième et dernier article sur cette saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (2/3) est apparu en premier sur RiskInsight.

Aux origines : les Honeypots

Le principe de Deceptive Security est basé sur l’utilisation de Security Decoys (ou « leurres » en français), inspirés des Honeypots (pots de miel). Le principe est simple : des leurres sont répartis aux points stratégiques du SI et toute activité y est tracée. Ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants, toute communication avec l’un d’entre eux est nécessairement suspecte. Leur analyse permet donc de détecter et d’étudier de potentielles menaces.

Aujourd’hui, les Honeypots demeurent peu répandus, les principaux cas d’usage restant cantonnés à des cas de recherche ou de récupération d’informations (notamment de Threat Intel). Ainsi, des « pots de miel » sont exposés publiquement afin d’observer le trafic reçu sur Internet, et d’en extraire des informations : observation de nouvelles menaces (ransomware, chevaux de Troie…), identification d’IP suspectes ou compromises (SPAM, botnet…) … On peut cependant noter le regain d’intérêt pour les honeypots suite à l’attaque WannaCry, pendant laquelle nombre d’entre eux ont été utilisés pour récupérer et analyser le ransomware.

Dans les SI des entreprises, leur utilisation est encore plus marginale, et – en plus des cas cités précédemment – majoritairement limitée à des besoins bien spécifiques de gestion de crise ou de réponse à incident. Dans ces cas, les Honeypots sont utilisés pour contenir la menace dans un périmètre défini (afin de protéger les ressources critiques), étudier son comportement et en déduire son objectif.

Ainsi, aujourd’hui, les Honeypots sont principalement utilisés dans des buts d’observation et de compréhension de la menace.

Les difficultés que les Honeypots rencontrent pour se démocratiser reposent principalement sur deux limites : ceux-ci sont généralement trop facilement détectés par les attaquants, et le passage à l’échelle d’un SI relève de l’impossible, notamment par manque d’industrialisation des solutions.

Suivre le rythme : wider, faster, stealthier

Le principe de Deceptive Security vise justement à adresser ces deux problématiques, et repose sur la capacité à déployer des leurres de manière industrielle et sur des périmètres étendus. Le déploiement de ces honeypots peut être réalisé de deux façons : par le déploiement d’environnements leurres dédiés, ou par l’ajout de leurres (agents…) installés sur des environnements existants (serveurs de production, de transfert de fichier…). La stratégie de certaines solutions de Deceptive Security repose sur le déploiement de leurres à une échelle telle que ceux-ci créent un « second SI » dans le SI (ou une partie de celui-ci), similaire à une toile d’araignée dans laquelle l’attaquant vient s’emmêler.

Même si cette industrialisation représente un progrès majeur en soi, ce qui justifie la création d’une nouvelle catégorie d’outils (plutôt que de parler de simple évolution), c’est surtout la capacité à mieux dissimuler les leurres. Terminés les serveurs vulnérables avec des mots de passe par défaut : le piège est évident, l’attaquant n’y croit plus. Aujourd’hui, les solutions de Deceptive Security les plus avancées racontent une histoire à l’attaquant afin de le guider peu à peu vers leurs pièges.

La recette : remonter les miettes jusqu’au pot de miel

Pour cela, des informations (généralement appelées « miettes ») sont disséminées sur les environnements existants : serveurs de productions, AD… Bien entendu, l’industrialisation du déploiement de ces miettes est lui aussi un des enjeux principaux mis en avant par les solutions les plus avancées. Une miette représente un brin d’information : la mention d’un serveur hébergeant un middleware obsolète, des identifiants de connexion à un serveur, l’existence d’un compte possédant des droits d’administration…

Selon les solutions, ces miettes peuvent poursuivre deux buts distincts. Elles peuvent être utilisées comme un mécanisme de protection, en guidant les attaquants vers de fausses pistes, ralentissant leur progression et les encourageant à jeter l’éponge et à changer de cible.

Mais surtout, elles peuvent aussi permettre la détection des attaquants. Dans ce cas, chacune des miettes représente un indice, que les attaquants peuvent récolter en explorant les différentes ressources du réseau. Une fois récoltés, interprétés et corrélés, ces indices guident petit à petit les attaquants vers des leurres. Et c’est ici qu’est le réel enjeu, et la rupture par rapport au positionnement classique, de la Deceptive Security : comment créer des scénarios plausibles -et variés- pour piéger les attaquants ?

Ainsi, là où les Honeypots se contentent de circonscrire l’attaquant dans un périmètre défini afin de comprendre le fonctionnement et l’objectif de l’attaque, les Security Decoys visent à être déployés sur un maximum de ressources, afin d’augmenter les chances de détection, et doivent donc savoir rester discrets.

Une fois le contact avec le leurre établi, l’attaquant est repéré. Son comportement peut être alors étudié ou son accès bloqué. Dans les cas les plus poussés, de fausses informations peuvent aussi être mises à disposition pour exfiltration, permettant de faire croire à l’attaquant que sa tentative est réussie, ou de le déstabiliser lui ou son employeur : faux secrets de fabrication ou projets de brevets, fausses stratégies de rachat…

Une nouvelle approche aux nombreux avantages

Au vu de son fonctionnement, la Deceptive Security présente certains avantages par rapport aux solutions existantes.

• La transparence pour les utilisateurs et les applications : la mise en place de leurres n’ajoute aucune contrainte aux équipes IT et utilisateurs finaux : pas d’ouverture de flux, de blocage de communication ou de fichiers légitimes… ;
• Un faible taux de fausses alertes: un leurre n’étant pas supposé être utilisé de manière légitime, tout contact a de forte chance d’être lié à une menace ;
• L’absence de connaissance des attaques pour être efficace : la protection apportée par la Deceptive Security n’est pas basée sur une connaissance préalable de la menace à détecter ou bloquer (pas de signatures…). Elle est donc à même de détecter certaines menaces inconnues (0-days sur des dispositifs de sécurité ou des middlewares…) et ne nécessite pas de mise à jour continue pour être efficace. Cependant, pour détecter de cas spécifiques – sur un type d’attaque ou une ressource ciblée par exemple -, une bonne connaissance des vecteurs d’attaques reste une nécessité pour la création de miettes convaincantes et pertinentes pour le scénario souhaité ;
• L’absence de phase d’apprentissage : la détection ou le blocage d’une menace ne repose pas non plus sur l’apprentissage du réseau (seuils, patterns…), même si une connaissance de celui-ci reste nécessaire. L’outil est donc opérationnel dès son déploiement, et n’est pas vulnérable pendant cette phase de définition de la « normalité » du réseau. Ainsi, la Deceptive Security évite les principaux inconvénients des approches par signature et par apprentissage ;
• L’absence de besoin de corrélation avec d’autres ressources: même si la corrélation avec d’autres ressources reste un plus, une simple connexion sur un leurre suffit à lever une alerte nécessitant d’étudier le cas plus en détail ;
• La possibilité de couvrir des périmètres généralement difficiles à protéger: des leurres peuvent être déployés sur de nombreux périmètres (IoT, legacy…) avec une complexité limitée, et donc apporter une nouvelle protection à ces ressources souvent non-couvertes par les dispositifs classiques.

Des cas d’usage bien spécifiques

Si la Deceptive Security permet de détecter certaines attaques classiques (malwares, scans…), le réel intérêt de ce type de solution n’est pas là, ces menaces pouvant être adressées plus efficacement par les dispositifs existants (antivirus…).

Le meilleur cas d’usage de la Deceptive Security est la détection des tentatives d’explorations fines et d’installation au sein du réseau, permettant ainsi -quand le niveau de sophistication des miettes est suffisamment important- de détecter certaines APT. Plus généralement, ce type de solution permet de détecter les mouvements latéraux au sein du réseau, et ce même avec un niveau limité de personnalisation des miettes.

Ce type de dispositif n’est donc pas destiné à remplacer les mesures existantes, mais peut agir comme complément, dans le but de détecter ces types de menaces échappant communément aux dispositifs classiques.

Et pour la suite ?

Concernant l’évolution de ces solutions, certains travaux cherchent à appliquer ce principe (déguiser les leurres en environnements de production) … mais dans l’autre sens ! En faisant passer les environnements de production pour des leurres, cette démarche à contrepied permettrait d’éviter à ces ressources d’être ciblées par les attaquants !

Les éditeurs

Une liste -non exhaustive- d’éditeurs de solution de Deceptive Security est renseignée à titre indicatif ci-dessous.

Cet article Deceptive Security : comment arroser l’arroseur ? est apparu en premier sur RiskInsight.