ESM : Scénarios communs pour les politiques de surveillance

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

Généralement, les organisations doivent surveiller leurs sources d'événements dans des « buckets » basés sur le niveau de criticité des sources d'événements. Voici un exemple typique :

  • Il existe un groupe d'appareils PCI, et il est essentiel de savoir si l'un de ces appareils cesse d'envoyer des messages (ou envoie trop peu de messages) sous une demi-heure.
  • Il existe un groupe d'appareils Windows, et il est utile de savoir si l'un de ces appareils cesse d'envoyer des messages après quatre heures.
  • Il existe un groupe d'appareils silencieux qui n'envoient généralement pas beaucoup de messages, mais vous souhaitez savoir s'ils n'envoient rien pendant 24 heures.

De nombreuses organisations pourraient avoir un réseau qui ressemble à cet exemple. Vous pouvez avoir plusieurs catégories ou elles peuvent être différentes, mais nous utiliserons cet exemple pour aborder le mode d'utilisation de cette fonction.

Vous pouvez avoir des dizaines, voire des centaines de groupes de sources d'événements, mais n'avoir que quelques groupes pour lesquels vous avez besoin de définir des seuils et des alertes.

Remarque : Si une source d'événement est un membre de plusieurs groupes sur lesquels l'alerte est configurée, il n'alertera que le premier groupe correspondant dans la liste classée. (L'onglet Politiques de surveillance présente une liste classée de vos groupes.)

Classement des groupes

Remarque : Pour modifier l'ordre des groupes, glissez -déplacez un groupe vers son nouvel emplacement. Les groupes placés en tête de liste sont prioritaires sur ceux qui suivent : RSA Security Analytics vérifie les seuils dans l'ordre prévu dans ce panneau. Ainsi, vos groupes prioritaires doivent être en haut de cette liste.

La première chose à garder à l'esprit est la façon dont vous classez vos groupes sur la page Politiques de surveillance. Si vous possédez les trois groupes mentionnés ci-dessous, vous devez les classer comme suit :

  1. Sources d'événements silencieuses. Le fait de posséder ce groupe permet de s'assurer que vous n'obtiendrez pas beaucoup de fausses alertes.
  2. sources d'événements PCI à priorité élevée. Les appareils à priorité supérieure doivent se trouver après les appareils silencieux
  3. Sources d'événements Windows. La période est plus longue (quatre heures contre une demi-heure) pour ces appareils par rapport aux appareils PCI. Ils doivent donc être placés après les appareils PCI.
  4. Toutes les sources d'événements. Vous pouvez éventuellement définir des seuils pour tous les appareils en tant qu'interception globale. Ceci permet de s'assurer que tout votre réseau fonctionne tel que vous l'attendez. Pour le groupe « fourre-tout », inutile de spécifier des seuils d'alerte — vous pouvez utiliser l'alerte automatique pour générer des alarmes pour les sources d'événements de ce groupe.

ESM_order1.png

Dans la figure ci-dessus, notez ce qui suit :

  • Les groupes sont classés comme indiqué dans la section précédente.
  • Le seuil des appareils PCI a pour but d'alerter si le nombre de messages entrants dans Security Analytics est inférieur à 10 messages en 30 minutes.
  • Un seuil inférieur est défini, mais pas un seuil supérieur. Ceci est classique pour de nombreux cas d'utilisation.

Après avoir configuré et classé vos groupes et commencé à recevoir des alertes, vous pouvez avoir à ajuster l'ordre. Utilisez ces instructions pour ajuster l'ordre :

  • Si vous recevez trop de notifications, vous pouvez descendre le groupe dans l'ordre. De même, si vous recevez trop peu de notifications, vous pouvez déplacer le groupe vers le haut.
  • Si vous notez qu'une source d'événement crée plus d'alertes qu'elle ne le devrait, vous pouvez la déplacer dans un autre groupe ou créer un nouveau groupe pour cette source d'événement.
Previous Topic:Alertes automatiques
You are here
Table of Contents > À propos de la gestion de la source d'événements > Scénarios communs pour les politiques de surveillance

Attachments

    Outcomes