Foire aux questions sur les événements

Utilisez ces questions et réponses fréquemment posées sur les événements pour comprendre comment QRadar® corrèle les activités des utilisateurs dans les fichiers journaux afin de générer des infractions.

A quoi correspond un événement ?

Dans QRadar, un événement est un message qui est reçu et traité à partir d'un périphérique de votre réseau et qui est un journal d'une action particulière sur ce périphérique. Par exemple, une connexion SSH sur un serveur UNIX, une connexion VPN à un périphérique VPN ou un refus de pare-feu consigné par votre pare-feu de périmètre sont tous des événements. Ces actions se produisent à un moment donné et sont enregistrées dans des fichiers journaux.

A quoi correspond un événement unique ?

QRadar identifie un événement unique en fonction d'un certain nombre de propriétés: adresse IP source, adresse IP de destination, port de destination, protocole, nom d'utilisateur et ID de source de journal ou ID d'événement. Dans certains cas, le port source est également utilisé. Si quatre événements parviennent avec les mêmes propriétés clés, ils sont fusionnés en un même enregistrement pendant 10 secondes. Une fois cette période écoulée, le cycle se répète.

A quoi correspond la coalescence ?

La coalescence permet de réduire la quantité de données traitées par le pipeline d'événements. A mesure que les données arrivent et qu'elles sont fusionnées, une grande diffusion en rafale d'événements peut convertir des centaines de milliers d'événements en quelques dizaines d'événements seulement. Cette action est effectuée alors que QRadar gère le nombre d'événements réels. La coalescence permet à QRadar de détecter, d'énumérer et de suivre une attaque à grande échelle. Elle protège également les performances du pipeline en réduisant la charge de travail du système et notamment l'espace de stockage requis pour ces événements.

La coalescence connaît une limitation lors de la normalisation des données. Le premier événement de l'enregistrement fusionné, utilisé comme enregistrement de base, est le seul conservé intégralement, avec son contenu. Vous pouvez désactiver la coalescence pour les périphériques et sources de journal utilisés pour suivre les exigences d'audit et de conformité dans votre environnement et notamment, les applications personnalisées, les services orientés clients, les ressources critiques et autres périphériques importants.

Comment différentes sources d'événements et de journal se comparent-elles ?

De nombreuses sources de journal et types de sources de journal différents sont pris en charge par QRadar, tels que les pare-feux, les dispositifs d'authentification, les scanners, les serveurs de fichiers, les plateformes d'application, etc. Chacun de ces types de sources de journal, tels qu'ils sont référencés dans QRadar, fournit une perspective et un type d'informations différents sur votre réseau. Par exemple, un pare-feu indique le nombre de systèmes distants qui tentent de pénétrer votre réseau. Simultanément, un serveur d'authentification Windows ou LDAP vous fournit des informations sur les membres du personnel local qui se connectent aux ressources réseau. Vos besoins en matière de surveillance, d'audit et de sécurité influencent les types de sources de journal que vous envoyez à QRadar.

Si un équilibreur de charge est utilisé, les événements sont-ils analysés par un collecteur d'événements ? Plusieurs sources de journal sont-elles créées ?

Toute source Syslog qui envoie des données à un équilibreur de charge devant QRadar peut être analysée sur n'importe quel collecteur d'événements. Toutes les sources de journal détectées automatiquement dans QRadar peuvent être traitées par n'importe quel collecteur d'événements dans le déploiement. Lorsque la détection automatique est déclenchée et qu'une demande de création d'une source de journal est envoyée à QRadar Console, la source de journal est créée. En une minute, tous les processeurs et collecteurs d'événements ont connaissance de cette nouvelle source de journal et les données envoyées à un processeur d'événements sont automatiquement associées à cette source de journal. Par conséquent, vous pouvez activer un équilibreur de charge en avant de plusieurs collecteurs et processeurs d'événements.

Une source de journal est créée dans ce scénario. Plusieurs commandes create peuvent être envoyées par plusieurs processeurs au cours des premières minutes qui suivent la détection d'une source de journal, mais cette dernière n'est créée qu'une seule fois. Lorsque le gestionnaire de source de journal sur le QRadar Console reçoit la commande create , il crée la source de journal si celle-ci n'existe pas. Le gestionnaire de sources de journal ignore la demande de création si la source de journal existe déjà.

Que signifient les horodatages dans les détails d'événement ?

Ces horodatages peuvent avoir des valeurs différentes, en fonction de l'origine des données, de la date d'arrivée des données et de la date d'écriture dans QRadar. La liste suivante décrit chaque horodatage :
  • Heure de début
    Enregistrement d'événement qui représente le moment où l'événement est reçu par un QRadar collecteur d'événements . Lorsque des événements arrivent dans le pipeline, un objet est créé en mémoire et l'horodatage Heure de début est défini sur cette heure.
  • Heure de stockage
    Heure à laquelle les données sont enregistrées sur disque par le composant Ariel à la fin du traitement par le pipeline d'événements. Cet horodatage est utile pour déterminer si les événements sont mis en file d'attente dans le pipeline d'événements pour des raisons de performances ou de licence.
  • Horodatage de la source de journaux
    Heure du contenu des événements (il s'agit généralement de l'heure affichée dans l'en-tête Syslog). Toutefois, certaines sources de journal incluent les horodatages dans le contenu, tels que les journaux Windows qui comportent une zone MessageTime dans le corps du contenu. Si aucune heure n'est disponible dans le contenu, la zone Heure de la source de journal est renseignée avec la valeur Heure de début.

Comment QRadar affecte-t-il une adresse IP source et de destination à des événements?

Les événements QRadar requièrent à la fois une adresse IP source et une adresse IP de destination. QRadar utilise ces emplacements pour localiser une adresse IP:

  • A partir du contenu des événements (première méthode)
    Les sources de journal prises en charge (et les sources de journal universelles, si vous créez vos propres modèles d'expression régulière d'analyse) recherchent dans le contenu des événements reçus une adresse IP source et une adresse IP de destination. Lorsqu'elles sont localisées, ces adresses sont placées dans les zones Source et Destination associées des enregistrements d'événement. Si le contenu ne contient aucune adresse IP, les autres méthodes décrites ci-après sont utilisées.
  • A partir de la zone Hostname de l'en-tête Syslog (deuxième méthode)
    Si le contenu des événements ne contient aucune adresse IP, la zone Hostname de l'en-tête Syslog est utilisée. La zone Hostname est commune pour les événements des sources de journal qui n'incluent qu'une Adresse source dans la zone, tels que les journaux de services Web, qui n'incluent que l'adresse IP de l'hôte distant. Dans ces types d'événement, l'adresse ID de destination est alimentée par l'en-tête Syslog ou la zone Hostname de l'événement. Si l'en-tête Syslog ou la zone Hostname correspond à un nom d’hôte et non à une adresse IP, aucune recherche DNS n'est effectuée et la troisième méthode est utilisée.
  • Adresse IP source IP du paquet réseau (troisième méthode)
    Si aucune adresse IP n'est disponible dans le contenu des événements ou dans la zone Hostname de l'en-tête Syslog, l'adresse IP source du paquet réseau est utilisée comme adresse IP. Si l'adresse IP source provient du contenu, l'adresse IP de ce paquet n'est utilisée que pour la zone Adresse IP de destination. Dans cette instance, le périphérique qui envoie à QRadar le message d'événement était l'adresse de destination de l'événement. Il peut arriver que l'adresse IP source et l'adresse IP de destination soient toutes deux introuvables dans le contenu ou dans la zone Hostname de l'en-tête Syslog. Dans ce cas, l'adresse IP du paquet réseau leur est affectée.

Comment QRadar affecte-t-il les adresses IP des serveurs Syslog centraux et des périphériques NAT?

Si vous disposez d'une infrastructure de service Syslog centrale existante, ou si vous souhaitez ajouter une règle de transfert à ce périphérique qui copie un flux de tous les événements sur le système QRadar . L'adresse IP utilisée par QRadar est l'adresse IP du paquet. Si vous utilisez un serveur Syslog central, vous risquez de retrouver l'adresse IP du serveur dans de nombreux événements et dans les noms de source de journal.

Pour éviter cette situation, configurez le serveur Syslog central pour ajouter un préfixe à un nouvel en-tête Syslog. Ce nouvel en-tête inclut l'adresse IP source d'origine du paquet reçu. Dans cette pratique, courante lors du transfert d'événements, QRadar fournit cette option dans le cadre de la configuration des destinations de transfert. Lorsque vous ajoutez le préfixe, l'adresse IP du périphérique source d'événement d'origine est toujours dans la zone Nom d'hôte de l'en-tête Syslog et QRadar utilise cette adresse IP dans les événements. Avec les périphériques NAT, il se peut que vous deviez retourner aux périphériques des sources de journal et les reconfigurer pour qu'ils utilisent l'adresse IP de l'hôte spécifié dans la zone Hostname de l'en-tête Syslog au lieu d'un nom d’hôte sous forme de chaîne. Par exemple, les services syslog-ng appellent cette option chain_hostname.

(Haut de la page)