Splunk Crash Course - Creating Alerts

Avant d'aborder la façon de créer des alertes, voyons ce que sont réellement les alertes. Les alertes se déclenchent lorsque les résultats de recherche répondent à des conditions spécifiques, ce qui nous permet de surveiller et de détecter une activité particulière, telle qu'un échec de connexion d'un utilisateur ou une adresse IP externe scannant l'organisation. Les alertes sont déclenchées et sont ensuite généralement examinées par des analystes humains, qui effectueront le triage initial de l'événement et le transmettront aux analystes seniors si nécessaire. C'est le rôle principal des

analystes du SOC, qui consiste à trier et à analyser les alertes SIEM, tandis que les analystes seniors peuvent également être chargés de développer de nouvelles règles de détection, ainsi que d'ajuster les règles existantes afin de réduire le bruit et de les rendre plus efficaces.

Processus d'alerte

Le processus de création d'alertes peut être divisé en quatre étapes principales :

1. Requête de recherche

2. Chronologie de la recherche

3. Déclencheurs d'

4. Actions d'alerte

Nous aborderons chacune de ces étapes plus en détail ci-dessous.

1 — Requête de recherche

La première tâche consiste à décider quelle activité nous voulons générer une alerte. S'agit-il d'une adresse IP externe qui essaie de se connecter par SSH à un serveur d'entreprise ? S'agit-il d'un compte utilisateur qui présente un nombre élevé d'échecs de connexion ? S'agit-il d'une utilisation du compte d'administrateur local ? Les règles Splunk concernent essentiellement les requêtes de recherche. Nous devons donc déterminer quelle activité nous voulons détecter et comment rédiger une requête de recherche qui l'identifiera.

2 — Calendrier de recherche

Maintenant que nous avons une alerte avec une requête de recherche, nous devons définir la fréquence Splunk d'exécution de la requête de recherche pour rechercher toute activité qui crée les conditions d'alerte. Nous utiliserons principalement l'une des deux options suivantes :

• Exécutez cette requête de recherche en continu pour rechercher une activité associée en temps réel (la majorité des règles SIEM)
• Exécutez cette requête de recherche selon un calendrier défini (généralement utilisé pour identifier les modifications par rapport aux valeurs de référence et aux profils comportementaux)

3 — Déclencheur d'alerte

Si nous avons une règle qui consiste à détecter les échecs de connexion à un compte et à le faire alerter chaque fois qu'un échec de connexion est généré dans l'environnement, le SIEM va être

submergé de tonnes d'alertes. Pour y remédier, nous pouvons créer des seuils au sein de l'alerte. Par exemple, tout le monde se trompe parfois de mot de passe, mais se tromper de mot de passe 5 ou 6 fois de suite n'est pas un comportement normal. Nous pouvons créer une alerte qui recherche les échecs de connexion provenant des contrôleurs de domaine Windows à l'aide des journaux d'événements Windows et définir un seuil de 6 par utilisateur. Désormais, lorsqu'un compte rencontre 6 échecs de connexion, une alerte est générée. Nous pouvons également combiner des seuils avec des plages horaires. Ainsi, si un compte ne parvient pas à se connecter 6 fois en 5 minutes, générez une alerte.

4 — Action d'alerte

C'est ici que nous déterminons ce qui se passe réellement lorsqu'une alerte se déclenche. Certaines des actions par défaut incluent :

• Envoi d'une notification par e-mail (généralement utilisée pour les événements très médiatisés nécessitant une réponse immédiate de la part d'analystes expérimentés)
• Ajouter une alerte à la liste des alertes récemment déclenchées (c'est ainsi que les analystes peuvent identifier les alertes et travailler à leur analyse)
• Enregistrez et indexez les événements d'alerte consultables (cela permet en fait aux analystes de visualiser rapidement toutes les informations relatives à l'alerte qui a déclenché)

Splunk permet également aux administrateurs d'écrire leurs propres actions personnalisées à l'aide de webhooks, afin que des messages puissent être créés dans leurs propres applications, telles qu'une application mobile qui informe les analystes lorsqu'une nouvelle alerte a été déclenchée et doit être examinée.

Création de vos propres règles

Tout d'abord, nous avons besoin d'une requête de recherche. Une fois que nous l'avons écrit, nous pouvons cliquer sur « Enregistrer sous » puis sur « Alerte ».

Les fenêtres suivantes s'afficheront alors :

Donnez un titre et une description à l'alerte.

Autorisations

• Privé : vous seul pouvez accéder aux alertes déclenchées, les modifier et les afficher.
• Partagé dans l'application : tous les utilisateurs de l'application peuvent consulter les alertes déclenchées. Par défaut, tout le monde a un accès en lecture et les utilisateurs expérimentés ont un accès en écriture à l'alerte.

Type d'alerte :

Nous expliquons ici Splunk comment rechercher les événements correspondant à notre alerte.

• Les alertes planifiées effectueront des recherches à un intervalle défini et évalueront les conditions de déclenchement une fois la recherche terminée.
• Les alertes en temps réel s'exécutent en permanence en arrière-plan et évaluent les conditions de déclenchement dans un laps de temps donné en fonction des conditions que vous définissez.

Dans la capture d'écran ci-dessus, nous avons défini le type d'alerte comme étant en temps réel, expirant après 24 heures et l'alerte de déclenchement est définie sur « par résultat ». Nous obtiendrons des résultats pour chaque match, nous pouvons le réduire si trop d'alertes sont générées. Ici, nous l'avons défini comme « supprimer les résultats » qui contiennent le mot « statut » car notre alerte de recherche contient le mot clé « status » et le supprimera au bout de 10 minutes.

Enfin, déclenchez des actions :

Nous indiquons ici Splunk les actions à effectuer lorsqu'une alerte est générée. Comme indiqué, elle peut effectuer les opérations suivantes : déclencher des alertes, enregistrer l'événement, afficher les

résultats dans un fichier de recherche et exécuter un script ou envoyer les résultats vers un point de terminaison afin qu'il puisse attirer l'attention d'un analyste du SOC.