Alertes : Bonnes pratiques

Document created by RSA Information Design and Development on Feb 3, 2017
Version 1Show Document
  • View in full screen mode
  

Les bonnes pratiques donnent des instructions pour vous aider à écrire, gérer et déployer des règles, et à conserver l'intégrité du système pour vos services ESA.

Comprendre les types de règles Event Stream Analysis

Le service Security Analytics Event Stream Analysis (ESA) fournit une analytique de flux avancée telle que la corrélation et le traitement complexe d'événements, avec un haut débit et une faible latence.  Il est capable de traiter de gros volumes de données d'événements disparates provenant des Concentrators. Toutefois, lorsque vous utilisez Event Stream Analysis, vous devez connaître les facteurs qui affectent l'utilisation des ressources afin de créer des règles efficaces. 

Chaque événement reçu par ESA est évalué afin de déterminer s'il est susceptible de déclencher une règle. Il existe trois types de règles pouvant être déployées afin de déterminer ce que doit faire le moteur ESA avec l'événement entrant. Chacun de ces types de règles a un impact différent sur l'utilisation des ressources du système. Ces trois types de règles peuvent être créés via le Générateur de règles ou les règles EPL avancées, ou ils peuvent être téléchargés via RSA Live. Le tableau ci-dessous répertorie le type de règle et l'impact de cette règle sur les ressources du système.

                       
Type de règleDescription :

Règle de filtrage simple

Cette règle ne présente pas de corrélation avec les autres événements. Au moment de l'acquisition, cette règle est évaluée par rapport à un ensemble de conditions, et une alerte est générée si ces conditions sont remplies. Si aucune condition n'est remplie, l'événement est rapidement libéré par le moteur pour réduire l'utilisation de la mémoire. Ces règles ne consomment pas de mémoire car les événements ne sont pas retenus après l'évaluation initiale. L'utilisation des ressources mémoire n'augmentent pas avec le déploiement de nouvelles règles de filtrage simples. Toutefois, si la condition de filtrage est trop générique, il est possible que la règle déclenche de nombreuses alertes, ce qui pourrait avoir un impact sur les ressources système pour le stockage et la récupération de ces alertes.
Par exemple, vous pourriez écrire une règle pour générer une alerte lorsque l'activité réseau HTTP arrive sur un port HTTP non standard.

Règle liée à la fenêtre des événements Cette règle évalue un ensemble d'événements par rapport à des conditions spécifiques sur une période de temps. Au moment de l'acquisition, la règle est évaluée par rapport à un ensemble de conditions. Si ces conditions sont remplies, l'événement est retenu en mémoire pendant une période spécifique. À la fin de cette période, les événements sont supprimés de la fenêtre de temps si le nombre d'événements collectés n'atteint pas le seuil à partir duquel une alerte est déclenchée. La consommation de mémoire de ces règles dépend largement du taux d'événements entrants (trafic), de la quantité de données par événement, et de la période spécifiée dans la fenêtre des événements. Chaque événement correspondant à ces critères est retenu en mémoire jusqu'à ce que la fenêtre de temps soit écoulée. Ainsi, plus la fenêtre de temps est étendue, plus le volume potentiel est élevé.  Par exemple, vous pouvez écrire une règle qui génère une alerte si la connexion d'un utilisateur au système échoue cinq fois sur une période dix minutes.

Règle de séquence

Cette règle évalue une chaîne d'événements entrants afin de déterminer si la séquence des événements correspond à une condition particulière. Au moment de l'acquisition, la règle est évaluée par rapport à un ensemble de conditions. Si les conditions sont remplies, l'une des deux actions suivantes se produit :

  • S'il s'agit du premier événement de la séquence, une nouvelle thread d'événements est démarrée, et l'événement retenu vient en tête de séquence.
  • Si l'événement appartient à une thread d'événements existante, il est ajouté à cette séquence.

Dans les deux cas, l'événement est retenu en mémoire. La quantité de ressources utilisées est particulièrement sensible à l'environnement client pour ce type de règle. Si la condition de filtrage génère de nombreuses threads, des ressources sont consommées pour chaque nouvelle thread (en plus de l'événement). En outre, si une thread d'événements ne se termine jamais (c'est-à-dire qu'une alerte n'est jamais générée), alors tout l'événement reste enregistré dans la mémoire de manière indéfinie.  Par exemple, vous pouvez écrire une règle pour générer une alerte lorsque la connexion d'un utilisateur à un serveur échoue, qu'il effectue une connexion réussie, puis qu'il crée un nouveau compte.

 

En plus de l'utilisation de mémoire abordée plus haut, la génération d'alertes consomme également des ressources système. Chaque alerte générée doit être stockée pour être récupérée et traitée par Incident Management. Ce processus utilise de l'espace disque pour le stockage, consomme de la mémoire de la base de données, et augmente l'utilisation du CPU pour exécuter les requêtes. 

Lorsque vous écrivez et déployez des règles, vous devez savoir que chacune de ces actions a un « coût » en termes de ressources système. Les sections ci-dessous sont conçues pour vous aider à garder votre utilisation à un niveau sain, et à surveiller les problèmes en cas de surcharge des systèmes. 

Bonnes pratiques pour l'écriture de règles

Voici les directives générales pour écrire des règles.

  • Créez des alertes pour les événements sur lesquels il est possible d'effectuer des actions.  L'objectif d'une alerte est de vous notifier d'un événement qui requiert une attention immédiate et spécifique. Pour les événements qui ne requièrent pas d'action de votre part, vous pouvez créer un rapport à titre informatif uniquement. Cela vous aide à ne pas surcharger la base de données qui stocke les alertes.
  • Configurez de nouvelles règles en tant que règles d'évaluation pour pouvoir observer leur réaction dans votre environnement.  Si vous déployez de nouvelles règles en tant que règles d'évaluation, elles seront désactivées si le seuil de mémoire configuré est dépassé. Vous pouvez également utiliser la fonction de snapshot mémoire pour connaître l'utilisation de la mémoire lorsqu'une règle d'évaluation est désactivée. Pour plus d'informations, consultez Utiliser les règles d'évaluation.
  • Configurer les notifications d'alerte uniquement après votre règle de test et de réglage. Cela peut vous éviter de recevoir un nombre trop important de notifications si le comportement d'une règle est différent de celui que vous attendez. 
  • Les règles doivent être spécifiques pour que vous puissiez limiter l'utilisation des ressources.. Utilisez les instructions suivantes pour limiter l'utilisation :
    • Assurez-vous que les filtres de la règle excluent tous les événements sauf ceux qui sont nécessaires au déclenchement précis de la règle.
    • Réduisez la taille de votre fenêtre de temps (pour la corrélation) autant que possible.
    • Limitez les événements que vous incluez dans la fenêtre : Par exemple, si vous ne souhaitez voir que les événements IDS, assurez-vous de n'inclure que les événements de votre fenêtre de temps. 
  • Les règles doivent être affinées sur un niveau d'alerte gérable. Si le nombre d'alertes est trop important, elles perdent leur objectif et leur utilité. En outre, vous risqueriez d'inonder la base de données qui stocke les alertes, ce qui ralentirait ou empêcherait votre système de traiter les alertes. Par exemple, vous souhaitez peut-être être informé du trafic chiffré vers d'autres pays. Mais vous pouvez limiter la liste aux pays à risque. Cela limite le volume des alertes à un niveau que vous pouvez gérer.

Bonnes pratiques pour l'utilisation de règles RSA Live

Voici les directives pour les règles RSA Live.

  • Déployez des règles RSA en petits lots. Toutes les règles ne sont pas adaptées à tous les environnements. La meilleure façon de vérifier le succès de vos règles RSA Live est de les déployer par petits lots, de façon à les tester dans votre environnement. Si vous déployez de petits lots, il est bien plus facile de déceler les problèmes d'une règle particulière. 
  • Lisez les descriptions de règle fournies par les règles RSA Live. Les règles ESA ne sont pas « universelles ». Toutes les règles ne fonctionneront pas dans votre environnement. Les descriptions de règles vous indiquent les paramètres que vous devez modifier pour déployer correctement une règle dans votre environnement.
  • Définissez vos paramètres.  Les règles RSA Live disposent de paramètres qui doivent être modifiés.  Si vous ne modifiez pas les paramètres, il est possible que la règle ne fonctionne pas ou qu'elle épuise votre mémoire.
  • Déployez de nouvelles règles en tant que règles d'évaluation afin d'observer leur réaction dans votre environnement. Si vous déployez de nouvelles règles en tant que règles d'évaluation, elles seront désactivées si le seuil de mémoire configuré est dépassé. Pour de plus amples informations, reportez-vous à la section  Utiliser les règles d'évaluation.

Bonnes pratiques pour déployer des règles

Voici les directives générales pour déployer des règles.

  • Déployez les règles en petits lots pour pouvoir observer leur réaction dans votre environnement. Tous les environnements ne sont pas identiques, et une règle devra être optimisée pour l'utilisation de la mémoire, le volume d'alertes et la détection efficace des événements.
  • Testez les règles avant de configurer des notifications d'alerte. Configurez les notifications d'alerte uniquement après avoir terminé votre réglage et vos tests de règle. Cela peut vous éviter de recevoir un nombre trop important d'alertes si le comportement d'une règle est différent de celui que vous attendiez.
  • Surveiller la santé du système dans le cadre de votre processus de déploiement. Lorsque vous déployez des règles, surveillez l'intégrité de votre système dans le cadre de votre processus de déploiement. Vous pouvez afficher l'utilisation totale de la mémoire de votre service ESA dans l'onglet Intégrité. Pour plus d'informations, consultez « Afficher les statistiques d'intégrité ». Dépanner le service ESA.

Bonnes pratiques pour l'intégrité du système

Voici les directives générales pour l'intégrité du système.

  • Configurez la base de données des alertes pour maintenir un niveau d'alerte sain. ESA utilise MongoDB pour stocker les alertes. Si MongoDB reçoit un nombre trop important d'alertes, cela peut provoquer le ralentissement ou l'arrêt de la base de données. Pour vous assurer que votre base de données reçoit un niveau adéquat d'alertes, configurez les paramètres pour effacer régulièrement les alertes. Pour ce faire, consultez la section « Configurer le stockage ESA » dans le Guide de configuration d'Event Stream Analysis (ESA).
  • Configurer de nouvelles règles en tant que règles d'évaluation. Il arrive souvent que de nouvelles règles créent des problèmes de mémoire. Pour éviter cela, vous pouvez configurer les nouvelles règles comme règles d'évaluation. Si le seuil de mémoire configuré est atteint, toutes les règles d'évaluation sont désactivées pour éviter que le système ne manque de mémoire.  Pour plus d'informations sur l'exécution des règles d'évaluation, reportez-vous à la section Utiliser les règles d'évaluation.
  • Configurer des seuils dans le module État de santé pour vous alerter si l'utilisation de la mémoire est trop élevée. Certaines metrics du module Intégrité effectuent le suivi de l'utilisation mémoire. Vous pouvez configurer des alertes et notifications pour vous envoyer un email lorsque ces seuils sont dépassés.  Pour plus d'informations sur les statistiques de la mémoire, consultez Afficher les statistiques d'intégrité. Dépanner le service ESA
  • Surveillez les métriques de mémoire pour chaque règle dans le module Intégrité. Pour chaque règle, vous pouvez afficher l'utilisation de mémoire estimée dans le module Intégrité. Vous pouvez utiliser ces informations pour garantir que les règles n'utilisent pas trop de mémoire.  Pour plus d'informations sur les statistiques de la mémoire, consultez « Afficher les statistiques d'intégrité ». Dépanner le service ESA
You are here
Table of Contents > Guide de démarrage rapide ESA > Bonnes pratiques

Attachments

    Outcomes