Il s'agit du deuxième article de la série, consacré à la méthodologie de création de règles de corrélation prêtes à l'emploi pour les systèmes SIEM. Dans l' article précédent , nous nous sommes fixés cette tâche, décrit les avantages qui seront obtenus dans sa mise en œuvre, et également énuméré les principaux problèmes qui se dressent sur notre chemin. Dans cet article, nous allons commencer à chercher des solutions et à commencer par le problème de la transformation du modèle du «monde» , ainsi que sa manifestation au stade de la normalisation des événements.



Le problème de la transformation du modèle du «monde» a été décrit dans le premier article. Rappelons brièvement son essence: lorsqu'un phénomène se produit à la source d'événements (par exemple, le démarrage d'un processus dans l'OS), il est fixé dans différents formats, d'abord en mémoire, puis dans le journal des événements OS puis dans le système SIEM. Chaque étape du traitement s'accompagne d'une perte de données, car au niveau du système d'exploitation, il existe un modèle «mondial» et, dans le journal du système d'exploitation, un autre, limité par un ensemble de champs, par le schéma de journalisation. Ainsi, il y a une réflexion (transformation) d'un modèle avec un grand nombre de paramètres vers un autre, avec un plus petit nombre d'entre eux. La normalisation et la sauvegarde d'un événement dans SIEM est une autre transformation qui se produit également avec la perte de données, puisque SIEM a également son propre modèle «monde».

Il est difficile de trouver un moyen qui permettrait de transformer un modèle en un autre sans perte. Connaissant cette limitation, il est nécessaire de formuler une telle approche de la normalisation et de la formation d'une liste de champs du schéma d'événements, dans lesquels les informations ne seraient pas perdues, importantes pour la corrélation et la poursuite des enquêtes sur les incidents de sécurité de l'information.

Dans le cadre de SIEM, un modèle est représenté par un schéma - un ensemble de champs dans lesquels les données de l'événement initial s'inscrivent dans le processus de normalisation. À l'avenir, il sera utilisé par des spécialistes pour créer des règles de corrélation. Pour que les enquêteurs sur les incidents et les responsables de l'élaboration des règles de corrélation interprètent sans ambiguïté les événements normalisés, le schéma doit satisfaire aux propriétés de base:

• être unifié pour les événements de tout type et de toute source;
• décrire clairement qui a interagi avec qui et comment;
• garder l'essence et le contexte de l'interaction.

Dans le processus d'élaboration des règles de normalisation, des informations sur l'interaction doivent être trouvées dans l'événement initial et décomposées en champs spécialement désignés. La même chose doit être faite avec le contexte et l'essence de l'interaction (plus à ce sujet dans le prochain article).

La question se pose: est-il possible d'identifier des schémas typiques d'interactions qui satisferaient tout événement créé par toutes les sources possibles de sécurité informatique et de l'information? Si oui, à quoi ressemblent ces régimes?

Pour trouver la réponse à ces questions, vous devez vous tourner vers l'analyse et essayer d'analyser autant de règles de normalisation déjà développées et fonctionnant dans les solutions SIEM que possible pour identifier les modèles courants. Dans le cadre de ces travaux, il a été possible d'analyser plus de 3 000 règles de normalisation à partir de plus de 100 sources différentes à partir de solutions telles que Positive Technologies MaxPatrol SIEM et Micro Focus ArcSight. L'analyse a abouti aux conclusions suivantes:

1. Il existe des schémas d'interaction typiques.
2. Dans chaque événement individuel, en règle générale, il existe des informations sur l'interaction au niveau du réseau et au niveau de l'application .
3. Les schémas d'interaction typiques peuvent varier à différents niveaux, et cela doit être pris en compte.

Schémas de communication de couche réseau et application

Nous décrivons des schémas typiques pour chaque niveau. Avant cela, vous devez mettre en évidence les entités qui sont toujours présentes dans les événements. En outre, sur la base de ceux-ci, des schémas d'interaction seront construits. Cela comprend:

• Objet . Une entité qui affecte un objet. Par exemple, un utilisateur changeant une clé de registre ou un hôte avec IP 10.0.0.1, envoyant un paquet à un hôte avec IP 20.0.0.1.
• Objet . L'entité affectée par le sujet.
• Source En règle générale, un hôte qui enregistre l'interaction du sujet avec l'objet et génère l'événement lui-même. Par exemple, la source sera un pare-feu qui enregistrera la transmission des paquets de l'hôte - le sujet avec IP 10.0.0.1, à l'hôte - l'objet avec IP 20.0.0.1.
• Émetteur Il y a des cas où SIEM reçoit des événements non pas directement de la source, mais d'un serveur intermédiaire à travers lequel ces événements passent. L'exemple le plus simple est un serveur Syslog intermédiaire. Un exemple est plus compliqué - lorsque le transmetteur peut être un serveur de gestion, par exemple, Kaspersky Security Center. Dans ce cas, la source est un agent spécifique de Kaspersky Endpoint Security.

Cependant, toutes les entités ne peuvent pas être représentées simultanément dans l'événement (plus de détails plus loin), il est donc important de conclure initialement des accords, car dans ce cas, les champs correspondants du schéma sont remplis. Cela aidera à l'avenir à distinguer clairement les cas dans lesquels ces champs n'ont pas été remplis en raison d'une erreur d'un spécialiste qui élabore des règles de normalisation des cas dans lesquels l'événement d'origine ne contenait pas vraiment de données sur une entité.

Passons maintenant aux modèles d'interaction et aux exemples d'événements. Pour plus de clarté, tous les exemples seront donnés sur la base de journaux de fichiers, de messages syslog ou d'enregistrements dans une base de données relationnelle, mais ils peuvent être utilisés pour d'autres formats de journaux, par exemple binaires.

Niveau réseau

L'identifiant principal pour les entités au niveau du réseau est les adresses IP. Il est important de comprendre qu'il peut y avoir d'autres identificateurs associés - adresses MAC au niveau du canal, FQDN - au niveau de l'application. La question se pose: parlent-ils de la même entité ou d'une entité différente? Ces identifiants peuvent-ils évoluer dans le temps avec la même entité? Un article séparé sera consacré à cela. Insistons maintenant sur le fait que l'identifiant principal des modèles d'interaction au niveau du réseau est l'adresse IP.

Ainsi, les schémas d'interaction typiques de ce niveau peuvent être divisés en deux classes - de base et dégénérés.

Schémas d'interaction de base

Schéma 1. Schéma d'interaction complet

Dans le cadre de ce modèle, en cas de réception à l'entrée SIEM, toutes les entités principales peuvent être distinguées: Sujet, Objet, Source, Emetteur. Dans le schéma d'interaction, le sujet agit sur l'objet. Cet effet enregistre (observe) la source et génère un événement. L'événement de la source entre dans l'émetteur et de celui-ci entre dans le SIEM.

L'événement ci-dessous capture la résolution de l'interaction réseau entre les hôtes par le pare-feu Stonesoft (maintenant Forcepoint), tandis que l'événement lui-même n'entre pas directement dans SIEM, mais à partir d'un serveur syslog intermédiaire.



Ici:
40.0.0.1 - Emetteur (serveur syslog intermédiaire),
30.0.0.1 - Source (nœud de pare-feu),
10.0.0.1 - Sujet (envoi de paquets UDP),
20.0.0.1 - Un objet (recevant des paquets UDP).


Diagramme 2: Diagramme de collecte directe sans émetteur

Un émetteur n'est pas toujours dans le schéma d'interaction. En règle générale, il est présent lorsqu'un serveur intermédiaire (par exemple, un serveur Syslog) est utilisé pour transmettre des événements, ou lorsque la solution à partir de laquelle les événements sont collectés dispose d'un système de gestion centralisé - par exemple, Kaspersky Security Center, Check Point Smart Console ou Cisco Prime. Dans ce schéma, les événements tombent dans SIEM directement à partir de la source. La plupart de tous les événements sont décrits par ce schéma particulier. À propos, un exemple d'un tel événement peut être vu sur la figure 1 , s'il n'y avait pas de serveur Syslog intermédiaire et que nous recevions des événements directement du pare-feu.



Ici:
30.0.0.1 - Source (nœud de pare-feu),
10.0.0.1 - Sujet (envoi de paquets UDP),
20.0.0.1 - Un objet (recevant des paquets UDP).


Schéma 3. Interaction avec de nombreux objets

Ce schéma d'interaction au niveau du réseau est assez rare et, en règle générale, est typique des événements de l'équipement réseau. Dans le schéma, un sujet interagit avec de nombreux objets, une interaction similaire est présente dans les événements qui décrivent des diffusions multicast, unicast ou broadcast.

Notez que parfois de nombreux objets peuvent être unis par un identifiant commun - une adresse de sous-réseau ou une adresse de diffusion. Cela doit être rappelé, car lors de l'analyse des événements, y compris au niveau des règles de corrélation, vous pouvez facilement ignorer l'interaction potentiellement importante, car dans ce schéma, l'adresse d'objet est cachée derrière l'adresse de groupe.

L'exemple suivant illustre un événement d'un serveur de relais IGMP via lequel une demande d'appartenance à multidiffusion est diffusée.



Ici:
30.0.0.1 - Source (serveur relais IGMP),
10.0.0.1 - Sujet (demande d'adhésion à un groupe),
224.0.0.252 - L'objet (adresse de multidiffusion).

Régimes dégénérés

Le sujet, l'objet et la source sont les entités de base du groupe des schémas d'interaction de base. Cependant, il y a des cas où l'une des entités peut être absente lors de l'événement.


Schéma 4. Interaction sans objet

Souvent, un tel modèle est typique dans les situations où le sujet rapporte un changement dans son état interne - c'est-à-dire qu'il agit simultanément dans le rôle du sujet et de l'objet. Par exemple, cette interaction peut être observée lors de changements de configuration ou d'événements de détection de logiciels malveillants sur le poste de travail. Mais ces informations ne sont pas enregistrées par le Sujet lui-même, mais par un système de gestion centralisé et stockées dans son journal.

L'exemple montre comment Symantec Management Server capture que l'agent Symantec Endpoint Protection qu'il gère a détecté un fichier malveillant sur son hôte.



Ici:
30.0.0.1 - Source (Symantec Management Server),
10.0.0.1 - Objet (Symantec Endpoint Protection Agent).


Schéma 5. Combiner le rôle du sujet et de l'objet dans la source

Le dernier schéma d'interaction dégénérée est typique d'une situation où SIEM reçoit des événements d'une source signalant un changement de son état interne: par exemple, reconfigurer un périphérique ou un logiciel, activer ou désactiver un port réseau. Dans un tel schéma, le rôle de la source coïncide avec le rôle du sujet et de l'objet. Contrairement au schéma précédent, les événements dans SIEM viennent directement.

Dans cet exemple, un commutateur basé sur Cisco IOS signale que son interface est passée à l'état UP.



Ici, 30.0.0.1 est la source (commutateur).

Niveau d'application

A ce niveau, il existe des interactions d'entités déjà connues: Sujet, Objet. Cependant, toutes les informations sur la source et l'émetteur restent directement au niveau du réseau et ne sont pas reflétées au niveau de l'application.

La plupart de tous les types d'événements intègrent des interactions simultanément au niveau du réseau et au niveau de l'application. Cependant, nous notons que les événements générés directement par le logiciel d'application, par exemple, 1C: Enterprise, Microsoft SQL Server ou Oracle Database, peuvent contenir exclusivement des interactions au niveau de l'application.

De plus, une entité Ressource supplémentaire apparaît au niveau de l'application.

Une ressource est une entité intermédiaire par laquelle le sujet exerce une influence sur l'objet sans interaction directe. Par exemple, accorder à Alex les droits d'accès au MyFile à Bob. Ici Alex est le sujet, Bob est l'objet, MyFile est la ressource. Veuillez noter que dans cet exemple, Alex n'interagit pas directement avec Bob.

Important : les événements au niveau de l'application peuvent contenir à la fois des paramètres supplémentaires du sujet et de l'objet, ainsi que la ressource elle-même. Par exemple, des paramètres supplémentaires d'une telle ressource comme un «fichier» peuvent être le répertoire dans lequel elle se trouve ou sa taille.
Dans ce cas, le sujet, l'objet et la ressource sont identifiés par un nom ou un identifiant unique: adresse e-mail, nom de fichier, nom de répertoire, nom de table dans la base de données.

Envisagez des modèles d'interaction supplémentaires spécifiques au niveau d'application.


Figure 6. Interaction des ressources

Dans ce diagramme, le sujet agit indirectement sur l'objet via une ressource intermédiaire. En règle générale, les événements avec un tel schéma sont clairement visibles dans les journaux d'audit de la base de données ou lorsque vous travaillez avec des droits d'accès aux fichiers et répertoires au niveau du système d'exploitation.

L'exemple montre une entrée de la base de données d'audit de la base de données Oracle. Il corrige le processus de révocation d'un rôle d'un utilisateur.



Ici:
"ALEX" - Sujet (nom d'utilisateur qui retire le rôle),
"BOB" - Objet (nom de l'utilisateur qui est révoqué),
"ROLE" - Ressource (nom du rôle révoqué).


Diagramme 7. Interaction avec de nombreuses ressources

Au niveau de l'application, ainsi qu'au niveau du réseau, il existe de tels types d'événements dans lesquels le sujet interagit immédiatement avec l'objet via de nombreuses ressources. C'est très rare, mais il y a des moments où le nombre d'objets est également supérieur à un. Ces types d'événements apparaissent lors de la correction des opérations en bloc. Par exemple, accorder l'accès à plusieurs fichiers à un seul utilisateur ou modifier l'ensemble de règles incluses dans la stratégie.

Dans l'exemple, la solution de protection des environnements virtuels vGate Security Code capture l'ajout de nouvelles stratégies à l'ensemble.



Ici:
"Admin @ VGATE" - Objet (nom de l'utilisateur qui modifie l'ensemble de politiques)
"Base" - Objet (ensemble de politiques)
«Installation et maintien de l'intégrité du système de fichiers», «Vérification des paramètres de l'agent SNMP», «Désactivation de l'installation automatique de VMware Tools» - Ressources (noms des politiques ajoutées)

Le modèle du canal d'interaction entre le Sujet et l'Objet

Sur tous les schémas, nous avons distingué différentes entités (sujets, objets, ressources, sources, émetteurs) et noté le soi-disant canal d'interaction entre elles. Attardons-nous plus en détail sur l'avant-dernière composante du grand modèle «monde» avec lequel SIEM doit fonctionner - sur les modèles du canal d'interaction entre le Sujet et l'Objet. Rappelons que le dernier volet est le contexte de l'interaction (le prochain article y sera consacré).

Il y a donc deux entités interagissant l'une avec l'autre. Dans le cadre de cette interaction, les données sont transférées d'une entité à une autre. Il peut s'agir de paquets réseau avec des données, des fichiers ou des commandes de gestion. Dans ce cas, le canal formé peut être représenté sous la forme d'un «tuyau» le long duquel il y a un flux dirigé de données et de commandes. Un tel modèle est clairement visible au niveau du réseau, mais moins prononcé au niveau de l'application (voir exemple ).


Modèle de canal de données

Sur la base d'un tel modèle, chaque événement reçu par le SIEM peut contenir des informations décrivant:

• Les paramètres du canal lui-même sont le «pipe»,
• Les données transmises par ce «tuyau».

Typiquement, un canal est décrit par des paramètres tels que l'identifiant de session, le protocole de transfert de données, le temps d'établissement du canal, le temps d'achèvement, la durée. Les données dans les événements sont caractérisées par le format utilisé par les algorithmes de chiffrement, le nombre de paquets transmis, le nombre d'octets transmis.

Prenons l'exemple d'un événement qui contient des données sur le canal d'interaction. Voici un événement du Cisco Identity Services Engine (ISE), un système de gestion des processus pour identifier et contrôler l'accès, qui enregistre la session réseau d'un utilisateur dans le cadre de la procédure de comptabilité (comptabilité).




Ici:
"Acct-Session-Id = 1A346216", "Acct-Session-Time = 50", "Service-Type = Framed", "Framed-Protocol = PPP" - paramètres du canal de communication,
"Acct-Input-Octets = 43525", "Acct-Output-Octets = 122215", "Acct-Input-Packets = 234", "Acct-Output-Packets = 466" - paramètres des données transmises sur le canal.

Un exemple de modèles d'interaction des entités et du canal dans un événement

Nous avons donc examiné les schémas d'interaction des niveaux et des applications du réseau, ainsi que le modèle du canal d'interaction. Ensuite, nous montrons un exemple de la façon dont dans un événement les schémas d'interaction de différents niveaux sont combinés et des informations sur le modèle de canal sont utilisées.

Ici, nous voyons un événement du pare-feu - le Cisco Adaptive Security Appliance (ASA), dans lequel une connexion TCP sortante est fixée.



L'exemple montre clairement que dans un événement, il existe des entités du niveau réseau et du niveau application. Au niveau du réseau, un schéma d'interaction entre le sujet et l'objet, qui est fixé par la source. Il n'y a pas d'émetteur.

Ici:
30.0.0.1 - Source (Cisco ASA),
10.0.0.1 - Sujet (l'adresse de celui qui se connecte),
20.0.0.1 - Un objet (l'adresse de celui à qui ils se connectent).

Au niveau de l'application, un schéma simple dans lequel seuls le sujet et l'objet sont présents:
"ALEX" - Sujet (nom d'utilisateur qui se connecte),
"BOB" - L'objet (le nom de l'utilisateur auquel il se connecte).

Dans cet événement également, il y a une description du canal de transmission de données, mais il n'y a pas de description des données elles-mêmes:
"TCP" est le protocole sur la base duquel le canal a été créé,
"136247" est l'identifiant de session de canal.

Conclusions

Comment les schémas d'interaction typiques mis en évidence par nous peuvent-ils aider?

• Tout d'abord , lors de la rédaction des règles de corrélation et de l'analyse des événements, un expert doit comprendre quelles entités sont présentes dans chaque événement qui arrive au SIEM. Pour cela, il est nécessaire, au stade de la normalisation des événements, d'identifier clairement les entités: Sujet, Objet, Ressource, Source et Emetteur.
• Deuxièmement , lors de la normalisation, il est important de tenir compte du fait que l'événement contient des informations à la fois sur l'interaction du niveau réseau et du niveau application. Ces deux interactions peuvent être simultanément présentes dans un même événement.
• Troisièmement , l'interaction elle-même est une structure composite dans laquelle il y a des informations sur le canal formé et sur les données transmises par ce canal.

Ainsi, le modèle du «monde», qui est construit dans SIEM et est représenté par un ensemble de champs (un schéma), devrait contenir des sections pour décrire:

1. Au niveau du réseau :
   
   • Sujet;
   • L'objet;
   • Source;
   • Émetteur
   • Canal d'interaction;
   • Données transmises sur le canal.
   
   
2. Au niveau applicatif :
   
   • Sujet;
   • Un objet ou une pluralité d'objets;
   • Une ressource ou plusieurs ressources.
   
   

, . IP-, MAC- FQDN. — ID. .

, . , . .

: . , , , , .

, . , .

, , :


,

— «» SIEM , . , , Alex , — , , , . , . , - , , SIEM .

, , . , , .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «» ( )

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5.