Écrire des règles Sigma

Sigma est un format de signatures générique et indépendant des fournisseurs pour les détections fondées sur les journaux. Vous écrivez une seule fois la logique de détection en YAML, puis vous la convertissez en SPL pour Splunk, en requêtes Elastic, en KQL pour Sentinel et pour de nombreux autres systèmes cibles.

Sigma joue pour la détection dans les journaux le même rôle que YARA pour la détection dans les fichiers : c’est une langue commune portable. Il permet aux équipes de partager publiquement des règles et d’éviter de réécrire la même idée pour chaque SIEM.

Une règle Sigma est un document YAML composé de sections obligatoires et facultatives. Les éléments essentiels sont title, logsource et detection.

Le bloc logsource indique au convertisseur quels journaux la règle concerne. Il n’interroge pas directement les données ; il sélectionne la correspondance de champs et l’index appropriés lors de la conversion.

Clés courantes :

• product — par exemple windows, linux, aws
• category — par exemple process_creation, network_connection, file_event
• service — par exemple sysmon, security, sshd

Choisissez la combinaison la plus précise prise en charge par vos données afin que la chaîne de traitement associe correctement les champs.

Dans detection, vous définissez un ou plusieurs identifiants de recherche nommés (sélections). Chacun est un mappage de critères associant champs et valeurs. Plusieurs champs au sein d’une même sélection sont combinés avec un AND logique.

Ici, les deux conditions doivent être vraies pour que selection corresponde.

Les modificateurs précisent la manière dont une valeur est comparée. Ils sont ajoutés au nom du champ après une barre verticale.

• contains — recherche d’une sous-chaîne
• startswith / endswith — recherche avec ancrage
• all — toutes les valeurs d’une liste doivent être présentes
• re — expression régulière
• base64offset|contains — recherche de sous-chaînes encodées en base64

Les modificateurs s’enchaînent de gauche à droite et sont appliqués dans cet ordre.

Deux règles régissent la logique au sein d’une sélection :

• Une liste de valeurs sous un même champ utilise OR : n’importe quelle valeur correspond.
• Un mappage de plusieurs champs utilise AND : tous les champs doivent correspondre.

Ci-dessous, Image correspond à l’un ou l’autre des fichiers binaires, et User doit également être égal à SYSTEM.

condition combine vos sélections nommées avec une logique booléenne. C’est ici que vous exprimez les filtres et les exclusions.

Les opérateurs comprennent and, or, not, les parenthèses et des agrégations comme count(). Vous pouvez également utiliser 1 of selection* / all of selection* pour faire référence à des groupes d’identifiants partageant un même préfixe.

Pour supprimer les activités connues comme légitimes, définissez un identifiant distinct et soustrayez-le dans la condition avec not. La logique malveillante reste ainsi lisible et les exclusions sont explicites.

Ici, la règle se déclenche lorsque rundll32 crée une connexion réseau, sauf s’il s’agit d’un processus de mise à jour légitime connu.

Au-delà de la logique, les bonnes règles comportent des métadonnées qui aident les intervenants à agir rapidement et les ingénieurs à maintenir la couverture.

• level — informatif, faible, moyen, élevé, critique
• tags — techniques ATT&CK, par exemple attack.t1059.001
• falsepositives — déclencheurs bénins connus
• references — rapports ou documents sur les menaces
• author et date

Ces champs prennent quelques minutes à renseigner et font gagner des heures pendant un incident.

Les règles portant sur un seul événement ne peuvent pas exprimer les attaques en plusieurs étapes. Les règles de corrélation Sigma combinent plusieurs règles de base au fil du temps pour détecter des séquences et des schémas.

Les types pris en charge comprennent event_count (N correspondances dans une fenêtre), value_count (valeurs distinctes, par exemple de nombreux utilisateurs ayant échoué à se connecter) et temporal (règle A puis règle B). Vous pouvez ainsi détecter, par exemple, une connexion réussie juste après une série d’échecs.

Avec sigma-cli, vous convertissez une règle dans le langage de requête de votre cible. Une chaîne de traitement associe les noms de champs Sigma à votre schéma réel.

La sortie est une requête prête à déployer, que vous pouvez coller ou envoyer via une API.

Vérifiez votre compréhension de la logique de détection Sigma.

Vous pouvez maintenant rédiger des règles Sigma portables :

• logsource sélectionne les journaux et les correspondances de champs applicables
• Les sélections sont des critères nommés associant champs et valeurs (champs = AND, listes de valeurs = OR)
• Les modificateurs comme contains, endswith, all et re précisent la comparaison
• condition combine les sélections avec and/or/not, des filtres et des agrégations
• Des identifiants filter distincts soustraient le bruit connu comme légitime
• Les métadonnées (level, tags, falsepositives) accélèrent le triage
• sigma convert compile la règle pour votre système cible SIEM

Ensuite, vous associerez ces règles aux techniques de l’adversaire avec MITRE ATT&CK.