Modèle de document d'extension

L'exemple d'un document d'extension fournit des informations sur la façon d'analyser un type particulier de Cisco FWSM afin que les événements ne soient pas envoyés avec un nom d'événement incorrect.

Par exemple, si vous voulez résoudre le mot session, qui est intégré au milieu du nom de l'événement :

Nov 17 09:28:26 192.0.2.1 %FWSM-session-0-302015: Built UDP connection for faddr <IP_address1>/80 gaddr <IP_address2>/31696 laddr <IP_address3>/2157 duration 0:00:00 bytes 57498 (TCP FINs)

Cette condition entraîne le DSM à ne pas reconnaître d'événement et tous les événements sont non analysés et associés au consignateur générique.

Bien qu'une partie seulement de la chaîne de texte (302015) soit utilisée pour la recherche QID, la chaîne de texte entière (%FWSM-session-0-302015) identifie l'événement comme provenant de Cisco FWSM. Étant donné que toute la chaîne de texte n'est pas valide, le DSM suppose que l'événement n'est pas valide.

Exemple de document d'xtension pour analyser un type d'événement

Un périphérique FWSM possède de nombreux types d'événements et beaucoup avec des formats uniques. L'exemple de document d'extension suivant indique comment analyser un type d'événement.

Remarque: Les ID de modèle n'ont pas besoin de correspondre aux noms de zone qu'ils analysent. Bien que l'exemple suivant duplique le motif, le champ SourceIp et le cab de champ SourceIpPreNAT utilisent le même modèle dans ce cas. Cette situation pourrait ne pas être vraie dans tous les événements FWSM.

<?xml version="1.0" encoding="UTF-8"?>
<device-extension xmlns="event_parsing/device_extension"> 
<pattern id="EventNameFWSM_Pattern" xmlns=""><![CDATA[%FWSM[a-zA-Z\-]*\d-(\d{1,6})]]></pattern>
<pattern id="SourceIp_Pattern" xmlns=""><![CDATA[gaddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern> 
<pattern id="SourceIpPreNAT_Pattern" xmlns=""><![CDATA[gaddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="SourceIpPostNAT_Pattern" xmlns=""><![CDATA[laddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="DestinationIp_Pattern" xmlns=""><![CDATA[faddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="Protocol_Pattern" case-insensitive="true" xmlns=""><![CDATA[(tcp|udp|icmp|gre)]]></pattern>
<pattern id="Protocol_6_Pattern" case-insensitive="true" xmlns=""><![CDATA[protocol=6]]></pattern> 
<pattern id="EventNameId_Pattern" xmlns=""><![CDATA[(\d{1,6})]]></pattern>
<match-group order="1" description="FWSM Test" device-type-id-override="6" xmlns=""> 
      <matcher field="EventName" order="1" pattern-id="EventNameFWSM_Pattern" capture-group="1"/>     
      <matcher field="SourceIp" order="1" pattern-id="SourceIp_Pattern" capture-group="1" /> 
      <matcher field="SourcePort" order="1" pattern-id="SourcePort_Pattern" capture-group="2"/> 
      <matcher field="SourceIpPreNAT" order="1" pattern-id="SourceIpPreNAT_Pattern" capture-group="1" /> 
      <matcher field="SourceIpPostNAT" order="1" pattern-id="SourceIpPostNAT_Pattern" capture-group="1" /> 
      <matcher field="SourcePortPreNAT" order="1" pattern-id="SourcePortPreNAT_Pattern" capture-group="2" />   
      <matcher field="SourcePortPostNAT" order="1" pattern-id="SourcePortPostNAT_Pattern" capture-group="2" /> 
      <matcher field="DestinationIp" order="1" pattern-id="DestinationIp_Pattern" capture-group="1" />         
      <matcher field="DestinationPort" order="1" pattern-id="DestinationIp_Pattern" capture-group="2" /> 
      <matcher field="Protocol" order="1" pattern-id="Protocol_Pattern" capture-group="1" /> 
      <matcher field="Protocol" order="2" pattern-id="Protocol_6_Pattern" capture-group="TCP" enable-substitutions=true/>      
      <event-match-multiple pattern-id="EventNameId" capture-group-index="1" device-event-category="Cisco Firewall"/> 
   </match-group> 
</device-extension>

<?xml version="1.0" encoding="UTF-8"?> 
<device-extension xmlns="event_parsing/device_extension"> 
<!-- Do not remove the "allEventNames" value -->
<pattern id="EventName-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="SourceIp-Fakeware_Pattern" xmlns=""><![CDATA[]]</pattern>
<pattern id="SourcePort-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="SourceMAC-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="DestinationIp-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="DestinationPort-Fakeware_Pattern" case-insensitive="true" xmlns=""><![CDATA[]]></pattern>
<pattern id="Protocol-Fakeware_Pattern" case-insensitive="true" xmlns=""><![CDATA[]]></pattern> 
<match-group order="1" description="FWSM Test" device-type-id-override="6" xmlns=""> 
   <matcher field="EventName" order="1" pattern-id="EventName-Fakeware_Pattern" capture-group="1"/> 
   <matcher field="SourceIp" order="1" pattern-id="SourceIp-Fakeware_Pattern" capture-group="1" /> 
   <matcher field="SourcePort" order="1" pattern-id="SourcePort-Fakeware_Pattern" capture-group="1"/> 
   <matcher field="SourceMAC" order="1" pattern-id="SourceMAC-Fakeware_Pattern" capture-group="1" /> 
   <matcher field="DestinationIp" order="1" pattern-id="DestinationIp-Fakeware_Pattern" capture-group="1" /> 
   <matcher field="DestinationPort" order="1" pattern-id="SDestinationPort-Fakeware_Pattern" capture-group="1" /> 
   <matcher field="Protocol" order="1" pattern-id="Protocol-Fakeware_Pattern" capture-group="1" />   
   <event-match-multiple pattern-id="EventNameId" capture-group-index="1" device-event-category="Cisco Firewall"/> 
</match-group> 
</device-extension>

Bases d'analyse syntaxique

L'exemple de document de l'extension précédent montre quelques-uns des aspects fondamentaux de l'analyse :

Adresses IP
Ports
Protocole
Plusieurs champs qui utilisent le même motif avec différents groupes

Cet exemple analyse tous les événements FWSM qui suivent le motif spécifié. Les champs qui sont analysés pourraient ne pas être présents dans ces événements lorsque les événements comprennent un contenu différent.

Les informations qui étaient nécessaires pour créer cette configuration qui n'étaient pas disponibles à partir de l'événement :

Le nom de l'événement se compose uniquement des 6 derniers chiffres (302015) de la partie %FWSM-session-0-302015 de l'événement.
Le FWSM a une catégorie d'événement de périphérique codée en dur de Cisco Firewall.
Le DSM FWSM utilise le Cisco Pix QIDmap et comprend donc le paramètre device-type-id-override="6" dans le groupe de correspondance. L'ID de type de source de journal Pix Firewall est 6.

Remarque: Si les informations QID ne sont pas spécifiées ou ne sont pas disponibles, vous pouvez modifier le mappage des événements. Pour plus d'informations, voir la section Modification du mappage d'événements dans le manuel IBM QRadar User Guide.

Nom de l'événement et catégorie d'événement de périphérique

Un nom d'événement et une catégorie d'événement de périphérique sont nécessaires lorsque le QIDmap est recherché. Cette catégorie d'événement de périphérique est un paramètre de regroupement au sein de la base de données qui aide à définir des événements semblables dans un périphérique. event-match-multiple à la fin du groupe de correspondance comprend un codage en dur de la catégorie. event-match-multiple utilise le motif de EventNameId sur le nom de l'événement analysé pour correspondre jusqu'à 6 chiffres. Ce motif n'est pas exécuté sur le contenu complet, uniquement sur la partie analysée en tant que le champ EventName.

Le motif EventName fait référence à la partie %FWSM des événements ; tous les événements Cisco FWSM contiennent la partie %FWSM. Le motif dans l'exemple correspond à %FWSM suivi par un nombre quelconque (zéro ou plus) de lettres et de tirets. Cette correspondance de motif résout le mot session qui est incorporé au milieu du nom de l'événement qui doit être retiré. Gravité de l'événement (selon Cisco), suivie d'un tiret, puis du nom de l'événement réel, comme attendu par QRadar. La chaîne (\d{6}) est la seule chaîne dans le motif EventNameFWSM qui possède un groupe de capture.

Les adresses IP et les ports pour l'événement suivent tous le même modèle de base : une adresse IP suivie de deux-points, suivie du numéro de port. Ce motif analyse deux données (l'adresse IP et le port), et précise les différents groupes de capture dans la section matcher.

<device-extension>
<pattern id="EventName1">(logger):</pattern> 
<pattern id="DeviceTime1">time=\[(\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2})\] </pattern>
<pattern id="Username">(TLSv1)</pattern> 
<match-group order="1" description="Full Test"> 
   <matcher field="EventName" order="1" pattern-id="EventName1" capture-group="1"/>   
   <matcher field="DeviceTime" order="1" pattern-id="DeviceTime1"  
       capture-group="1" ext-data="dd/MMM/YYYY:hh:mm:ss"/> 
   <matcher field="UserName" order="1" pattern-id="Username" capture-group="1"/>
</match-group>
</device-extension>

Adresse IP et motifs de port

L'adresse IP et les motifs de port sont quatre ensembles de un à trois chiffres, séparés par des points, suivis par un signe deux-points et le numéro de port. La section de l'adresse IP est dans un groupe, de même que le numéro de port, mais pas les deux points. Les sections matcher pour ces champs font référence au même nom de motif mais à un groupe de capture différent (l'adresse IP est le groupe 1 et le port est le groupe 2).

Le protocole est un motif commun qui recherche le contenu pour la première instance de TCP, UDP, ICMP, ou GRE. Le motif est marqué avec le paramètre insensible à la casse de sorte que toute occurrence correspond.

Bien qu'un second motif de protocole ne se produise pas dans l'événement utilisé dans l'exemple, il existe un second motif de protocole qui est défini par un ordre de deux. Si le motif de protocole le plus faible ne correspond pas, le suivant est tenté, et ainsi de suite. Le deuxième motif de protocole démontre également la substitution directe ; il n'existe pas de groupe de correspondances dans le motif, mais avec le paramètre enable-substitutions activé, le texte TCP peut être utilisé à la place du protocole=6.