Elastic Security : des protections préconfigurées pour les équipes de sécurité

Des contenus préconfigurés pour les ingénieurs de détection

Elastic Security propose désormais plus de 1 100 règles de détection préconfigurées pour aider ses utilisateurs à paramétrer leurs détections et leur monitoring de sécurité rapidement et être opérationnels dès que possible. Sur ces quelque 1 100 règles, plus de 760 sont des règles de détection pour le SIEM prenant en compte plusieurs sources de logs, les autres s'exécutant sur des points de terminaison utilisant Elastic Security for Endpoint.

Elastic s'est engagée à faire preuve de transparence et d'ouverture auprès de la communauté du domaine de la sécurité. C'est la raison principale pour laquelle nous mettons notre logique de détection à la disposition des utilisateurs afin de pouvoir la faire évoluer en collaboration avec tous ceux qui s'y intéressent. Il est important à nos yeux de partager nos recherches, nos règles et d'autres découvertes avec la communauté du domaine de la sécurité, afin que nous puissions apprendre auprès d'elle et continuer à améliorer nos produits.

Non seulement l'ensemble de ces contenus sont intégrés et disponibles immédiatement dans Elastic Security, mais nous les fournissons également par l'intermédiaire de référentiels GitHub publics (detection-rules, protection-artifacts).

Nous n'avons pas à rougir des comparaisons effectuées avec d'autres produits axés sur la détection. Vous pouvez donc retrouver Elastic Security sur la plateforme Tidal Cyber.

Pourquoi fournissons-nous des contenus de sécurité ?

Nous sommes parfaitement conscients que les entreprises n'ont pas toutes les ressources nécessaires pour rechercher de nouvelles menaces et effectuer des détections avec les dernières technologies et fonctionnalités disponibles. C'est là qu'Elastic Security intervient, en faisant office de ressource supplémentaire pour votre équipe de sécurité.

L'équipe TRADE (Threat Research and Detection Engineering) d'Elastic fait des recherches sur les menaces émergentes et courantes, et de là, met au point des règles de détection et de prévention qu'elle tient à jour pour nos utilisateurs. L'équipe fait également part de ses commentaires pour améliorer les différents langages de requête utilisés pour prendre en charge les cas d'utilisation de sécurité. L'équipe TRADE travaille en étroite collaboration avec notre équipe InfoSec interne, ainsi qu'avec d'autres équipes d'ingénierie, pour veiller à ce que les remarques communiquées soient prises en compte pour améliorer les produits de façon continue.

Dans le reste de cet article, nous verrons comment tirer parti des règles de détection SIEM et des contenus de sécurité qui les accompagnent, et nous étudierons comment ils sont créés. À présent, entrons dans le vif du sujet.

Processus de création de règles d'Elastic

1. Identification du thème

La première étape du processus de création de règles consiste à identifier le thème qui servira d'axe principal, en fonction des initiatives de recherche, de l'environnement actuel des menaces, de l'analyse des renseignements fournis par la veille et de l'analyse de la couverture. Nous prenons aussi en compte les intégrations disponibles et populaires, les demandes des utilisateurs et les tendances.

2. Étude du thème

Une fois que la technologie, la menace ou la tactique sur laquelle nous souhaitons nous concentrer a été identifiée, nous l'étudions. Vous trouverez ici un exemple d'analyse pour Google Workplace. Nous réalisons une étude approfondie pour comprendre l'architecture et les services fournis, ainsi que pour identifier les techniques préjudiciables potentielles généralement mappées au cadre MITRE ATT&CK®.

3. Création du laboratoire

Pour travailler sur les règles, nous aurons peut-être besoin d'un environnement de laboratoire pour pouvoir simuler la menace et générer ainsi les données nécessaires pour créer et tester la logique de détection. L'exemple ci-dessus vous permet de jeter un coup d'œil dans les coulisses de la création d'un laboratoire pour Google Workplace. Quelle que soit la source de données pour laquelle nous établissons des règles, nous utiliserons la même approche pour créer et gérer un environnement de laboratoire.

4. Travail sur les règles

En général, c'est l'auteur d'une règle qui détermine le type de règle à utiliser. Il applique les bonnes pratiques pour créer une logique de détection performante qui génère peu de faux positifs, il la teste et il crée le fichier de règle avec l'ensemble des champs de métadonnées nécessaires. La philosophie de la TRADE permet une élaboration appropriée et un testing adéquat d'une règle.

5. Réalisation d'un examen par des pairs

Ensuite, la règle est prête à être soumise à un examen par des pairs. Il va de soi que les examinateurs doivent aussi comprendre la technologie et les menaces gérées par la nouvelle détection. Les collègues doivent évaluer la logique de détection existante pour identifier les cas extrêmes dans lesquels la logique peut potentiellement présenter des failles. Il est possible que les règles soient contournées par une menace ou qu'elles connaissent des perturbations dans l'environnement des clients. C'est pourquoi il est important de trouver le bon équilibre.

6. Considérations liées à la couverture

Lorsque nous cherchons à améliorer la couverture de notre détection, nous vérifions également si une règle existante pourrait être ajustée pour prendre en charge la nouvelle détection ou si l'approche décidée serait raisonnable du point de vue des analystes en sécurité lorsqu'ils enquêtent sur les alertes générées. Ainsi, les auteurs de règles peuvent se concentrer sur une production de qualité plutôt que de quantité. 

Lors de ce processus, il arrive que nous déterminions qu'une règle générera trop de faux positifs. Dans ce cas, nous la mettons de côté pour la publier en tant que règle fondamentale. Dans d'autres cas, nous repérons des lacunes dans la couverture des données qui nous empêchent de créer une logique de détection efficace. Nous collaborons alors avec les autres équipes d'Elastic pour combler ces lacunes et, de ce fait, nous reportons la création de la règle.

Nous sommes conscients que la couverture d'une règle de détection prête à l'emploi peut ne pas être adaptée à l'environnement de certains utilisateurs. C'est pourquoi les règles peuvent être remaniées dans Kibana si vous avez besoin de les modifier. Une approche plus simple consiste à ajuster la règle en y ajoutant des exceptions pour la mettre à jour en fonction de votre modèle de menace et des caractéristiques spécifiques de votre environnement. Pour en savoir plus sur l'approche que nous appliquons lorsque nous élaborons des règles et sur ce que celles-ci peuvent vous apporter, lisez cet article.

Vous pouvez suivre notre procédure de création des règles de détection dans le référentiel correspondant. Si vous avez une règle que vous souhaitez partager avec d'autres utilisateurs Elastic, vous pouvez la mettre à la disposition de la communauté via notre référentiel, comme d'autres l'ont fait précédemment.

Et vous savez quoi ? Il n'y a pas que les nouvelles règles qui comptent !

En plus du travail de création de règles, l'équipe passe beaucoup de temps à monitorer et à adapter les règles existantes. De temps en temps, nous retirons aussi certaines règles qui ne répondent plus à nos normes en raison de leur obsolescence.

Comme vous le savez, nous aimons les données. Nous nous sommes donc penchés sur les 600 dernières requêtes "pull" du référentiel de règles de détection pour déterminer les types de tâches que nous avons réalisées. Comme vous pouvez le voir dans le tableau ci-dessous, l'ajustement et la maintenance surpassent de loin la création de règles. Notre objectif est de conserver des détections de haute qualité et à jour.

Les chercheurs d'Elastic Security Labs examinent régulièrement les données télémétriques pour déterminer les règles qui ont besoin d'être ajustées d'après la prévalence des alertes et des paramètres spécifiques.

Les données télémétriques d'Elastic Security sont volontairement partagées par nos utilisateurs et servent à améliorer les performances des produits et l'efficacité des fonctionnalités. D'ailleurs, le récent rapport d'Elastic sur les menaces mondiales se base sur les données partagées par nos utilisateurs. Dans ce rapport, nous faisons part de nos observations sur la situation au niveau mondial concernant les menaces. Vous pouvez vous appuyer sur nos constatations pour guider la création de vos propres règles.

Lors de l'examen des données télémétriques pour booster l'efficacité des règles, l'identification des menaces occupe une place prioritaire. Les ingénieurs enfilent leur casquette de chercheurs pour étudier les alertes découlant de vrais positifs. Les données télémétriques des vrais positifs requièrent leur propre workflow de tri, mais peuvent conduire à la création d'une nouvelle règle ou d'une investigation plus poussée. La TRADE participe aussi à la recherche et à l'analyse avancée d'Elastic Security Labs, en particulier à l'analyse plus technique comme la rétroingénierie des malwares, le profilage des adversaires, la découverte de l'infrastructure et la collection d'indicateurs atomiques. Nous collaborons souvent avec d'autres équipes de recherche internes sur cette étude. 

Contenus de détection pour les analystes en sécurité

Les ingénieurs de détection ne sont pas les seuls à utiliser les règles de détection. Elles concernent également les analystes en sécurité qui trient les alertes et les examinent.

Pour les analystes en sécurité, nous fournissons un contexte opérationnel concernant les menaces en enrichissant les règles avec des informations supplémentaires, comme des guides d'investigation. Les auteurs de règles ajoutent des informations concernant les attaquants et les comportements, les suggestions d'enquête, les faux positifs, l'analyse et les étapes de résolution. Cette information est très utile pour les analystes qui étudient les alertes et qui ont besoin de comprendre rapidement pourquoi celles-ci ont été déclenchées afin de pouvoir déterminer la marche à suivre. Le guide d'investigation peut être aussi consulté dans l'interface des alertes de la solution Elastic Security.

Nous vous recommandons de créer des guides d'investigation pour vos règles personnalisées. Ils constitueront une ressource précieuse pour les équipes de sécurité.

Nous mettons tout en œuvre pour proposer une couverture complète des règles de détection des menaces avec les guides d'investigation. Au moment de cette publication, environ 30 % des règles configurées sont accompagnées de guides d'investigation. Vous pouvez facilement filtrer les règles pour obtenir celles ayant des guides en utilisant la balise "Investigation Guide" (Guide d'investigation).

Les données télémétriques des produits servent également pour déterminer l'ordre de priorité dans l'élaboration des guides. Nous regardons quelles sont les règles les plus utilisées par nos utilisateurs et nous leur fournissons des informations sur les aspects qui les intéressent.

Notre roadmap est axée sur l'amélioration continue des guides d'investigation concernant les recommandations de tri et de résolution, ainsi que sur l'amélioration des fonctionnalités. Par exemple, à partir de la version 8.5 de la Suite Elastic, les guides d'investigation peuvent contenir des recherches Osquery personnalisées qui vont interroger les points de terminaison afin d'obtenir des données télémétriques supplémentaires pouvant s'avérer utiles lors de l'analyse ou du tri.

Vous avez des commentaires ou des suggestions en ce qui concerne les guides d'investigation ? Dites-le nous en soumettant un problème sur GitHub. Nous apprécions les contributions de la communauté !

Même si une logique de détection de qualité est essentielle pour identifier les menaces potentielles, nous sommes conscients qu'il peut être important pour les analystes d'avoir du contexte supplémentaire sur une menace donnée. Avec les règles de détection préconfigurées, Elastic s'efforce de fournir le plus de contexte possible sur la règle en elle-même.

En marge des guides d'investigation, nous mappons toutes les règles à leur matrice MITRE ATT&CK spécifique et nous identifions la gravité et le risque de l'alerte pour vous. En outre, comme il peut être difficile de savoir quelles règles appliquer lorsqu'on ingère des données à partir de différentes sources, nous indiquons les intégrations nécessaires pour telle ou telle règle. Vous pouvez utiliser le champ Related Integrations (Intégrations associées) pour accéder à une intégration pertinente, la configurer et (si nécessaire) appliquer la règle associée pour vous assurer que les ensembles de données appropriés ont été ingérés.

Les mises à jour des règles, y compris le contexte supplémentaire, sont publiées régulièrement hors cycle et fournies directement aux utilisateurs dans la solution Elastic Security. Nous vous recommandons de mettre à niveau votre Suite Elastic avec une version récente, pour que vous puissiez exploiter le plein potentiel des règles s'appuyant sur les nouvelles fonctionnalités de sécurité.

Autre chose ?

L'équipe TRADE travaille également sur une fonctionnalité des règles de détection qui s'appelle Red Team Automation (RTA). Cette fonctionnalité, écrite en Python, facilite le testing des règles. Les scripts RTA sont utilisés pour générer des vrais positifs sans risque et aider l'équipe à automatiser le testing de régression des règles de détection par rapport à plusieurs versions de la solution Elastic Security. Vous pouvez aussi vous servir des scripts RTA publiés pour effectuer vos propres tests ou en créer de nouveaux pour vos règles personnalisées.

Pour en savoir plus sur la fonctionnalité de RTA et d'autres outils que l'équipe fournit, lisez cet article.

Restez à l'affût pour en savoir plus

Comme vous pouvez le voir, notre objectif est de vous fournir des contenus préconfigurés tout au long du workflow de détection et du cycle de vie des règles, depuis la création d'une règle jusqu'à sa mise en application, en passant par sa mise à jour et son testing. Et, nous le répétons, tous ces contenus sont intégrés directement dans les produits et sont partagés de manière ouverte avec la communauté via GitHub.

Nous mettons tout en œuvre pour renforcer la sécurité des systèmes de nos clients et pour faciliter la tâche à leurs équipes. N'hésitez pas à nous contacter si vous souhaitez nous faire part de vos idées ou de vos difficultés. Pour cela, vous pouvez passer par la communauté Slack ou par nos forums de discussion. À bientôt !