Archiver : Instructions relatives aux règles et requêtes

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

Toutes les requêtes et les conditions de règle définies dans les services de base de RSA Security Analytics doivent suivre les instructions suivantes : 

Tous les horodatages et valeurs littérales de la chaîne doivent être entre guillemets. Ne mettez pas les nombres ou les adresses MAC et IP entre guillemets.

Par exemple :

  • extension = 'torrent'
  • time='2015-jan-01 00:00:00'
  • service=80
  • ip.src = 192.168.0.1

Remarque : L'espace à droite et à gauche d'un opérateur est facultatif.
Par exemple, vous pouvez utiliser service=80 ou service = 80.

Exemples de règle

Le tableau suivant présente des exemples de conditions de règle. Vous pouvez utiliser des conditions de règle pour les collections de rétention des logs dans un service Archiver et pour les règles d'application, de réseau et de corrélation appliquées à un Decoder, Log Decoder ou Concentrator. Les conditions de règle sont également utilisées dans toutes les clauses Where de toutes les requêtes de la base de données principale.

Pour plus d'informations sur la syntaxe de règle dans Security Analytics, reportez-vous à la section Clauses Where de la rubrique Requêtes dans le Guide d'optimisation de la base de données principale de RSA Security Analytics.

                                   
Nom de la règleCondition
ComplianceDevicesdevice.group='PCI Devices' || device.group='HIPPA Devices'
HighValueWindowsdevice.group='Windows Compliance'
MediumValueWindowsdevice.type='winevent_nic' && msg.id='security_4624_security'
LowValueWinLogsdevice.type='winevent_nic' && msg.id='security_4648_security'
LowValueProxyLogsdevice.class='proxy' && msg.id='antivirus_license_expired'
GeneralWindowsdevice.type='winevent_nic'

Configuration du mode strict pour Security Analytics 10.6

Depuis la version 10.2, Security Analytics utilise un analyseur moderne pour les règles et les requêtes qui définit de manière stricte la syntaxe valide. Lorsqu'un service de base rencontre une syntaxe obsolète, un message d'avertissement à ce propos est consigné dans les logs de Security Analytics. Security Analytics applique désormais une analyse stricte pour les nouvelles règles d'application, de réseau et de corrélation. L'analyseur hérité de la génération précédente, désormais obsolète, autorise l'utilisation d'une syntaxe ambiguë, ce qui peut entraîner des résultats inattendus. Security Analytics 10.6 continue de prendre en charge la syntaxe obsolète, mais les versions futures ne la prendont plus en charge.

Une fois la mise à jour vers Security Analytics 10.6 effectuée, les règles de syntaxe obsolètes sont mises en surbrillance dans l'interface utilisateur. L'éditeur de règles fournit des infobulles supplémentaires. Une fois les règles corrigées, les mises en surbrillance disparaissent. Reportez-vous à la rubrique Corriger les règles contenant une syntaxe obsolète dans le Guide de configuration de Decoder et Log Decoder.

Les statistiques /decoder/config/rules/rule.errors et /concentrator/config/rules/rule.errors, introduites dans la version 10.6, indiquent le nombre de règles erronées. Si rule.errors est différent de zéro, Security Analytics génère une alerte d'intégrité pour indiquer que vous devez corriger les règles.

De plus, un chemin de migration est disponible pour les requêtes issues de systèmes externes. Après une mise à jour à partir d'une version antérieure, le système fonctionne en mode obsolète (contrôlé par /sdk/config/query.parse). En mode obsolète, le service continue à utiliser l'analyseur hérité pour toutes les requêtes qui échoue lors de l'analyse stricte. Les erreurs sont consignées et un message est renvoyé au client pour l'informer de l'échec de l'analyse stricte. Cependant, la requête s'exécute et renvoie les résultats comme pour les versions précédentes. Vous devez surveiller les logs et les clients externes afin d'identifier les rapports, les tableaux de bord, les règles..., qui sont écrits dans la syntaxe obsolète afin de corriger les erreurs potentielles.

Une fois les problèmes résolus, vous pouvez passer tous les services de base (Decoder, Log Decoder, Concentrator, Broker et Archiver) en mode strict afin de surveiller le moindre problème. Le mode strict n'utilise pas l'analyseur hérité et les violations d'analyse renvoient des erreurs. Vous devez effectuer cette tâche avant toute mise à niveau majeure ultérieure à la version 10.6, étant donné que l'analyseur hérité sera supprimé des prochaines versions, et il qu'il n'y aura plus aucune option de fonctionnement en mode obsolète.

Par défaut, toutes les nouvelles installations fonctionnent en mode strict. Si vous prévoyez d'ajouter une nouvelle appliance à l'infrastructure existante en cours d'exécution en mode obsolète, dans la vue Explorer (Administration > Services > Sélectionner un service, puis dans le menu Actions, sélectionnez Afficher > Explorer), vous pouvez basculer /sdk/config/query.parse en mode obsolète jusqu'à ce que l'ensemble de la pile soit passé en mode strict.

Dans Security Analytics 10.6, la validation des règles s'appliquera toujours en mode strict, afin d'éviter de créer des problèmes de syntaxe.

Syntaxe valide avec analyseur moderne

Voici les règles de syntaxe valides en utilisant l'analyseur moderne :

  • Tous les types de texte doivent utiliser les valeurs littérales entre guillemets. Exemple : username = 'user1'
  • Les guillemets peuvent être simples ou doubles, mais ils doivent être identiques (vous ne pouvez pas commencer avec un guillemet simple et finir avec des guillemets doubles)
  • Si la valeur littérale comporte des guillemets, vous pouvez leur insérer un caractère d'échappement ou utiliser d'autres guillemets ouvrants. Les deux exemples ci-dessous sont valides (utilisez la barre oblique inverse en guise de caractère d'échappement):

    • username = "User’s"
    • username = 'User\'s'
  • Pour utiliser une barre oblique inverse dans une chaîne littérale, insérez une autre barre oblique inverse en guise de caractère d'échappement. \\
  • Tous les types d'heures doivent utiliser des guillemets pour les dates au format suivant : time = 'YYYY-MM-DD HH:MM:SS'
  • Tous les types d'heures exprimées en nombres de secondes depuis l'outil EPOCH (Jan 1, 1970), ne doivent pas être mis entre guillemets.
    Exemple : time = 1448034064
  • TOUT LE RESTE ne doit pas être mis entre guillemets : Adresse IP, adresses Ethernet, chiffres, etc.
    Exemple : service = 80 && ip.src = 192.168.1.1/16

Exemples de syntaxe ambiguë en utilisant l'analyseur hérité

Voici un exemple de syntaxe ambiguë avec l'analyseur hérité obsolète :

select * where alias.host = server-xeon

Dans la requête ci-dessus, il semble évident que l'auteur de la requête souhaite renvoyer tous les méta dans lesquels alias.host est égal à server-xeon. Malheureusement, cela ne se produit pas avec l'analyseur hérité. Celui-ci analyse cette requête sous la forme select * where alias.host = 'server'-'xeon'. Il la convertit donc en une requête de plage (valeurs BETWEEN server et xeon, en utilisant l'opérateur dash -), et étant donné que cette plage renverra probablement des résultats incohérents avec server-xeon, les utilisateurs supposeront que le moteur de requêtes ne présente aucun problème. En mode strict 10.6, vous obtiendrez l'erreur suivante :

expecting <quoted_string> here: "server-xeon" 

Ceci indique immédiatement à l'utilisateur la raison pour laquelle la requête d'analyse a échoué.

Voici un autre exemple de syntaxe ambiguë avec l'analyseur hérité obsolète :

select * where username=lastname,firstname

En langage Security Analytics, vous pouvez spécifier plusieurs valeurs en les séparant par des virgules (opérateur OR implicite). L'auteur de la requête voulait-il signifier 'lastname,firstname' ou recherchait-il deux valeurs, 'lastname' et 'firstname' ? Là encore, la syntaxe est ambiguë, mais acceptée par l'analyseur hérité (qui l'interprète comme 'lastname' OR 'firstname'). Avec l'analyseur moderne, vous devez être totalement clair(e) dans vos intentions, soit 'lastname,firstname' ou 'lastname','firstname'

Dans l'exemple suivant, l'analyse ne s'effectue pas correctement :

select * where username = lastname, firstname

À première vue, vous pouvez ne pas remarquer qu'il y a un espace entre la virgule et le prénom. En l'absence de guillemets, l'analyse ne s'effectue pas correctement avec l'analyseur hérité et aucun message d'erreur ne s'affiche pour indiquer que l'analyse a échoué. Au lieu de cela, l'analyse s'exécute (en ignorant complètement le prénom du fait de l'espace existant). Le pire est que rien ne vous indique que la requête exécutée ne correspond pas à ce que vous avez soumis, sauf si vous parvenez à déterminer d'une certaine manière que le jeu de résultats est incomplet. Avec l'analyse stricte activée, une erreur d'analyse est renvoyée, chose qui doit toujours se produire. Au moins dans les versions antérieures (et le mode obsolète), les logs affichent immédiatement un message après le log d'audit pour la requête : Rule '<rule name>' in deprecated format. Please make sure all text values are surrounded with quotes.

You are here
Table of Contents > Références > Instructions relatives aux règles et requêtes

Attachments

    Outcomes