entrant avec une balise DestinationIP qui correspond à la colonne IP et une balise d'événement AttackId qui correspond à la colonne NormalizedAttackId, le résultat est un (1).
Si aucune correspondance n'est trouvée sur la même ligne, le résultat est zéro (0).
Intégration des sources de données
L'utilisation d'une technologie adaptable et flexible réside au cœur de la stratégie d'intégration de source de données de Sentinel, stratégie appliquée grâce à des collecteurs d'interprétation
(également nommés collecteurs) qui analysent et normalisent les événements du flux de données.
Ces collecteurs peuvent être modifiés selon les besoins et ne sont liés à aucun environnement spécifique. La création, la modification, la maintenance et le déploiement des collecteurs sont simples et peuvent être effectués directement par les utilisateurs. Un environnement de déploiement intégré permet de créer des collecteurs de manière interactive via glisser-déposer
à partir d'une interface utilisateur. Dans la mesure où des utilisateurs autres que les programmeurs peuvent créer des collecteurs, les besoins actuels et futurs sont satisfaits dans un environnement informatique qui évolue constamment. Le contrôle des collecteurs
(par exemple, démarrage ou arrêt) s'effectue de manière centrale à partir du Centre de contrôle Sentinel.
Intégration des applications
L'intégration des applications externes via des API standard est centrale à Sentinel. Par exemple, une API bidirectionnelle destinée aux systèmes de ticket de dépannage incluant
Remedy® et ServiceDesk® de HP OpenView permet une intégration directe des systèmes externes.
L'API reposant sur les services Web permet aux systèmes externes compatibles SOAP de tirer parti d'une intégration totale au système Sentinel.
Heure
L'heure d'un événement est déterminante pour son traitement. Elle est importante pour la génération de rapports et l'audit, ainsi que pour le traitement en temps réel. Le moteur de corrélation traite les flux d'événements classés par heure et détecte les modèles existant dans les événements, ainsi que les schémas temporaires existant dans les flux. Cependant,
1-10
Guide de L'Utilisateur de Sentinel
le périphérique générant l'événement peut ne pas connaître l'heure réelle à laquelle l'événement est généré. Pour pallier cela, Sentinel propose deux options afin de traiter les alertes issues des périphériques de sécurité : se fier à l'heure signalée par le périphérique et utiliser cette heure comme heure de l'événement, ou ne pas se fier à l'heure signalée par le périphérique et à la place horodater l'événement à l'heure à laquelle il est traité pour la première fois par Sentinel (par le collecteur).
Sentinel est un système distribué et comprend plusieurs processus qui peuvent résider à divers endroits du réseau. En outre, le périphérique peut être à l'origine d'un certain retard. Pour pallier cela, les processus Sentinel reclassent les événements dans un flux basé sur l'heure avant de procéder au traitement.
L'illustration suivante décrit le concept de l'heure dans Sentinel.
1. Par défaut, l'heure d'événement est définie sur l'heure du composant Wizard, mais l'heure idéale serait celle des périphériques. Il est donc préférable de définir l'heure d'événement sur l'heure de périphérique si cette dernière est disponible, précise et correctement analysée par le collecteur.
2.
Une mémoire tampon d'heure configurable qui reclasse les événements et met à jour l'heure réelle affichée. L'heure par défaut est 30 secondes avant et après l'heure du serveur.
3. Une mémoire tampon de reclassement de corrélation, si l'heure d'événement est antérieure de 30 secondes à l'heure du serveur, auquel cas le moteur de corrélation ne traite pas les événements.
4. Si l'heure d'événement est antérieure de 5 minutes à l'heure de Wizard (heure correcte), les événements sont directement acheminés vers la base de données.
Présentation de Sentinel
1-11
Événements internes ou système
Les événements internes ou système permettent de rendre compte du statut et du changement de statut du système. Le système interne génère deux types d'événements, à savoir :
Les événements internes
Les événements de performances
Les événements internes fournissent des informations et décrivent un état unique ou un changement de statut du système. Ils signalent les cas où un utilisateur se connecte ou n'est pas authentifié, le démarrage d'un processus ou l'activation d'une règle de corrélation.
Les événements de performances sont générés périodiquement et décrivent l'utilisation moyenne des ressources par différents composants du système.
Tous les événements système renseignent les champs d'attribut suivants :
Le champ Type de capteur (ST - Sensor Type) : pour les événements internes, ce champ est défini sur I et, pour les événements de performances, sur P.
ID d'événement : un UUID unique de l'événement.
Heure d'événement : l'heure à laquelle l'événement a été généré.
Source : l'UUID du processus qui a généré l'événement.
Nom du capteur : le nom du processus qui a généré l'événement (par exemple,
DAS_Binary).
RV32 (Catégorie de périphérique) : défini sur ESEC.
Collecteur : « Performance » pour les événements de performances et « Internal » pour les événements internes.
Outre les attributs courants, chaque événement système définit également la ressource, la sous-ressource, la gravité, le nom de l'événement et les balises de message. Le nom d'un
événement interne est suffisamment spécifique pour identifier la signification exacte de l'événement (par exemple, UserAuthenticationFailed). Les balises de message apportent des détails spécifiques. Dans l'exemple ci-dessus, la balise de message contient le nom de l'utilisateur, le nom du système d'exploitation (si ce nom est disponible), ainsi que le nom de la machine. Le nom d'un événement de performances est un nom générique qui décrit le type des données statistiques, les données elles-mêmes figurant dans la balise de message.
Les événements de performances sont envoyés directement à la base de données. Pour les afficher, effectuez une interrogation rapide.
Voir l’annexe A : Événements système.
Processus
Le service Windows et les processus suivants communiquent entre eux via iSCALE, l'intergiciel orienté message (MOM).
Watchdog
Moteur Event Statistics
Data Synchronizer (Data Controller)
Correlation Engine
Processus RuleLg Checker (vérificateur de règle de corrélation)
Data Access Service (DAS)
– binaire, requête et Active Views™
Processus Query Manager
Sentinel Service (MSSQL uniquement) - Reportez-vous à
Watchdog
1-12
Guide de L'Utilisateur de Sentinel
