Améliorer la connaissances des menaces et des attaquants : plateformes CTI (-Cyber-Threat Intelligence)

La Cyber Threat Intelligence (CTI ou Threat Intel’) est une discipline regroupant la récolte, la consolidation et l’exploitation de toutes les informations sur les cyber-menaces. “Connais ton ennemi” indique Sun Tzu dans l’Art de la Guerre. Bien que cette citation fasse référence aux guerres « physique », le principe reste vrai… et l’est sans doute même davantage pour les luttes « cyber ».

En effet, aujourd’hui, un nombre important de dispositifs de sécurité s’appuient sur une connaissance des attaques : approche par signature des anti-virus et IDS, scénarios de détection ciblés… Même si la tendance s’inverse (notamment avec la détection d’anomalies), la grande majorité des produits de sécurité s’appuient toujours -et continueront de s’appuyer- sur des principes de Threat Intelligence.

Les besoins des entreprises étant de plus en plus spécifiques, et les attaquants de plus en plus spécialisés, les solutions de Threat Intel’ se démocratisent et proposent directement leurs services aux entreprises. En complément des offres commerciales, de plus en plus de plateformes d’échanges et de partenariats permettent de collaborer directement avec d’autres entreprises (de même secteur, zone géographique…).

Les services rendus par la Threat Intel’ sont multiples. D’une part la Threat Intel’ « stratégique » aide les SOC à mieux connaître le contexte et les menaces spécifiques à leur entreprise. Pour cela, les risques pesant sur chaque écosystème sont étudiés : aspects géographique, politique, idéologique, sectorielle… Ces informations permettent aux équipes sécurités de mieux connaître les menaces les concernant, et d’orienter leurs décisions pour définir leur stratégie « long terme » (solutions à déployer…).

D’autre part, la Threat Intel’ « tactique » donne des informations plus précises sur les méthodes des attaquants et permet notamment au SOC de faciliter la détection et d’adapter les mesures existantes : nouveaux scénarios de menaces à surveiller, ports à bloquer….

En complément de ces approches, la Threat Intel’ « technique » participe grandement à l’analyse des évènements de sécurité en fournissant, sur demande (depuis un SOAR notamment, voir partie suivante), des éléments permettant de juger de la véracité d’une alerte : appartenance d’une IP à un botnet, hash de fichier correspondant à un virus connu…

Les dispositifs de Threat Intelligence figurent donc parmi les outils les plus polyvalents du SOC, en permettant de tirer parti au mieux des dispositifs existant, en restant à jour et priorisant les menaces à détecter, et en orientant vers les prochains outils et mesures à déployer.

Exemples d’éditeurs Threat Intelligence :

Industrialiser et automatiser le processus de réaction : SOAR

Les SOAR (pour Security Orchestration, Automation & Response) sont issus de la combinaison de trois outils du SOC : les SIRP (Security Incident Response Plateform, plus de détails ici), les SOA (Security Orchestration & Automation, les solutions d’industrialisation et d’automatisation) et une partie des fonctionnalités de plateformes de Threat Intelligence. Pour résumer, ce sont des plateformes d’aide et d’automatisation de la réaction aux incidents de sécurité. Ces solutions se rapprochent d’outils de ticketing (ITSM) classiques, mais embarquent des fonctionnalités spécifiques aux problématiques de cybersécurité. Les SOAR offrent principalement trois capacités, chacune liée à l’un des trois types d’outils à leur origine.

Premièrement, comme les SIRP, ils permettent la définition de processus de réaction adaptés à chaque évènement de sécurité. Ceux-ci sont basés sur des playbooks prédéfinis par l’éditeur, publiés par la communauté de la solution, ou créés manuellement pour une meilleure adaptation aux besoins de l’entreprise. Cette tâche impose notamment aux équipes de réaction d’établir un processus clairement défini, les aidant ainsi à se poser les bonnes questions lors de la création de procédures de réaction, et à capitaliser et stocker ces connaissances.

Le gain des SOAR repose cependant davantage sur l’automatisation des différentes étapes suivant la détection. Lors de la phase d’analyse, l’outil va automatiquement enrichir l’évènement de sécurité en allant récupérer des informations de contexte sur le SI (identité dans l’AD, criticité d’une ressource…), et en interrogeant des services de Threat Intelligence externes (via des API) ou proposés avec la solution. Outre l’automatisation de l’enrichissement et des étapes d’analyse, les SOAR facilitent aussi le travail des analystes -investigation de postes, interrogation de VirusTotal… en un clic-  lorsque leur intervention est nécessaire.

Mais l’automatisation ne s’arrête pas là ! Bien que polémique, l’automatisation de la réaction (via la connexion aux équipements de sécurité, héritage du SOA) peut représenter un gain important pour les équipes de sécurité : blocage d’URL, génération de signature de fichier et propagation aux antivirus, blacklisting d’IP…

L’objectif des SOAR est donc clair : faciliter la tâche des équipes en charge de l’analyse et de la réaction, en les aidant à définir des processus et en automatisant les tâches au maximum. Même si les SOAR sont très adaptables, et peuvent donc aider à répondre à toute type d’attaque, ils brillent tout particulièrement pour automatiser le traitement des attaques courantes (ransomware, phishing…), très répétitives et mobilisant les efforts des équipes de réaction.

Une fois ces tâches automatisées, les équipes sécurité en charge de la réaction peuvent se concentrer sur les alertes plus complexes, où leurs connaissances apportent une véritable valeur ajoutée.

À conditions d’être prêt à fournir l’effort initial (formalisation des processus…), les gains en réactivité et en charge attendus sont donc conséquents. Les SOAR sont amenés à changer le mode de travail des équipes SOC, en particulier pour les analystes de premier niveau. Même si ces solutions sont encore peu déployées en France, ils devraient devenir l’un des indispensables du SOC dans les années qui viennent.

Exemples d’éditeurs SOAR :

Même si l’outillage n’est qu’une partie du SOC, chacune de ces solutions présente des avantages certains qui aideront les équipes de détection à rester d’actualité face à l’évolution du SI et des menaces.

Tous ces outils sont prometteurs, et certains arrivent à maturité. Cependant, il est important de garder à l’esprit que l’outillage actuel lève déjà de nombreuses alertes, difficiles à prendre en compte. Il est donc conseillé de finir de déployer et d’industrialiser l’existant (en utilisant un SOAR par exemple), avant de se tourner vers de nouvelles solutions.

Et, comme pour tout produit innovant, il faut savoir garder la tête froide : le déploiement d’une nouvelle solution doit être motivé par des besoins bien définis.

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 (3/3) 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.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

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

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la 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 (1/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.