Il existe plusieurs niveaux d’optimisation dans l’ordre, du moins efficace à le plus efficace. Certaines de ces techniques sont facilement mises en œuvre. En revanche, les autres sont plus avancées et peuvent nécessiter une assistance de la part des services professionnels. Les services professionnels peuvent optimiser vos sources de données SIEM pour vous.
Pour désactiver les règles relatives aux événements de faible valeur et de nombre d’événements élevé, procédez comme suit :
De nombreuses sources de données envoient plusieurs journaux, dont certains sont plus importants que d’autres. Les journaux de faible importance, mais dont le volume est élevé, réduisent l’événement global par seconde sur la capacité du récepteur.
Si un type d’événement particulier comporte un nombre élevé d’événements par seconde et que les journaux ne sont pas importants pour l’utilisateur, les règles responsables de ces événements peuvent être désactivées. Cette action n’empêche pas le récepteur de collecter et d’envoyer ces événements à l’ESM, ce qui évite que les événements ne le fassent vers les tableaux de bord ESM.
Les modifications ont un impact faible sur les performances, mais elles permettent de réduire le volume de données dont ESM a besoin pour passer en revue.
- Dans le tableau de bord, sélectionnez le nom de la règle ou le type d’événement que vous souhaitez désactiver.
- Dans le menu Pancake, sélectionnez afficher la règle.
Le système ouvre l’Editeur de stratégies pour cette source de données et recherche la ASP ou la règle de source de données responsable de ces événements.
- Lorsque cette règle est sélectionnée, cliquez sur la liste déroulante de la section activer/désactiver et choisissez Désactiver.
- Cliquez sur la liste déroulante opérations en haut de la page, puis cliquez sur stratégie de déploiement.
Pour éviter l’utilisation d’une analyse en tant que syslog générique dans les propriétés de la source de données :
Chaque ASP source de données contient une section dans les propriétés pour la gestion des événements qui ne correspondent à aucune règle. Cette option peut être configurée pour
ne rien faire,
consigner comme inconnuou effectuer une
analyse syntaxique en tant que syslog générique.
Ces options peuvent être utiles pour la résolution de problèmes, mais nous vous recommandons de désactiver le paramètre syslog générique. La raison en est qu’elle diminue considérablement les performances. Il s’agit d’une solution à court terme lors de la configuration d’une nouvelle source de données qui ne dispose pas des fichiers de règles nécessaires pour l’ensemble des événements. Fondamentalement, il exécute l’événement au-delà de la source de données d’origine et ASP les règles une deuxième fois, mais ajoute des milliers de règles syslog génériques supplémentaires. Etant donné qu’il ajoute de nombreuses règles supplémentaires à chaque événement traité, il y a un impact important sur les performances. L’activation de seulement quelques-uns de ces paramètres de règles génériques peut ralentir le récepteur entier.
- Sélectionnez la source de données et ouvrez Propriétés.
- Faites défiler vers le bas jusqu’à la section inconnue .
- Sélectionnez ne rien faire ou consigner comme inconnu.
- Cliquez sur OK et, si vous y êtes invité, rédigez les paramètres de source de données et cliquez sur appliquer la stratégie.
Pour classer les règles ASP pour vous assurer que les règles de nombre d’événements les plus élevées sont exécutées en premier (voir KB90611-Filter et les informations de classement des règles de l’analyseur syslog avancé pour plus d’informations) :
Chaque événement entrant dans une source de données doit être vérifié par rapport à chaque règle pour cette source de données jusqu’à ce qu’une concordance soit trouvée. Plus le nombre de règles à vérifier avant la concordance est élevé, plus les performances d’analyse sont lentes. En modifiant l’ordre dans lequel les règles sont utilisées pour vérifier chaque événement, il est possible de réduire l’impact sur les performances de l’analyse syntaxique. L’idée est de rendre les événements les plus courants susceptibles de déclencher d’abord les règles de correspondance.
Par exemple, il existe 1 000 règles pour une source de données et l’événement le plus courant est le
type 51. Placez les vérifications d’ordre des règles pour le type 51 au lieu de les 999 autres règles.
- Dans la console ESM, cliquez sur Editeur de stratégies. Dans le volet types de règle , cliquez sur récepteur, analyseur syntaxique de fichiers Syslog avancé.
- Dans le menu opérations , cliquez sur trier les règles ASP. Dans la liste déroulante type de source de données , sélectionnez une source de données.
- Dans le volet de gauche, sélectionnez les règles à ajouter et définissez-les dans l’ordre approprié dans le volet de droite.
- Sélectionnez l'onglet Règles standard ou Règles personnalisées.
Remarque : Dans les règles de filtrage des commandes, aucune règle n’est répertoriée par défaut.
- Utilisez les flèches pour déplacer une règle du volet gauche vers le volet de droite, au-dessus des règles non classées.
- Utilisez les flèches vers le haut ou le bas pour placer les règles dans l'ordre approprié.
- Cliquez sur OK et enregistrez les modifications.
- Poussez la stratégie vers les équipements appropriés.
Pour utiliser des règles de filtre afin de supprimer complètement un type d’événement de l’analyse syntaxique et du pipeline des événements (voir KB74834-comment créer des règles de filtre personnalisées pour filtrer les événements inoffensifs ou KB87331-comment améliorer les performances de ASP en filtrant les journaux qui ne correspondent à aucune règle pour plus de détails) :
Les règles de filtre sont similaires à la désactivation des règles d’analyse syntaxique, à la différence près que vous bloquez toutes les deux la collecte de l’événement d’origine. Les événements collectés par le récepteur suivent ces règles de filtrage, et si un événement correspondant à un filtre est défini, il est supprimé du côté de la collection. Cette suppression signifie que les événements ne sont jamais envoyés au pipeline d’analyse ou à ESM, ce qui offre un gain de performances optimal. Si un événement particulier de la valeur faible est déclenché à un nombre plus élevé que les événements plus importants et qu’il n’est pas nécessaire de suivre ces événements dans le tableau de bord ESM, une règle de filtrage est logique à employer. Il est important de noter que, bien qu’une règle de filtrage supprime les événements du traitement du récepteur et de l’ESM, les journaux sont envoyés à l’ELM pour la conformité. Par conséquent, même si un événement est filtré à partir du récepteur et de l’ESM, il peut toujours être trouvé avec une recherche ELM.
Les règles de filtre sont des sujets avancés et requièrent que l’utilisateur soit familiarisé avec l’écriture d’expressions régulières PCRE.