7.5.4. Analyse des alertes Sigflow

7.5.4.1. Introduction

Pour plus d'informations, voir les paragraphes suivants :

7.5.4.1.1. Gestion du moteur Sigflow

Pour les informations sur le moteur, voir le paragraphe Visualisation de l'état du moteur.
Pour les informations sur la mise à jour du moteur, voir le paragraphe Mise à jour du moteur.
Pour les informations sur la configuration du moteur, voir le paragraphe de Configuration du moteur.

7.5.4.1.2. Événements générés par le moteur

Les événements générés par Sigflow sont :

des événements de type "alerte" lorsque le moteur a trouvé une correspondance avec la signature définie dans les règles d'alerte
des événements de type "fileinfo" lorsque le moteur Sigflow a reconstruit le flux réseau files
des événements de type "metadata" lorsque le moteur Sigflow a reconnu le flux réseau protocoles

7.5.4.1.2.1. Événements de type "alerte"

Les événements de type "alerte" sont générés lorsque le moteur a trouvé une correspondance avec la signature définie dans les règles d'alerte.

Celles-ci sont affichées :

Dans l’interface principale nommée Web UI du GCenter, dans l’écran `Alerts`

L’interface principale nommée Web UI est décrite dans le Présentation de la WebUI.

Il est possible de visualiser la signature trouvée et sa définition.
- Pour visualiser les alertes, sélectionner le filtre moteur `Sigflow`.
  
  Voir la présentation de l'Ecran `Alerts` de la WebUI.
- Cliquer sur l'alerte sélectionnée.
  
  La fenêtre `Alert details` est affichée.
  
  Les informations détaillées de cette alerte sont affichées dans l'Exemple d’alerte Sigflow dans la WebUI.
  
  Les compteurs affichés sont indiqués dans l'annexe Structure des données du journal de bord du moteur.
Dans l'interface nommée Kibana UI
- Dans l'interface principale WebUI, pour visualiser les alertes, sélectionner le filtre moteur `Sigflow`.
  
  L'écran affiche uniquement la liste des alertes Sigflow.
- Après avoir sélectionné l'alerte, cliquer sur la commande `Open flow details` du menu `Actions`.
  
  Voir la présentation de l'Ecran `Alerts` de la WebUI.
  
  Kibana est ouvert dans la catégorie `Sigflow` de la section `Alerts `.
  
  L'interface affichée est l'interface nommée Kibana UI (décrite dans l'Interface graphique Kibana).
- Cliquer sur l'onglet `Messages` (1).
  
  La base de données Kibana est filtrée avec les filtres :
  - network.flow_id: ID unique du flux sélectionné
  - event.module: sigflow_alert
  Cette page affiche toutes les alertes détectées par Sigflow dans ce flux réseau (quelles que soient les adresses IP ou la direction).
- Cliquer sur l'icône (2) à gauche de l'alerte.
  
  La fenêtre `Expanded document` (3) est affichée.
  
  Les informations détaillées de cette alerte peuvent être consultées sous forme de tableau ou au format json (voir le paragraphe Événements de type "alerte").
  
  Les compteurs affichés sont donnés dans l'annexe Structure des données du journal de bord du moteur.
  
  Note
  
  L'interface KibanaUI est également accessible sans filtre via l'icône `Hunting` sur la barre de menu de gauche dans la WebUI.

7.5.4.1.2.2. Événements de type "fileinfo"

Les événements de type "fileinfo" sont générés lorsque le moteur Sigflow a reconstruit le flux réseau files.

Ces événements fileinfo sont visibles dans l'interface Kibana.

Cliquer sur l'icône `Hunting` de la `WebUI`.

L'interface affichée est l'interface nommée Kibana UI (décrite dans l'Interface graphique Kibana).

Cliquer sur la section `Network Metadata` (2) puis sur la catégorie `File Transactions` (1).
Cliquer sur l'onglet `Messages` (3).

Cette page affiche tous les événements de type fileinfo correspondant aux fichiers reconstruits dans ce flux de réseau.
- Cliquer sur l'icône (1) à gauche de l'alerte.
Les informations détaillées (2) de cet événement peuvent être consultées sous forme de tableau ou au format json.

Note

L'interface KibanaUI est également accessible sans filtre via l'icône `Hunting` sur la barre de menu de gauche dans la WebUI.

7.5.4.1.2.3. Événements de type "metadata"

Les événements de type "metadata" sont générés lorsque le moteur Sigflow a reconnu les protocoles du flux réseau.

Ces événements metadata sont visibles dans l'interface Kibana.

Cliquer sur l'icône `Hunting` de la `WebUI`.

L'interface affichée est l'interface nommée Kibana UI (décrite dans l'Interface graphique Kibana).

Cliquer sur la section `Network Metadata` puis sur la catégorie de protocole (HTTP par exemple).
Cliquer sur l'onglet `Messages`.

Cette page affiche tous les événements de type métadonnées (metadata) correspondant au protocole détecté dans ce flux de réseau.
Sélectionner la flèche à gauche de l'événement.

Les informations détaillées de cet événement peuvent être consultées sous forme de tableau ou au format json.

7.5.4.1.3. Informations essentielles pour comprendre le contexte de l'alerte

7.5.4.1.3.1. Quels sont les champs clés d'une alerte et leur signification ?

Avant d’entreprendre toute enquête ou qualification de l’alerte, il est essentiel de commencer par observer plusieurs éléments qui fourniront des informations essentielles pour comprendre le contexte de l’alerte.

Ces informations sont visibles soit dans l’interface Web UI, soit dans l’interface Kibana UI.

Dans l'interface principale nommée Web UI du GCenter
- Ouvrir la fenêtre `Alert details`.
  
  La procédure détaillée est donnée ci-dessous.
- Cliquer sur l'onglet `Details`.
  
  Les éléments clés comprennent :
  - `category` pour connaître l’id de l’alerte et la gravité, utile pour classer les alertes.
  - `sigflow` pour avoir les informations importantes concernant le déclenchement de l’alerte.
    
    La partie `metadata` affiche précisément la charge utile qui déclenche l’alerte.
  - `Network` pour avoir les informations relatives au protocole utilisé pour déclencher l’alerte et également le vlan utilisé.
  - `source` et `destination` pour avoir les éléments concernant le port et l’adresse ip pour la source et la destination.
  - Pour le reste des éléments, le champ le plus intéressant sera le `start` du `flow`.
    
    Il permet de sélectionner une fenêtre de temps pour réaliser les recherches.
Dans l'interface Kibana UI
- Ouvrir la fenêtre `Alerts-Sigflow - Messages`.
  
  La procédure détaillée est donnée ci-dessous.
  
  Les éléments clés comprennent :
  - `timestamp:`
    
    Ce champ correspond au moment de la détection.
  - `Source IP` et `Dest. IP`
    
    Les adresses IP associées à l’alerte, source ou destination, fournissent des informations sur la communication réseau impliquée dans l’incident.
  - `Source Port` et `Dest. Port`
    
    Le port associé à l’alerte, source ou destination, fournit des informations sur la communication réseau impliquée dans l’incident.
  - `Sigflow affected product`
    
    Lorsque cela est possible, il y a une spécification sur le produit par rapport à l’alerte.
    
    L’exactitude de ce champ est très relative, il peut s’agir d’une version d’apache ou d’éléments comme `Web_Browsers` ou `Windows_XP_Vista_7_8_10_Server_32_64_Bit`.
  - `Sigflow.signatures`
    
    Ceci affichera le titre de l’alerte, la partie "msg" qui décrit l’élément détecté par l’alerte.
    
    Pour information, si ce champ contient `ET POLICY` ou `ET INFO`, considérer cette alerte comme une alerte d’information ou une alerte de profil bas.
    
    Ils montrent qu’il y a une configuration qui ne correspond pas aux bonnes pratiques.
    
    Ils peuvent être utilisés pour un contexte supplémentaire sur d’autres alertes.

7.5.4.2. Procédure de traitement d'une alerte

7.5.4.2.1. Comment vérifier l'exactitude d'une alerte et déterminer si elle représente une menace réelle ?

Sigflow utilise des règles pour effectuer des détections.
Il faut traiter le sujet de la vérification de l’exactitude d’une alerte Sigflow et déterminer si elle représente une menace réelle ou non impliquant une combinaison de techniques d’analyse.
Voici quelques mesures à prendre :

Comprendre l’alerte :
- Comprendre la règle qui a déclenché l’alerte, les adresses IP source et de destination, les numéros de port et toute information supplémentaire fournie.
- Toutes ces informations se trouvent dans GCenter :
  - dans la WebUI, dans la fenêtre `Alert details` de l'écran `Alert` : examiner attentivement les détails de l'alerte Sigflow
  - dans Kibana, pour mieux comprendre l'alerte, ouvrir la fenêtre `Expanded document` de la section `Alerts `, catégorie `Sigflow`, onglet `Messages`
- Aux fins du compte rendu, si vous avez une alerte contenant les étiquettes `ET POLICY` ou `ET INFO`, prenez-la comme une alerte d’information.
  
  Ils affichent le fait qu’il y a une configuration qui ne correspond pas aux bonnes pratiques.
  
  Ils peuvent être utilisés pour un contexte supplémentaire sur d’autres alertes.
Analyse des règles :
- Examiner la règle qui a généré l’alerte.
  
  Comprendre les conditions qui ont déclenché l’alerte et le niveau de gravité qui lui est attribué.
  
  Certaines règles peuvent être plus génériques et générer de faux positifs, tandis que d’autres peuvent être plus spécifiques.
- Différents éléments concernant les faux positifs :
- Vrai faux positif, c’est une règle qui a été déclenchée et qui indique une menace quand il n’y en a pas.
- Signature bruyante, c’est une alerte déclenchée par une activité normale qui est identifiée mais la règle n'a pas été supprimée.
  
  Ce cas peut arriver lorsque, par exemple, un script effectue des actions automatiques qui peuvent être associées à une activité malveillante si elle n’est pas effectuée par la machine de supervision.
Analyse historique et comparaison de référence :
- Examiner les données historiques et les tendances.
  
  Analyser si des alertes similaires ont été émises dans le passé et s’il existe une tendance de menaces récurrentes.
  
  L’analyse historique peut aider à identifier les menaces persistantes ou évolutives.
- Agréger toutes les alertes par machine ou rechercher la régularité de l’événement dans le temps.
- En agrégeant la vue des alertes, rechercher l’apparition des alertes pour voir si c’est la seule alerte de ce type.
  
  En cas d’alerte multiple sur cet hôte, enregistrer-la et qualifier cette alerte.
  
  Parfois, les alertes sont trop importantes et peuvent être déclenchées même s’il n’y a rien à craindre.
- S'il y a des doutes sur les faux positifs, regarder le point suivant dans la documentation «Que se passe-t-il si une alerte de ce moteur est identifiée comme un faux positif» ?
- Une fois l'évaluation terminée et après avoir déterminé si l’alerte est récurrente ou non, approfondir l’analyse jusqu’à l’analyse de la charge utile.
Analyse de la charge utile :
- Analyser la charge utile associée à l’alerte.
  
  Cette information sera trouvée dans les détails de l’alerte (vu au premier point).
- Pour analyser la charge utile, utiliser les champs suivants `Sigflow.payload_printable`.
  
  Par exemple, pour identifier un domaine malveillant.
- Utiliser également le champ `Sigflow.payload` lorsque la charge utile est codée.
  
  Par exemple, pour reconstruire et regarder à l’intérieur d’une archive envoyée par stealer à son C2 et encoder en b64.
Corrélation avec d’autres événements :
- Il est obligatoire de croiser les alertes avec les journaux d’autres moteurs.
  
  Une approche à plusieurs niveaux peut aider à confirmer la validité d’une alerte.
- Pour vous aider dans cette tâche, réduire la portée de l'analyse en explorant les IP sources/destinations, le port et une fenêtre de temps sur laquelle la première alerte a été identifiée.
Intégration du renseignement sur les menaces :
- Pour être sûr et pour avoir plus d’informations pour agir, obtenir des détails sur les alertes d’orroborate avec des indicateurs connus de compromission (ICO) provenant de sources de renseignements sur les menaces.
Procédures d’intervention en cas d’incident:
- Si une alerte est jugée authentique, suivre le plan d’intervention de votre organisation pour atténuer et contenir la menace.
- Quelques pistes pour permettre une analyse plus approfondie des événements sont données dans la partie «Quelles réponses sont nécessaires si la menace est confirmée ? »

7.5.4.2.2. Comment catégoriser la menace en fonction des informations recueillies ?

La catégorisation des menaces basée sur les informations produites par le moteur Sigflow implique :

d’analyser les alertes
de les classer dans différentes catégories de menaces

Les informations devront être recoupées pour engager d’autres actions.

Pour catégoriser les menaces :

Niveaux de gravité :
- Commencer par examiner les niveaux de gravité attribués aux alertes Sigflow.
  
  De nombreuses règles comportent des niveaux de gravité prédéfinis (p. ex., élevé, moyen, faible).
  
  Utiliser ces niveaux de gravité comme indicateur initial de la menace potentielle.
- Toutes ces informations se trouvent dans le GCenter :
  - dans le WebUI, dans la fenêtre `Alert details` de l'écran `Alert` : examiner attentivement les détails de l'alerte Sigflow
  - dans Kibana, pour mieux comprendre l'alerte, ouvrir la fenêtre `Expanded document` de la section `Alerts `, catégorie `Sigflow`, onglet `Messages`
Classification des règles :
- Classer les règles en différentes catégories en fonction de leur objectif et du type de menaces qu’elles détectent.
  
  Par exemple, les règles peuvent se concentrer sur les logiciels malveillants, les activités réseau suspectes, les tentatives d’exploitation ou les vulnérabilités connues.
- Aux fins du compte rendu, si une alerte contient les étiquettes `ET POLICY` ou `ET INFO`, la prendre comme une alerte d’information.
  
  Elles affichent le fait qu’il y a une configuration qui ne correspond pas aux bonnes pratiques.
  
  Elles peuvent être utilisés pour un contexte supplémentaire sur d’autres alertes.
- Toutes ces informations se trouvent dans le GCenter :
  - dans le WebUI, dans la fenêtre `Alert details` de l'écran `Alert` : examiner attentivement les détails de l'alerte Sigflow
  - dans Kibana, pour mieux comprendre l'alerte, ouvrir la fenêtre `Expanded document` de la section `Alerts `, catégorie `Sigflow`, onglet `Messages`
- Aux fins du compte rendu, si une alerte contient les étiquettes `ET POLICY` ou `ET INFO`, la prendre comme une alerte d’information.
- Aux fins du compte rendu, si vous avez une alerte contenant les étiquettes `ET POLICY` ou `ET INFO`, prenez-la comme une alerte d’information.
  
  Elles affichent le fait qu’il y a une configuration qui ne correspond pas aux bonnes pratiques.
  
  Si besoin, signaler l’alerte à votre organisation de sécurité.
Analyse de la charge utile :
- Examiner la charge utile des paquets réseau associés à chaque alerte.
  
  L’analyse de la charge utile peut révéler la nature de la menace, comme les signatures de logiciels malveillants spécifiques, la communication de commande et de contrôle ou les modèles de charge utile malveillante.
  
  Par exemple, pour identifier un domaine malveillant.
- Utiliser aussi le champ `Sigflow.payload`, cela dépend du cas.
  
  Par exemple, pour reconstruire et regarder à l’intérieur d’une archive envoyée par stealer à son C2 et encoder en b64.
Analyse de l’indicateur de compromission (IOC) :
- Rechercher des indicateurs de compromission dans les alertes, tels que les adresses IP, les noms de domaine, les hachages de fichiers ou les modèles spécifiques aux logiciels malveillants connus.
  
  Recouper ces indicateurs avec les flux de renseignements sur les menaces pour déterminer la nature de la menace.
- Toutes ces informations se trouvent dans GCenter, dans le panneau `Alert` ou dans Kibana, dans Sigflow sous le panneau `Messages.
- Toutes ces informations se trouvent dans le GCenter :
  - dans le WebUI, dans la fenêtre `Alert details` de l'écran `Alert` : examiner attentivement les détails de l'alerte Sigflow
  - dans Kibana, pour mieux comprendre l'alerte, ouvrir la fenêtre `Expanded document` de la section `Alerts `, catégorie `Sigflow`, onglet `Messages`
Analyse comportementale :
- Analyser le comportement du trafic réseau qui a déclenché les alertes Sigflow.
  
  Identifier les modèles de comportement suspect ou malveillant, tels que l’analyse des ports, les attaques par force brute ou les schémas de communication anormaux.
- Pour cette partie, élargir les fenêtres de temps et rechercher d’autres alertes afin de mieux comprendre le comportement.
  
  Vous ne trouverez pas nécessairement le début de l’attaque, mais avec cette analyse comportementale, vous pourrez utiliser killchain pour identifier l’étape de l’attaque.
Renseignements contextuels :
- Tenir compte des informations contextuelles, telles que les adresses IP source et destination, les ports et les protocoles concernés.
  
  Ces informations peuvent fournir des informations sur le type spécifique de menace et l’impact potentiel sur le réseau.
- Utiliser également un autre moteur de détection pour aider dans cette tâche.
  
  Par exemple, les alertes cross-reference Sigflow et le moteur Malcore permettent de savoir à quel malware vous avez affaire.
Classification d’intervention en cas d’incident :
- Si une alerte est confirmée comme une menace réelle, la classer en fonction du système de classification d’intervention de votre organisation.
  
  Il peut s’agir de catégoriser les incidents comme ayant un impact faible, moyen ou élevé et de hiérarchiser les mesures d’intervention en conséquence.
Documentation et rapports :
- Documenter les constatations et créer des rapports qui résument la catégorisation des menaces.
  
  Une documentation claire aide à comprendre la nature des menaces, à améliorer les procédures d’intervention et à partager des informations avec les parties prenantes concernées.

7.5.4.2.3. Quelles réponses à apporter en cas de confirmation de la menace ?

Note

Cette procédure permet d’approfondir l’enquête et d’évaluer l’étendue de l’incident après confirmation d’une menace générée par le moteur Sigflow.

Suivre les procédures d’intervention en cas d’incident si une alerte est jugée authentique :

suivre le plan d’intervention de votre organisation pour atténuer et contenir la menace.
en l'absence de procédure d’intervention en cas d’incident :
- Rapports et classification :
- consigner les constatations
- classer l’incident comme ayant un impact faible, moyen ou élevé
- hiérarchiser les mesures d’intervention en conséquence
- Isoler le système :
- isoler immédiatement le système contaminé
- s’assurer qu’il ne peut pas causer d’autres dommages
- Lancer la chasse aux menaces :
- lancer une chasse proactive aux menaces
- utiliser les alertes comme point de départ pour enquêter sur les menaces potentielles
- effectuer une analyse approfondie pour découvrir les menaces cachées ou avancées qui peuvent ne pas être immédiatement apparentes

Comme le moteur Sigflow nous permet de trouver un élément sur le réseau, avec cette enquête sur le réseau, une enquête sur l’hôte compromis doit être engagée.

7.5.4.2.4. Que faire si une alerte de ce moteur est identifiée comme un faux positif ?

Parfois, les alertes sont trop importantes et peuvent être déclenchées même s’il n’y a rien à craindre.

Dans ce cas:

vérifier que le trafic générant l’alerte :
- est légitime
- s’aligne sur le comportement normal du réseau
S’il apparaît que certaines règles produisent trop de faux positifs, les désactiver en modifiant le ruleset.

Important

Désactiver une règle signifie que la menace pour laquelle la règle a été créée ne sera plus détectée. Nous vous conseillons d’évaluer de près le risque de cette opération avec tous les intervenants responsables de la sécurité de l’organisation.