Elastic Security rend public son référentiel de règles de détection

Chez Elastic, nous croyons en la puissance de l'open source et en l'importance de la communauté. En accordant toute notre attention à la communauté, nous veillons à créer le meilleur produit possible pour nos utilisateurs. Avec Elastic Security, nous répondons à deux de nos principaux objectifs : bloquer les menaces à grande échelle et équiper chaque analyste comme il faut. Aujourd'hui, nous rendons public un nouveau référentiel GitHub, elastic/detection-rules. Ceci, dans le but de travailler aux côtés de la communauté spécialisée dans la sécurité pour bloquer les menaces à plus grande échelle.

Avec le lancement du moteur de détection d'Elastic Security, nous avons pu automatiser la détection des menaces dans la Suite Elastic. Depuis, l'équipe Elastic Security Intelligence & Analytics a ajouté plus de 50 règles supplémentaires. Cela a permis d'améliorer la visibilité sur les techniques employées par les utilisateurs malveillants sur les systèmes d'exploitation Linux, macOS et Windows. Nous continuons à augmenter la couverture pour multiplier les possibilités de détection, notamment dans de nouveaux domaines comme les services cloud et le comportement des utilisateurs.

Dans les versions précédentes, nous utilisions un référentiel interne pour gérer les règles du moteur de détection. Aujourd'hui, nous avons amélioré nos procédures de test de manière itérative en ajoutant des tests automatisés sur les nouvelles contributions. Ces tests permettent de valider la syntaxe du langage de requête de Kibana (KQL), l'utilisation de schémas et d'autres métadonnées. Nous avons évolué dans la façon dont nous développons les règles. Nous pouvons donc avancer plus rapidement sans nuire au travail accompli.

En rendant public notre référentiel GitHub elastic/detection-rules, Elastic Security va développer des règles de manière ouverte avec l'aide de la communauté. Votre contribution est la bienvenue ! Il s'agit d'une occasion idéale de mettre en commun nos connaissances en matière de sécurité, d'apprendre les uns et des autres et d'avoir plus d'impact en unissant nos forces.

Qu'y a-t-il dans ce nouveau référentiel ?

Dans le référentiel GitHub elastic/detection-rules, vous trouverez des règles écrites pour Elastic Security, couvrant de nombreuses techniques MITRE ATT&CK®. Notre logique de règles actuelle est principalement rédigée en KQL. Grâce à Elastic Common Schema (ECS), nous n'avons besoin d'écrire une règle qu'une seule fois. En utilisant les champs définis et les catégories d'ECS, les règles fonctionnent automatiquement avec les logs Beats et d'autres sources de données qui se mappent correctement à ECS.

Dans le dossier rules/, les règles sont stockées au format TOML et regroupées par plateforme. Nous avons privilégié la simplicité en mettant en place une organisation horizontale. Le but : que vous puissiez trouver facilement une règle et en ajouter. Si vous recherchez des règles applicables à Windows uniquement, accédez au sous-dossier rules/windows. Si, malgré cela, vous peinez à trouver une règle ou si vous souhaitez effectuer une recherche globale, vous pouvez utiliser notre interface en ligne de commande et exécuter la commande python -m detection_rules rule-search. Celle-ci renverra alors les fichiers dont les métadonnées correspondent.

Chaque règle contient plusieurs champs de métadonnées en plus de la requête en tant que telle. Ces champs fournissent différentes informations comme le titre, la description, le niveau de bruit, les mappages ATT&CK, les balises, ou encore l'intervalle de programmation. D'autres champs supplémentaires aident les analystes à faire le tri, par exemple en décrivant les faux positifs connus ou en indiquant les étapes utiles pour une analyse. Pour plus d'informations sur les métadonnées appartenant aux règles, consultez le guide de création de règles de Kibana ou notre récapitulatif des métadonnées de règles dans le guide des contributions.

Comment ces règles sont-elles gérées dans mon moteur de détection ?

Si vous utilisez notre service géré Elastic Cloud ou la distribution par défaut de la Suite Elastic incluant l'ensemble complet de fonctionnalités gratuites, vous obtiendrez les versions les plus récentes des règles la première fois que vous accéderez au moteur de détection. Ensuite, lorsque vous ferez une mise à niveau, le moteur de détection reconnaîtra les règles ayant été ajoutées ou modifiées, puis vous invitera à décider si vous souhaitez (ou non) que ces règles soient mises à niveau. Après la mise à niveau, suivez les étapes indiquées et vous obtiendrez la dernière version des règles.

Qui utilisera ce référentiel ?

C'est dans ce référentiel que l'équipe Elastic Security Intelligence & Analytics développera des règles, créera des tickets, gèrera des requêtes d'extraction et ciblera les versions en voie d'être lancées. En rendant ce référentiel public, nous invitons tous les contributeurs externes à participer à ce workflow. Les contributeurs auront ainsi une bonne visibilité sur notre processus de développement ainsi qu'un accès clair aux règles à publier avec le moteur de détection.

Vous vous sentez prêt à contribuer ? Merci de signer le contrat de licence pour contributeur (CLA). C'est une étape incontournable pour l'ensemble des référentiels GitHub Elastic. Ce contrat entérine le fait que nous puissions distribuer librement votre code aux utilisateurs Elastic.

Quelle approche adopter en matière de détection des menaces ?

En général, nous avons tendance à privilégier les détections qui ciblent les comportements malveillants, ce qui signifie que nous nous concentrons habituellement sur les techniques ATT&CK. Avant de créer une règle, nous devons déterminer comment une technique fonctionne. Nous consacrons donc un certain temps et une certaine énergie à faire des recherches. Néanmoins, cette approche nous permet d'atteindre un résultat optimal en détectant et en bloquant les attaques d'aujourd'hui et de demain, et pas seulement celles d'hier.

Lorsque nous optons pour une approche comportementale, nous avons besoin de différents types de règles. Certaines peuvent détecter des événements atomiques, d'autres peuvent nécessiter d'agréger plusieurs événements ou d'examiner l'écart par rapport à un seuil. Avec l'Event Query Language (EQL), nous pourrons écrire des règles qui étudieront des séquences de comportement couvrant plusieurs événements.

Bien sûr, nous avons conscience qu'il n'est pas toujours aisé pour les utilisateurs de détecter une technique d'un point de vue comportemental. Dans ce cas, n'hésitez pas à ajouter une règle "signature" par nature, écrite pour un comportement ou un outil spécifique.

Pour poursuivre la discussion sur ce qui caractérise une détection "mature", découvrez la philosophie du référentiel de règles de détection.

Pourquoi avons-nous besoin d'un nouveau référentiel ?

Si vous avez déjà eu l'occasion de partager des règles publiques, vous connaissez probablement d'autres référentiels GitHub populaires, comme Cyber Analytics Repository (CAR) de MITRE, Sigma ou même EQL Analytics Library qui se base sur l'EQL d'Elastic. Vous vous posez peut-être les questions suivantes : Pourquoi avons-nous besoin d'un autre référentiel ? Pourquoi ne pas utiliser ceux qui existent déjà ?

Sans surprise, la meilleure réponse à ces questions est une autre question : Pourquoi les autres référentiels existent-ils ? Les référentiels CAR et Sigma s'adaptent tous deux, à dessein, à différents langages, plateformes, parfois même sources de données. À l'inverse, EQL Analytics Library a été écrit avec un langage spécifique en tête.

Avec notre nouveau référentiel de règles de détection, la finalité que nous recherchons est légèrement différente. Notre objectif est de donner aux utilisateurs d'Elastic Security les meilleures détections possible fonctionnant sur différentes sources de données. Nous utilisons ECS pour homogénéiser les schémas. L'avantage, c'est que nous pouvons écrire une règle applicable à plusieurs sources de données en une seule fois.

La Suite Elastic prend en charge plusieurs langages. De fait, il doit en aller de même pour nos règles. Les langages de requête sont généralement développés pour résoudre différents types de problèmes. Nous ne devons pas contraindre les développeurs de règles à utiliser un langage spécifique si un autre langage s'avère plus adapté. Actuellement, dans le référentiel, nous avons des règles KQL et Lucene, ainsi que des règles qui utilisent les tâches de détection des anomalies par Machine Learning. Nous travaillons dur pour intégrer l'EQL dans la Suite Elastic et dans notre référentiel.

Nous pouvons également vérifier que les bonnes pratiques sont respectées afin que les performances d'Elasticsearch soient optimales. Par exemple, si nous effectuons une recherche sur process.path:*\\cmd.exe, il est nécessaire de faire un contrôle des caractères génériques, ce qui est plus coûteux qu'un simple contrôle des mots-clés. Au lieu d'effectuer une recherche contenant des caractères génériques, nous vous recommandons d'utiliser process.name:cmd.exe, qui donnera de meilleures performances et renverra des résultats plus précis. Dans la même veine, ECS contient aussi le champ process.args, qui correspond à une version analysée de process.command_line. Nous vous recommandons d'utiliser plutôt le champ analysé, car celui-ci offre de meilleures performances, avec un nombre inférieur de caractères blancs insignifiants ou d'évasions basées sur des citations. C'est gagnant-gagnant !

Puis-je ajouter des règles venant d'un autre référentiel ?

Dans votre environnement, vous pouvez tout à fait ajouter des règles à votre propre moteur de détection, à partir du moment où votre rôle Kibana dispose des droits appropriés. Si vous souhaitez ajouter des règles au référentiel elastic/detection-rules, vous vous doutez probablement de ce que nous allons vous répondre : Ça dépend.... Tant qu'une règle peut être concédée sous licence dans le cadre de la licence Elastic, c'est possible. La plupart du temps, les exigences sont plutôt simples : conserver le nom des auteurs d'origine dans le tableau rule.author et mettre à jour le fichier NOTICE.txt en conséquence pour attribuer la règle aux auteurs d'origine. Nous ne voulons pas être récompensés pour le travail de quelqu'un d'autre. Aussi, aidez-nous à être rigoureux !

Pour en savoir plus sur notre approche en matière de licences dans le référentiel, consultez la section Licensing (Licences) du fichier README.

Comment puis-je apporter ma contribution ?

Vous avez hâte de partager votre logique de règles ? Accédez au référentiel elastic/detection-rules sur GitHub. Nous y avons détaillé des instructions sur l'utilisation du référentiel, sur le forking et le clonage, ainsi que sur la création d'une règle. Nous mettons aussi à votre disposition une interface de ligne de commande pour faciliter la modification de fichiers par lot et la création de règles. Lorsque vous êtes prêt à ajouter une nouvelle règle au référentiel, exécutez python -m detection_rules create-rule. Vous serez ensuite invité à entrer les métadonnées requises. Nous vous recommandons de privilégier l'utilisation de l'interface de ligne de commande, car elle limite le nombre d'erreurs de copier-coller qui surviennent lors de la réutilisation de contenus venant d'un fichier TOML d'une autre règle ou d'un autre modèle.

Lorsque votre règle est correcte, vous pouvez exécuter la commande python -m detection_rules test pour tester des unités de façon locale afin de valider la syntaxe, l'utilisation du schéma, etc. Créez ensuite la requête d'extraction. Un membre de l'équipe Intelligence & Analytics passera votre contribution en revue. Si des modifications s'avèrent nécessaires, nous regarderons avec vous ce qu'il faut modifier pour les appliquer. 

Vous avez une idée de règle, mais vous souhaitez collaborer avec nous pour la mettre en place ou pour avoir un retour ? N'hésitez pas à créer un ticket New Rule (Nouvelle règle). Nous avons hâte de vous aider et de travailler avec vous !

Pour plus d'informations, consultez notre guide des contributions.

Et ensuite ?

Bienvenue dans notre nouveau référentiel (et workflow) de règles ! N'hésitez pas à nous soumettre vos contributions. Nous avons hâte de voir votre nom dans le champ rule.author. Le référentiel de règles de détection va continuer à évoluer, tout comme Elastic Security, et nous sommes impatients d'aller de l'avant.

Si vous souhaitez suivre le développement de l'EQL dans la suite, abonnez-vous à ce ticket GitHub. Ou jetez un œil à notre documentation pour voir sur quoi travaille l'équipe Elasticsearch.

Si vous avez des retours à nous transmettre ou des questions à nous poser concernant l'écriture des règles ou l'accès à notre nouveau référentiel GitHub de règles de détection, veuillez créer un ticket dans GitHub, nous contacter sur le forum de discussion avec la balise detection-rules ou communiquer avec nous sur la chaîne #detection-rules de la communauté Slack Elastic.