Supervision SIEM

L'acronyme SIEM signifie Security Information and Event Management (gestion des informations et des événements de sécurité). Un SIEM décrit les fonctionnalités de surveillance de la sécurité par la collecte, le filtrage, la normalisation, la corrélation et la visualisation des événements de sécurité. Il combine la gestion des informations de sécurité (SIM) et la gestion des événements de sécurité (SEM).

Un SIEM gère les événements de sécurité, qui peuvent provenir d'un log ordinaire (par exemple logs d'un Apache), du log d'un outil de sécurité spécifique (logs d'un firewall, IDS, honeypot, EDR, et cætera) ou d'événements enrichis provenant d'un autre outil (un autre SIEM).

Pandora FMS SIEM est responsable du traitement des entrées logs obtenues par votre collection, de la normalisation des données et de la génération d'événements de sécurité basés sur ces entrées.

Comme pour la collecte logs, les événements SIEM générés sont stockés dans OpenSearch®, donc la première condition pour que cette surveillance fonctionne est d'avoir une Installation OpenSearch.

Pandora FMS SIEM génère les événements de sécurité à l'aide de deux composants dans le serveur, de sorte que les événements sont également générés en deux étapes:

• Normalisation des données: Toutes les entrées de la collection logs sont décodées, générant de nouvelles entrées logs normalisées qui sont stockées temporairement.
• Génération d'événements: La conformité des logs normalisés à un ensemble de règles est vérifiée, auquel cas un événement SIEM est produit avec toutes les informations relatives aux règles et le log normalisé à l'origine de l'événement.

Le flux complet de la surveillance SIEM est donc le suivant:

• Les agents, plugins et autres sources d'information surveillent ou génèrent des logs qui sont envoyés au dataserver ou au syslogserver.
• Le dataserver et le syslogserver se chargent de traiter ces entrées logs et de les stocker sur le serveur OpenSearch configuré pour la collecte des logs.
• siemserver décode tous les logs obtenus par la collecte des logs pour générer des logs normalisés sur le serveur OpenSearch configuré pour la surveillance SIEM. Ces logs normalisés sont stockés temporairement.
• siemevents traite chacun des logs normalisés et s'ils répondent à un ensemble de règles prédéfinies, des événements SIEM sont générés et stockés sur le serveur OpenSearch configuré pour la surveillance SIEM.

Avec les événements générés, il est possible de les consulter pour leur fonctionnement à partir de la console Pandora FMS.

Pour utiliser la surveillance des événements SIEM, il faut d'abord l'activer à partir de la configuration principale.

Menu Management → Settings → System Settings → SIEM → Activate SIEM,remplissez complètement le formulaire et cliquez sur Update pour enregistrer les modifications.

Cela créera les modèles nécessaires sur le serveur OpenSearch spécifié pour la normalisation des logs et la génération d'événements SIEM.

Il activera également ce type de surveillance dans les serveurs Pandora FMS où siemserver et siemevents ont été lancés.

Pour effectuer la surveillance des événements SIEM, il est nécessaire d'activer les serveurs siemserver et siemevents dans la configuration du serveur.

Pour décoder et normaliser les entrées de la collection logs, il sera nécessaire de disposer de fichiers de décodage XML qui établissent la manière d'obtenir les informations nécessaires dans chaque cas (ci-après, “decoders”). Ces fichiers XML seront situés dans le chemin indiqué par le paramètre siem_decoders de la configuration du serveur, par défaut dans:

/usr/share/pandora_server/util/siem/decoders

Afin de générer des événements SIEM, il sera nécessaire de disposer de fichiers XML de règles qui établissent les conditions pour générer un événement sur la base des informations obtenues dans les logs standardisés (ci-après, “rules”). Ces fichiers XML seront situés dans le chemin indiqué par le paramètre siem_events_rules de la configuration du serveur, par défaut dans:

/usr/share/pandora_server/util/siem/rules

La majeure partie de la collecte des logs est effectuée par les agents du logiciel Pandora FMS. Ces agents, tant dans les systèmes GNU/Linux® que MS Windows®, disposent de types de modules spécifiques pour effectuer cette tâche.

La surveillance SIEM dépend fortement du type de log collecté, il sera donc nécessaire de spécifier module_source_type dans les modules de collecte logs pour indiquer ce type.

Le type est utilisé par les decoders et les rules, il convient donc de consulter les decoders et les rules actifs pour savoir quel type indiquer dans chaque log.

Les types logs les plus couramment utilisés sont les suivants:

• syslog
• ids
• web-log
• squid
• windows
• host-information
• ossec

La collecte des logs sur les systèmes Linux se fait principalement par la lecture des fichiers log. Ceci peut être réalisé en utilisant des configurations de modules avec cette structure minimale:

module_begin
module_name <program_name>
module_type log
module_regexp <path_to_log_file>
module_pattern <capture_regexp>
module_source_type <log_type>
module_end

Par exemple, pour collecter toutes les entrées de connexion log d'un serveur Apache:

module_begin
module_name apache
module_type log
module_regexp /var/log/httpd/access_log
module_pattern .*
module_source_type web-log
module_end

Les entrées collectées à partir d'un log comme ci-dessus seraient normalisées par des decoders tels que web-accesslog, web-accesslog-ip ou web-accesslog-domain, entre autres.

Les logs décodés d'un log comme ci-dessus pourraient générer des événements tels que Common web attack, XSS (Cross Site Scripting) attempt ou SQL injection attempt entre autres.

Sous MS Windows®, la collecte des logs se fait principalement en surveillant les événements du système, bien qu'elle puisse également se faire en lisant les fichiers log comme sur les systèmes Linux.

En utilisant le système d'événements Windows, ces logs peuvent être collectés en utilisant des configurations de modules avec l'une des deux configurations minimales.

Dans le cas d'événements de type Application, System ou Security:

module_begin
module_name <module_name>
module_type log
module_logevent
module_source <Application|System|Security>
module_source_type <log_type>
module_end

Ou s'il s'agit d'événements sur un autre canal:

module_begin
module_name <module_name>
module_type log
module_logchannel
module_source <log_channel_path>
module_source_type <log_type>
module_end

Par exemple, pour collecter toutes les entrées d'événements de l'application Security et Windows Defender:

module_begin
module_name Windows_LogEvents_System
module_type log
module_logevent
module_source Security
module_source_type ossec
module_end

module_begin
module_name Windows_LogchannelEvents_WindowsDefender
module_type log
module_logchannel
module_source Microsoft-Windows-Windows Defender/Operational
module_source_type ossec
module_end

Les données recueillies à l'occasion d'événements tels que ceux mentionnés ci-dessus sont normalisées par decoders como windows_eventchannel.

Les logs décodés d'événements tels que ceux mentionnés ci-dessus pourraient générer des événements tels que Windows error event, Short-time multiple Windows Defender warning events ou Multiple Windows Defender error events entre autres.

En utilisant la surveillance du fichier log, la configuration est identique à celle des systèmes Linux. Une configuration minimale comme celle-ci est nécessaire:

module_begin
module_name <program_name>
module_type log
module_regexp <path_to_log_file>
module_pattern <capture_regexp>
module_source_type <log_type>
module_end

Par exemple, pour collecter toutes les entrées de journal d'un serveur X:

module_begin
module_name xserver
module_type log
module_regexp C:\server\logs\xserver.log
module_pattern .*
module_source_type xserver
module_end

Lorsque la surveillance SIEM est activée et configurée, un aperçu de l'état de la surveillance est accessible dans le menu Operation → SIEM → Dashboard.

Les événements SIEM générés peuvent être consultés dans leur intégralité dans le menu Operation → SIEM → Events.

Chaque événement SIEM dispose d'une fenêtre de détails sur l'événement SIEM, affichant des informations sur le log normalisé et la règle qui a généré l'événement.

En fonction des decoders qui ont normalisé le log, l'événement aura un onglet Dynamic fields avec des informations utiles sur le log.

En fonction de la règle qui a généré l'événement, des onglets MITRE ATT&CKS® et SIEM groups contiennent des informations utiles sur l'impact de l'événement.

Pandora FMS inclut par défaut une série de decoders pour la surveillance SIEM, mais tout administrateur peut inclure ses propres decoders.

Pour inclure de nouveaux decoders, vous devez d'abord ajouter ou éditer un fichier XML dans le chemin indiqué au Pandora FMS server dans son paramètre de configuration siem_decoders.

Les décodeurs sont chargés dans l'environnement via des fichiers XML que le serveur Pandora FMS master lit à chaque démarrage du service.

Une fois que les décodeurs sont chargés, leur configuration est stockée dans la base de données, et chaque siemserver les traite pour les entrées obtenues en collectant les logs.

A partir de la console Pandora FMS, il sera possible de visualiser les decoders chargés avec leur configuration complète à partir du menu Operation → SIEM → Decoders.

Il est également possible de désactiver les decoders de cette vue, afin que siemserver ne les prenne pas en compte lors de la normalisation des entrées log.

Les decoders sont configurés et chargés dans Pandora FMS avec des fichiers XML. Ces fichiers peuvent avoir la syntaxe valide suivante:

<var name="VarName">VarValue</var>
 
<decoder name="DecoderName" discard="yes|no">
    <parent>DecoderName</parent>
    <program_name>REGEXP</program_name>
    <type>EventType</type>
    <prematch type="pcre2">REGEXP</prematch>
    <prematch offset="after_parent">REGEXP</prematch>
    <prematch offset="after_prematch">REGEXP</prematch>
    <regex type="pcre2">REGEXP</regex>
    <regex offset="after_parent">REGEXP</regex>
    <regex offset="after_regex">REGEXP</regex>
    <order>Field1, Field2.Sub1, Field2.Sub2</order>
    <json_null_field>string|discard</json_null_field>
</decoder>

• var: Utilisé pour indiquer les variables avec leurs valeurs, pour une utilisation ultérieure dans XML ($VarName).
• decoder: Il s'agit de l'information sur le decoder, avec son nom. Un seul fichier XML peut contenir plusieurs decoders.

1. name: C'est le nom du decoder. Plusieurs decoders peuvent avoir le même nom, et tous sont évalués.
2. discard: Avec une valeur yes ou no, permet aux logs d'être écartés de l'évaluation des decoders s'ils correspondent à celui-ci. Les decoders avec discard=“yes” sont évalués avant les autres (tant qu'ils n'ont pas de decoder parent).

• parent: Spécifie le nom du decoder parent pour générer une structure hiérarchique.
• program_name: Le nom du programme à trouver dans les en-têtes log ou dans le source_id log.

1. type: Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, OS Regex est utilisé.

• type: Le type de logs pour lequel le decoder doit être comparé. Il doit correspondre au type du log.
• prematch: Si le contenu de log correspond, il génère un log normalisé.

1. type: Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, OS Regex est utilisé.

• regex: Les groupes capturés avec cette expression régulière sont des informations normalisées pour log.

1. type: Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, OS Regex est utilisé.

• order: Les valeurs capturées par les expressions rationnelles sont stockées dans ces noms de champs, dans l'ordre des groupes de capture.
• json_null_field: Les valeurs nulles dans les groupes de capture sont stockées sous forme de chaîne vide ou rejetées.

• offset: Utilisé pour indiquer l'ordre dans lequel les vérifications sont effectuées et pour écarter du contenu de log pour les vérifications suivantes le texte correspondant à l'expression régulière : after_parent, after_regex, after_prematch. Par exemple:

<decoder name="my_decoder">
  <prematch type="pcre2">^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d </prematch>
  <regex type="pcre2" offset="after_prematch">(\w):(\d+)</regex>
  <order>srcip,srcport</order>
</decoder>

Il vérifiera que le texte log correspond à l'expression régulière ^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d , écartera ce contenu du texte et, lors de l'évaluation de l'expression régulière regex, il capturera ce qui est approprié. Dans l'exemple, je supprimerais une date du texte lors de l'évaluation pour simplifier les groupes de capture.

Pandora FMS inclut par défaut une série de rules pour la surveillance SIEM, mais tout administrateur peut inclure ses propres rules.

Pour inclure de nouvelles rules, vous devez d'abord ajouter ou éditer un fichier XML dans le chemin indiqué au serveur Pandora FMS dans son paramètre de configuration siem_rules.

Les rules sont chargées dans l'environnement via des fichiers XML que le serveur Pandora FMS master lit à chaque démarrage du service.

Une fois que les rules sont chargées, leur configuration est stockée dans la base de données, et chaque serveur siemevents les traite pour les entrées de surveillance SIEM normalisées.

Depuis la console du Pandora FMS, il sera possible de visualiser les rules chargées avec leur configuration complète à partir du menu Operation → SIEM → Rules.

Il est également possible de désactiver rules de cette vue, afin que siemevents ne les prenne pas en compte lors du traitement des logs normalisés.

Les rules qui n'ont pas pu être lues à partir des fichiers XML seront marquées dans la console comme “non actives” et ne seront pas prises en compte lors de la génération d'événements SIEM. Les rules qui ont été désactivées manuellement par un administrateur ne seront pas non plus prises en compte. Par conséquent, pour que les rules soient évaluées, elles doivent être actives et activées.

Les rules sont classées en plusieurs niveaux, allant du plus bas (0) au plus haut (15). Le tableau suivant décrit chaque niveau et fournit des informations sur la gravité de chaque événement généré par la surveillance SIEM.

En fonction de ces niveaux, les événements auront une gravité spécifique qui sera affichée dans la Console:

• Informational: Niveaux 0 à 6.
• Normal: Niveaux 7 à 8.
• Warning: Niveaux 9 à 11.
• Critical: Niveaux 12 à 15.

<var name="VarName">VarValue</var>
 
<group name="GROUP1,GROUP2,">
    <rule id="N" level="N" frequency="N" timeframe="N" ignore="N" overwrite="yes|no">
        <if_matched_sid>N</if_matched_sid>
        <if_matched_group>GROUP</if_matched_group>
        <same_id />
        <different_id />
        <same_field>Field1</same_field>
        <same_field>Field2.Sub1</same_field>
        <different_field>Field1</different_field>
        <different_field>Field2.Sub1</different_field>
        <description>TEXT</description>
        <match type="pcre2">RREGEXP</match>
        <match negate="yes|no">RREGEXP</match>
        <regex type="pcre2">RREGEXP</regex>
        <regex negate="yes|no">RREGEXP</regex>
        <decoded_as>DecoderName</decoded_as>
        <category>EventType</category>
        <field name="Field1">REGEXP</field>
        <field name="Field2.Sub1" negate="yes|no">REGEXP</field>
        <program_name negate="yes|no">REGEXP</program_name>
        <time>TIME-RANGE</time>
        <weekday>DAYS</weekday>
        <if_sid>PARENT1, PARENT2</if_sid>
        <if_group>GROUP</if_group>
        <if_level>N</if_level>
        <info type="text|link|cve">TEXT|LINK|CVE</info>
        <group>GROUP1,GROUP2,</group>
        <mitre>
            <id>MITRE_ID</id>
            <id>MITRE_ID</id>
        </mitre>
    </rule>
</group>

• var: Utilisé pour indiquer les variables avec leurs valeurs, pour une utilisation ultérieure dans XML ($VarName).
• group: Permet de regrouper des règles. Il est également utilisé pour les conditions des mêmes règles.
• rule: Il s'agit de l'information contenue dans la règle :

1. id: Identifiant de la règle. Il doit être unique (à moins qu'une autre règle ne soit écrasée).
2. level: Niveau de l'événement lorsqu'il est généré (0 à 15). Les règles de niveau 0 ne génèrent pas d'événement.
3. frequency: Nombre de fois qu'une simultanéité doit se produire pour générer un événement. La fréquence indiquée dans les règles est vérifiée pour les logs du même agent, et non pour n'importe quel log.
4. timeframe: Fenêtre temporelle dans laquelle les concordances doivent être données (secondes).
5. ignore: Cette règle remet à zéro les compteurs de frequency après ces secondes.
6. overwrite: Avec une valeur yes ou no, elle permet d'écraser la configuration d'une règle avec le même ID. Si avec overwrite=“yes” la règle a level=“0”, elle est évaluée avant toute autre règle et en cas de correspondance avec le log, elle écarte l'évaluation du reste des règles pour ce log.

• if_matched_sid: La règle est satisfaite si une autre règle avec l'ID indiqué a déclenché une alerte les fois indiquées par frequency dans le timeframe.
• if_matched_group: Comme if_matched_sid mais pour les groupes.
• same_id: Les devises ayant le même numéro d'identification doivent être indiquées.
• different_id: Les devises ayant des identifiants différents doivent être indiquées.
• same_field: Il doit y avoir des concomitances avec les mêmes valeurs dans le champ.
• different_field: Les concomitances doivent se produire avec des valeurs différentes dans le champ.
• description: Le texte de l'événement à générer.
• match: Si le contenu de log correspond, un événement SIEM est généré.

1. type: Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, OS Regex est utilisé.
2. negate: Avec une valeur de yes, il permet de refuser la correspondance.

• regex: Identique à match.

1. type: Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, OS Regex est utilisé.
2. negate: Avec une valeur de yes, il permet d'annuler l'expression régulière.

• decoded_as: La règle est satisfaite si le log a été décodé par le decoder spécifié.
• category: La règle est satisfaite si le type du decoder correspond.
• field: Si le champ indiqué correspond à la valeur, il est conforme à la règle.

1. negate: La valeur oui permet de refuser la correspondance avec le champ.

• program_name: Si l'origine de log correspond, la règle est respectée.

1. negate: Avec une valeur de oui, il permet de refuser les correspondances avec l'origine log.

• time: Si l'événement est généré dans l'intervalle de temps indiqué, la règle correspond.
• weekday: Si l'événement est généré ces jours-là, la règle est conforme aux dispositions suivantes (monday - sunday, weekdays, weekends).
• if_sid: La règle est satisfaite si l'une des règles parentes est satisfaite.
• if_group: La règle est satisfaite si l'enregistrement satisfait à toute autre règle du groupe spécifié.
• if_level: La règle est satisfaite si une autre règle de même niveau a été satisfaite.
• info: Informations supplémentaires sur l'événement généré.
• group: Liste des groupes dans la règle.
• mitre: Liste des ID MITRE de la règle.

Les variables peuvent être utilisées dans la description et dans info avec les valeurs des champs personnalisés, par exemple : $(Field1), $(Field2.Sub1), $(Field2.Sub2).

Les expressions régulières sont des séquences de caractères qui définissent un motif.

Il existe deux types d'expressions régulières valables pour les decoders et les rules: OS Regex y PCRE2.

Il s'agit d'expressions régulières simples basées sur une bibliothèque en langage C. Elle est conçue pour être simple tout en prenant en charge les expressions régulières les plus courantes.

Pour utiliser les caractères suivants, vous devez les échapper avec \:

• Les modificateurs * et + ne peuvent être appliqués qu'aux expressions avec barre oblique inverse, et non aux caractères simples (par exemple, + est pris en charge, 0+ ne l'est pas).
• Vous ne pouvez pas utiliser l'alternance dans un groupe, par exemple (foo|bar) n'est pas autorisé.
• Les retours en arrière complexes ne sont pas pris en charge, par exemple \p*d*\s*\w*: ne correspond pas à un seul deux-points car \p* consomme les deux deux-points.
• . correspond à un point littéral, tandis que \. correspond à n'importe quel caractère.
• \s ne correspond qu'à un espace ASCII (32), pas à d'autres espaces tels que les tabulations.
• Il n'existe pas de syntaxe pour faire correspondre un caret, un astérisque ou un caractère plus littéral (bien que fasse correspondre un astérisque ou plus, ainsi que d'autres caractères).

Perl Compatible Regular Expression (PCRE2) offre des fonctionnalités telles que les motifs récursifs, les assertions de type “look-ahead” et “look-back”, les groupes de non-capture, les quantificateurs non-voraces, une syntaxe étendue pour les caractères et les classes de caractères, entre autres.

Pour plus de détails, voir la Documentation syntaxique CPRE2.

Retour à l'index de la documentation du Pandora FMS