SIEM Rules

Les règles SIEM se présentent généralement sous deux formes : des règles fournies par le fournisseur SIEM pour offrir des fonctionnalités « prêtes à l'emploi » permettant de détecter les attaques génériques et les modèles suspects, et des règles rédigées par des humains qui sont élaborées par les défenseurs de l'organisation lorsqu'ils savent ce qui constitue une activité normale et ce qui ne l'est pas. Mais que sont-elles réellement ? Il s'agit de requêtes de recherche qui recherchent une activité spécifique, en examinant toutes les données importées ou en temps réel qui sont introduites dans la solution SIEM. Si la requête de règles correspond à une donnée, différentes actions peuvent être déclenchées, telles que la génération d'une alerte, l'envoi d'un e-mail à une équipe ou l'enregistrement de l'activité dans un emplacement distinct. Ces requêtes de recherche peuvent être exécutées en continu (détection en temps réel) ou configurées pour être exécutées à des heures précises, par exemple tous les jours ou toutes les semaines.

Exemples de fonctionnalités des règles SIEM

Nous pouvons créer des règles pour détecter une quantité infinie d'activités, à condition que le SIEM saisisse les journaux requis. Vous trouverez ci-dessous certains des éléments que nous pouvons surveiller :

Authentification/activité du compte :

• Tentatives d'ouverture de session ayant échoué
• Tentatives de connexion réussies (ou échouées) à des comptes désactivés
• Utilisation de comptes spécifiques (administrateur local, administrateur, administrateur de domaine)
• Modifications du SID (Security Identifier) apportées à un compte (indicateur potentiel d'une augmentation des privilèges)

Exécution du processus :

• Exécution à partir d'emplacements inhabituels (tels que des répertoires temporaires ou des caches de navigateur ; cela peut indiquer l'exécution de programmes malveillants ou des mécanismes de persistance)
• Relations entre processus suspectes (par exemple, Microsoft Word générant un processus enfant de CMD ou PowerShell Window (potentiellement une macro malveillante exécutant du code))
• Hachages incorrects connus (hachages MD5, SHA1, SHA256 générés à partir de fichiers malveillants confirmés)

Activité du réseau :

• Scans de ports
• Énumération des services
• Découverte d'hôtes

Réduction et réglage des faux positifs

Les faux positifs sont des alertes qui ont été générées mais qui ne constituent pas réellement un événement malveillant. Par exemple, une règle qui surveille l'ID d'événement Windows 4625 (« Un compte n'a pas pu se connecter »). La surveillance de ce journal nous indiquera lorsqu'un compte ne parvient pas à se connecter correctement. Tout le monde a saisi un mot de passe erroné une ou deux fois. La création d'une règle qui détecte les occurrences uniques d'échecs de connexion n'apportera pas beaucoup de valeur et sera très bruyante (ce qui signifie que cela générera BEAUCOUP d'alertes). Des seuils peuvent être définis pour permettre un meilleur contrôle sur ce qui se passe lorsque les recherches renvoient des résultats à partir de données agrégées. Nous pouvons définir un seuil de règle. Ainsi, si un compte ne parvient pas à se connecter 10 fois en 10 minutes, il faut générer une alerte. Cela peut nous aider à identifier les attaques dans lesquelles un acteur malveillant tente de se connecter à un compte en devinant le mot de passe (attaques par force brute ou par dictionnaire).

Dans certains cas, il peut être nécessaire de modifier la règle pour spécifier que certaines valeurs doivent être ignorées. Prenons un exemple : nous avons une règle qui examine les journaux du parefeu pour identifier les activités d'analyse réseau lorsqu'une adresse IP source envoie du trafic vers un grand nombre de systèmes internes. Notre société achète ensuite un scanner de vulnérabilité et l'installe dans un réseau interne. Elle prévoit d'effectuer des analyses de détection des hôtes afin d'identifier activement les systèmes en cours d'exécution afin que ces informations puissent être stockées et utilisées pour planifier des analyses de vulnérabilité à l'avenir. Pendant que le scanner envoie du trafic vers toutes les adresses IP potentielles de sa plage cible définie, cette règle émet une alerte en cas d'activité qui n'est pas malveillante. Si l'équipe de sécurité le juge approprié, elle peut choisir d'exclure cette adresse IP source de la règle. Ainsi, lorsque le scanner sera activé, l'activité sera observée par le SIEM, mais la règle lui interdit de déclencher une alerte lorsque cette adresse IP source spécifique est détectée. Nous avons désormais empêché la génération de faux positifs à l'avenir.

Rédaction de requêtes de recherche et d'alertes

Nous aborderons ce point dans la section suivante, dans laquelle vous allez configurer votre propre version locale de Splunk SIEM et apprendre à rédiger des requêtes de recherche pour trouver des informations spécifiques dans un ensemble de données contenant des centaines de milliers de journaux. Une fois que vous savez comment rédiger des requêtes de recherche, vous pouvez l'appliquer pour configurer des alertes !

Avant de passer à cette section, nous vous recommandons de lire cette page sur la création de règles de détection dans la pile ELK, une alternative open source au SIEM. Pendant que nous allons l'utiliser

Splunk , cela vous donnera certainement un bon aperçu de la logique qui sous-tend les règles ! — https://www.elastic.co/guide/en/security/current/rules-ui-create.html