Impact, douleur, actionnabilité et gravité du SIEM

[post-views]
avril 13, 2020 · 7 min de lecture
Impact, douleur, actionnabilité et gravité du SIEM

Objectif

L’objectif de cet article de blog est d’introduire les métriques (Douleur, Exploitabilité, Impact SIEM et Sévérité) qui ont été introduites sur le Threat Detection Marketplace de SOC Prime.

Introduction

SOC Prime’s Threat Detection Marketplace améliore vos opérations de sécurité avec du contenu de détection de qualité.Comme pour toutes les technologies défensives, déployer tout le contenu possible « prêt à l’emploi » n’est pas recommandé, et choisir quel contenu apporte le plus de valeur peut parfois être difficile. Avec les nouvelles métriques Impact SIEM, Douleur, Exploitabilité et Sévérité, SOC Prime espère que décider quelles règles sont adaptées pour vous deviendra plus simple.

Cependant, ces métriques ne reflètent pas directement la qualité d’un élément de contenu. Une règle peut potentiellement avoir un faible score dans la plupart des métriques mais rester une détection de qualité.

  • Impact SIEM : Il s’agit de l’impact anticipé sur les performances d’un SIEM
  • Douleur : Le score reflète où la règle se situe sur la pyramide de la douleur. Les règles à forte douleur sont idéales pour les chasseurs de menaces et les opérateurs L3.
  • Exploitabilité : À quel point le triage est-il évident. Un score d’exploitabilité élevé reflète qu’un analyste L1 sera en mesure de comprendre rapidement les prochaines étapes. Une règle à faible exploitabilité peut nécessiter des étapes avancées telles que la forensique en mémoire, contacter le propriétaire du compte, ou effectuer de nombreuses recherches supplémentaires.
  • Sévérité : À quel point est-il critique de revoir toute alerte causée par cette logique. Cela est dérivé du champ niveau SIGMA.

Douleur, Exploitabilité et Sévérité sont fournis par l’analyste qui a créé la règle dans le but de réfléchir aux qualités de la règle. SOC Prime examine tout le contenu et peut ajuster les valeurs en fonction de notre expertise et des retours clients. L’impact SIEM est actuellement attribué via des moyens semi-automatisés, et cela sera pleinement mis en œuvre à l’avenir.

Dans les sections suivantes, je décrirai comment ces éléments sont notés et traités dans le Threat Detection Marketplace.

Obtenir les métriques

Lorsque vous sélectionnez une règle dans le panneau de recherche, les métriques concernant la règle s’afficheront sur le côté droit de l’écran. Ces métriques seront disponibles pour le contenu communautaire et exclusif.

Impact SIEM (1 – 3, un score plus élevé signifie moins d’impact)

L’impact SIEM est l’impact anticipé sur le système contre lequel vous exécuterez la règle.

Les SIEMs sont des systèmes d’analyse nécessitant des quantités massives de puissance de calcul pour obtenir un résultat positif. Cela rend la tâche d’optimisation de chaque bit et octet de la configuration du SIEM une routine quotidienne. Les personnes ayant passé des années dans l’ingénierie de détection ou familières avec les bonnes pratiques de regex savent qu’une règle avec un énoncé event=/.*threat.*/ est une règle « gourmande ». Ajoutez-en une dans une grande installation de production et vous pourriez expérimenter une recherche plus lente. Ajoutez-en cent, et même un système distribué commencera à perdre en performance. Nous avons observé divers fournisseurs de SIEM fournissant des affirmations gourmandes lors des formations pour mettre en évidence la facilité de trouver des menaces. En production, il est cependant important de créer des règles rentables, et c’est exactement pourquoi nous avons introduit cette métrique.

À mesure que la complexité de la règle et la quantité de bruit dans les sources de données augmentent, le score d’impact SIEM sera plus bas.

Score Logique Raisonnement
message contient « a » OU « b » OU « c » OU « d » OU « e » OU « f » OU « g » OU « h » OU « i » OU « j » OU « k » OU « l » OU « m » OU « n » OU OU « o » OU « p » OU « q » OU « r » OU « s » OU « t » OU « u » OU « v » OU « w » OU « x » OU « y » OU « z » OU « 1 » OU « 2 » OU « 3 » This rule would not be accepted as it is too impactful.
1 user = « *$ » AND (commandline contains « TVqAA ») (commandline contains « http:// » OR commandline contains « https:// » OR commandline contains « ftp » OR commandline contains « file:\\ ») Beaucoup d’utilisation de caractères génériques/contient
2 eventid=4688 AND commandline contains « scrobj.dl » L’utilisation de contient augmente la charge sur le SIEM.
3 eventid:5140 AND sharename:Admin$ Une correspondance exacte sur les champs est optimale d’un point de vue performance

_

Douleur (1 – 3, plus élevé est plus comportemental/moins facile à contourner)

Le score de douleur est une abstraction de la place qu’occupe la règle sur la Pyramide de la Douleur de David Bianco et à quel point la logique est facilement contournée. Plus la règle est comportementale et moins elle est susceptible d’être contournée, plus le score de douleur sera élevé. Les règles comportementales sont généralement meilleures pour la chasse aux menaces et peuvent souvent être plus bruyantes ou nécessiter des compteurs de pile pour être efficaces. Les règles basées sur les IOC devraient provoquer moins de bruit mais pourraient être très rares à déclencher ou seulement utiles pour l’analyse historique. Le mécanisme de journalisation étant désactivé ou totalement subverti n’est pas pris en compte dans ce score (c’est-à-dire des outils comme le fantôme dans les journaux)

 

Score Logique Raisonnement
1 destination.ip= »1.1.1.1″ AND destination.port=53 Il s’agit d’une détection basée sur l’IP, les IPs sont facilement modifiables.
2 eventid=4688 AND commandline contains « scrobj.dl » Ceci est une détection de comportement mais scrobj.dll peut être renommé pour éviter cette détection.
3 eventid:5140 AND sharename:Admin$ Si quelqu’un se connecte à un partage admin sur Microsoft ce journal n’est pas facilement contourné

_

Exploitabilité (1 – 3, plus élevé est plus évident)

Le score d’exploitabilité reflétera à quel point la règle est « digeste ». Souvent, c’est un reflet direct de la source de journal elle-même. Plus le contexte disponible dans la source de journal originale est important, plus le score d’exploitabilité est susceptible d’être élevé. Encore une fois, cela est basé sur les données d’alerte elles-mêmes. L’exploitabilité de toutes les règles de votre environnement peut augmenter grandement grâce à l’automatisation et à l’orchestration. Ceci n’est pas pris en compte.

Score Logique Raisonnement
1 destination.ip=”1.1.1.1” AND destination.port=53 Selon la source de données cet avertissement pourrait être très difficile à trier. Souvent, des règles comme celle-ci se déclenchent sur des hôtes non gérés (réseau invité, etc). De plus, le DHCP peut introduire des complexities dans l’identification de l’hôte fautif. 
2 eventid:5140 AND sharename:Admin$ L’ID d’événement Windows 5140 fournira le nom d’utilisateur et le nom d’hôte/IP qui ont accédé à un partage. Cependant, il faudra probablement effectuer des recherches supplémentaires pour déterminer s’il s’agit du résultat d’une compromission.
3 eventid=4688 AND commandline contains ”scrobj.dl” L’ID d’événement Windows 4688 fournit beaucoup de contexte immédiatement utile à un analyste. Il est probable qu’identifier une compromission probable soit possible en ne regardant que cette alerte.

Sévérité (1 – 3, plus élevé est une alerte plus critique)

La sévérité est une abstraction des niveaux SIGMA (bas, moyen, élevé et critique).

Score Niveau SIGMA Raisonnement
1 Low Veuillez consulter : https://github.com/Neo23x0/sigma/wiki/Rule-Creation-Guide
2 Moyen
3 Élevé & Critique

Conclusion

Trouver un contenu correspondant à vos besoins devrait être aussi simple que possible. En introduisant les métriques Impact SIEM, Douleur, Exploitabilité et Sévérité, SOC Prime espère aider à faire correspondre le contenu par nos développeurs du Threat Bounty Program avec les exigences de votre opération défensive.

Si vous avez une équipe interne d’ingénierie de détection, nous vous recommandons qu’ils implémentent ces concepts et les capturent comme une métrique lors de la création de contenu défensif.

Méta

Publié – avril 2020

Dernière mise à jour – 15 avril 2020

Auteurs – Adam Swan (@acalarch) | Andrii Bezverkhyi (@andriinb)

Cet article vous a-t-il été utile ?

Aimez-le et partagez-le avec vos collègues.
Rejoignez la plateforme Detection as Code de SOC Prime pour améliorer la visibilité des menaces les plus pertinentes pour votre entreprise. Pour vous aider à démarrer et générer une valeur immédiate, réservez dès maintenant une réunion avec les experts de SOC Prime.

Articles connexes