Règles SIGMA: standardiser les détections quel que soit le SIEM

Les règles SIGMA sont un formidable outil collaboratif pour les équipes SOC. Elles permettent de normaliser les règles de détection indépendamment du SIEM utilisé.

Chez Yogosha, on prône les approches collaboratives de la cybersécurité. Les menaces et les profils d’attaquants prolifèrent trop rapidement pour que chaque organisation puisse encore se défendre seule dans son coin.

Pour être efficace, la sécurité doit passer par l’agrégation des compétences et des ressources.

Ça, c’est la théorie générale. Celle qu’on retrouve derrière le bug bounty par exemple, mais aussi derrière les règles SIGMA. Elles adressent cette problématique à travers un angle bien précis : la standardisation de la détection des menaces et des incidents – en facilitant au passage la tâche des SOC du monde entier.

C’est quoi, les règles SIGMA ?

Les règles SIGMA sont un langage unifié pour la détection des incidents, qui standardise les règles de détection peu importe le SIEM ou le système utilisé. Les règles SIGMA permettent entre autres :

• la création et le partage de règles de détection normalisées et utilisables par tous ;
• la migration des règles en toute simplicité en cas de changement de SIEM (Security Information Management System) ;
• l’unification de l’analyse des logs pour les acteurs qui utilisent plusieurs outils (SIEM, EDR, XDR…) comme les MSSPs ;
• la monétisation des contenus de détection par les chercheurs en sécurité et hackers éthiques, qui peuvent convertir le fruit de leur travail en règles SIGMA commercialisables.

Pourquoi utiliser les règles SIGMA ?

Les règles SIGMA sont aux logs ce que les règles YARA sont aux fichiers malveillants, ou les règles SNORT à l’activité du réseau. Elles facilitent et rationnalisent des tâches quotidiennes des équipes SOC (Security Operation Center).

Les règles SIGMA pour standardiser les détections

Grâce aux règles SIGMA, toutes les équipes SOC de la planète peuvent maintenant échanger et utiliser des règles de détection sans regard pour le SIEM ou la plateforme utilisée. Ne plus être conditionné par une technologie ou un fournisseur permet une flexibilité et une rapidité inégalées en matière de détection.

Vous avez créé une règle Splunk pour détecter une nouvelle menace ? Faites-en une règle SIGMA, et partagez-la avec les confrères qui utilisent QRadar, Qualys ou autre. Idem pour l’accès à des ressources web, la modification de fichiers ou la détection de n’importe quelle action suspecte ou non autorisée.

C’est là toute la beauté des règles SIGMA, toutes les détections peuvent être standardisées, de la plus simple à la plus compliquée, de la plus ancienne à la plus récente.

Les règles SIGMA pour vérifier l’intégrité des données

Outre la détection active des menaces, les règles SIGMA permettent d’analyser les logs a posteriori – pour peu qu’ils soient conservés bien évidemment. Appliquer une règle SIGMA à d’anciens logs permet de rechercher rapidement une activité suspecte en particulier, afin de vérifier si brèche il y a eu.

Règles SIGMA : par où commencer ?

Bonne nouvelle : les règles SIGMA ne sont pas compliquées à utiliser. Elles sont écrites en YAML, et une fois qu’on a compris la logique et les principaux écueils à éviter, c’est un jeu d’enfants.

Le Github SIGMA

Voici le repository Github de SIGMA. Vous y trouverez le projet, ainsi que Sigmac, le compilateur de règles qui permet de les traduire en fonction du SIEM de destination. A noter que l’outil undercode.io permet de faire la même chose directement en ligne.

Le Github est également un bon point de départ pour se former, à travers le Wiki ou en essayant les nombreuses règles de détection mises à disposition par la communauté.

Comment écrire une règle SIGMA ?

Il existe de nombreuses ressources sur le web pour aider à la création des règles SIGMA. Plutôt que de répéter ce qui a déjà été dit, nous vous renvoyons plutôt vers :

• Comment écrire des règles SIGMA, un tutoriel rédigé par Florian Roth, qui n’est autre que le co-créateur du projet SIGMA (l’autre étant Thomas Patzke) ;
• Defender’s Toolkit 102: Sigma Rules, un autre guide pratique exhaustif.

Ici, nous allons simplement survoler les basiques nécessaires à la bonne compréhension du fonctionnement des règles SIGMA.

Pour fonctionner, une règle SIGMA doit spécifier :

• une source de données – une source de logs donc ;
• un critère de détection : ce que l’on va chercher au sein des logs ciblés ;
• une cible : le SIEM ou le système qui va analyser les logs – Splunk, Sysmon, Sumo Logic…

Pour ce faire, les règles SIGMA répondent toutes à une même structure, avec divers champs à remplir :

title:
id:
status:
description:
author:
references:
logsource:
   category:
   product:
   service:
   definition:
detection: 
   condition: 
fields: 
falsepositives:
level: 
tags:

Seules les sections logsource et detection sont réellement nécessaires. Les autres sont des métadonnées qui facilitent la compréhension et l’adoption de la règle par le reste de la communauté. La partie Log Source est indispensable car c’est elle qui spécifie les logs qui doivent être analysés. La partie Detection est le cœur de la règle SIGMA, puisque c’est là qu’on va indiquer ce qui doit être cherché dans les logs.

Exemple : une règle SIGMA pour détecter l’exploitation d’une RCE dans Oracle WebLogic

Puisque rien ne vaut les démonstrations, place à un exemple. La règle SIGMA suivante, disponible sur le Github, permet de détecter l’exploitation de la vulnérabilité RCE dans Oracle WebLogic Server décrite dans CVE-2021-2109. Elle est écrite en YAML comme suit :

title: Oracle WebLogic Exploit CVE-2021-2109
id: 687f6504-7f44-4549-91fc-f07bab065821
status: test
description: Detects the exploitation of the WebLogic server vulnerability described in CVE-2021-2109
references:
    - https://twitter.com/pyn3rd/status/1351696768065409026
    - https://mp.weixin.qq.com/s/wX9TMXl1KVWwB_k6EZOklw
author: Bhabesh Raj
date: 2021/01/20
modified: 2022/10/09
tags:
    - attack.t1190
    - attack.initial_access
    - cve.2021.2109
logsource:
    category: webserver
detection:
    selection:
        cs-method: 'GET'
        c-uri|contains|all:
            - 'com.bea.console.handles.JndiBindingHandle'
            - 'ldap://'
            - 'AdminServer'
    condition: selection
fields:
    - c-ip
    - c-dns
falsepositives:
    - Unknown
level: critical

Maintenant, voici la même règle traduite en requête pour QRadar :

SELECT UTF8(payload), "sourceip" FROM events WHERE UTF8(payload) ILIKE '%GET%' AND "URL" ILIKE '%com.bea.console.handles.JndiBindingHandle%' AND "URL" ILIKE '%ldap://%' AND "URL" ILIKE '%AdminServer%'

Et ici avec Splunk :

index=* (cs-method="GET" AND c-uri="*com.bea.console.handles.JndiBindingHandle*" AND c-uri="*ldap://*" AND c-uri="*AdminServer*") | table c-ip,c-dns

Ou là encore avec Graylog :

(cs-method:"GET" AND c-uri:*com.bea.console.handles.JndiBindingHandle* AND c-uri:*ldap\:\/\/* AND c-uri:*AdminServer*)

Pratique, n’est-ce pas ?

Quels sont les SIEM et systèmes supportés par les règles SIGMA ?

A ce jour, 25 SIEMS (et affiliés) sont pris en charge par les règles SIGMA, tels que listés sur Github:

• Splunk
• ElasticSearch Query Strings
• ElasticSearch Query DSL
• Kibana
• Elastic X-Pack Watcher
• Logpoint
• Microsoft Defender Advanced Threat Protection (MDATP)
• Azure Sentinel / Azure Log Analytics
• Sumologic
• ArcSight
• QRadar
• Qualys
• RSA NetWitness
• PowerShell
• Grep
• LimaCharlie
• ee-outliers
• Structured Threat Information Expression (STIX)
• LOGIQ
• uberAgent ESA
• Devo
• LogRhythm
• Datadog Logs
• FortiSIEM
• HAWK.io MDR

La sécurité collaborative pour renforcer la sécurité globale

Les règles SIGMA sont un formidable outil de sécurité collaborative. En standardisant les règles de détection, elles facilitent l’échange des stratégies de détection entre les différents acteurs de la sécurité – analystes SOC, RSSI, hackers éthiques…

Autrement dit, les règles SIGMA favorisent une meilleure sécurité globale en permettant à l’intelligence collective de s’affranchir des considérations secondaires que sont le choix du SIEM ou des systèmes utilisés. Une initiative que nous ne pouvons que saluer chez Yogosha, puisque c’est précisément la philosophie derrière le Vulnerability Operations Center (VOC).

Le VOC est à la sécurité offensive ce que le SOC est à la sécurité défensive. Le VOC est à la sécurité offensive ce que le SOC est à la sécurité défensive. Comme les règles SIGMA, le VOC améliore la détection des vulnérabilités en favorisant la collaboration entre les communautés sécu, et en réduisant la friction entre les outils.

Lire aussi : C’est quoi, un Vulnerability Operations Center (VOC) ?