Imaginez la situation: vous avez passé beaucoup de temps à écrire et déboguer des règles de corrélation, et un jour plus tard, vous avez constaté qu'elles ne fonctionnaient pas. Comme on dit, cela ne s'est jamais produit et là encore! Il s'avère ensuite que la nuit, le réseau a été à nouveau mis à niveau et que quelques serveurs ont été remplacés, mais les règles de corrélation n'en tiennent pas compte. Dans cet article, nous expliquerons comment enseigner au SIEM à s'adapter au paysage en constante évolution des infrastructures.



Nous nous rapprochons de plus en plus de la fin de la série d'articles consacrés à la création de règles de corrélation adaptatives qui fonctionnent dès le départ. L'article s'est avéré long, celui qui veut peut immédiatement tirer des conclusions .

Dans l'article «Méthodologie de normalisation des événements», nous avons résumé les techniques qui aideront à minimiser le problème de perte de données et de normalisation incorrecte des événements initiaux. Cependant, peut-on affirmer que, si le rôle des erreurs de normalisation est réduit, il est possible de créer des règles de corrélation prêtes à l'emploi? Théoriquement, oui, si l'objet de surveillance surveillé par SIEM serait statique et fonctionnerait exclusivement comme indiqué dans les termes de référence. Mais en pratique, il s'avère que dans le monde réel, il n'y a rien de statique.

Examinons donc de plus près l'objet de surveillance. SIEM collecte des journaux à partir de sources, à partir desquelles il extrait les adresses IP, les comptes d'utilisateurs, l'accès aux fichiers et aux clés de registre, les interactions réseau. Si tout est résumé, ce n'est rien de plus que des informations sur les étapes du cycle de vie d'un système automatisé (ci-après - AS). Ainsi, l'objet de surveillance SIEM est un système automatisé dans son ensemble ou une partie de celui-ci.

Un système de haut-parleurs n'est pas un objet statique, il a tendance à changer constamment: de nouveaux travaux et serveurs sont introduits, les anciens équipements sont mis hors service et remplacés par de nouveaux, les systèmes «plantent» en raison d'erreurs et sont restaurés à partir de sauvegardes. La dynamique au niveau du réseau, comme l'adressage ou le routage dynamique, change quotidiennement le visage des haut-parleurs. Comment le vérifier? Essayez de trouver dans votre entreprise un schéma L3 complet et actuel du réseau et vérifiez auprès des administrateurs réseau dans quelle mesure il reflète l'état actuel des choses.

Lorsque vous développez des règles de corrélation, vous essayez de partir de ce à quoi ressemblent les haut-parleurs ici et maintenant. En testant les règles de corrélation, vous les affinez à un état dans lequel elles sont capables de travailler avec le moins de faux positifs dans la configuration actuelle des enceintes. Les locuteurs étant en constante évolution, les règles de corrélation devront tôt ou tard être mises à jour.

Maintenant, compliquons la tâche et considérons les règles fournies par des experts externes, tels que les SOC commerciaux, les intégrateurs implémentant SIEM ou les développeurs de solutions SIEM eux-mêmes. Ces règles n'incluent pas les fonctionnalités de vos enceintes - le contexte d'exécution - elles ne sont pas optimisées pour elles. Ce problème est une autre pierre d'achoppement dans le concept de règles de corrélation qui sortent du cadre. Sa solution peut être que SIEM en lui-même:

1. Construit un modèle des haut-parleurs observés.
2. Maintient toujours ce modèle à jour.
3. Vous permet d'utiliser ce modèle comme contexte d'exécution dans les règles de corrélation.

Contexte - Modèle de système automatisé

Tout d'abord, nous décrivons la composition du modèle de haut-parleur. Si nous nous tournons vers la définition classique d'un terme de GOST 34.003-90 , alors un AS est «un système composé de personnel et d'un ensemble d'outils d'automatisation pour ses activités qui met en œuvre la technologie de l'information pour effectuer des fonctions établies». Il est important que lors de la mise en œuvre des technologies de l'information, le personnel (utilisateurs) et les outils d'automatisation fonctionnent sur les données.

Étant donné que SIEM recueille des informations à partir de nombreuses sources différentes, y compris l'informatique, la sécurité de l'information et les applications commerciales, toutes les parties de cette définition seront «visibles» pour nous directement dans les événements.

Ensuite, nous décrirons à quoi ressemble le modèle créé pour des entités telles qu'un utilisateur, un ensemble d'outils d'automatisation (ci-après dénommés réseaux et systèmes informatiques) et des données.

Malheureusement, il est assez difficile de modéliser des processus technologiques dans le cadre du SIEM, car une telle classe de solutions n'est pas destinée à cela. Néanmoins, une partie des processus est visible à travers les modèles de comportement de ces entités.


Modèle d'enceinte générale

Nous examinerons ensuite chaque entité et nous attarderons sur:

• identification unique;
• la composition du modèle;
• trouver les données nécessaires au modèle;
• la nature de la modification des données d'entité;
• mettre à jour les données du modèle lorsqu'elles changent.

Modèle utilisateur

Identification

Un utilisateur d'un AS doit être compris comme une personne spécifique: un employé d'une entreprise, un entrepreneur ou un pigiste. Il est important qu'il ait autorisé l'accès aux orateurs.

Les informations sur les utilisateurs AS sont généralement fragmentées dans de nombreux systèmes. Pour l'assembler, vous devez faire un effort. Regardons un exemple où et quelles informations peuvent être collectées pour un utilisateur spécifique.

1. Microsoft Active Directory et Microsoft Exchange. À partir d'eux, nous pouvons découvrir son nom de domaine principal et son adresse e-mail.
2. Cisco Identity Services Engine (ISE) stocke sa deuxième connexion pour un accès à distance via VPN.
3. La base de données du portail interne stocke sa troisième connexion.
4. Si l'utilisateur est un administrateur de base de données, la quatrième connexion est stockée dans le SGBD, et peut-être pas une.
5. Base de données RH, dans laquelle son nom complet est stocké (au cas où Active Directory était trop paresseux pour obtenir l'utilisateur selon toutes les règles).

Ainsi, si l'entreprise ne dispose pas de solutions de gestion des identités ou de gestion des droits des utilisateurs qui permettent au moins de rassembler ces informations d'identification disparates, vous devrez le faire vous-même manuellement dans SIEM.

Pour résumer:

1. SIEM nécessite un seul ID utilisateur.
2. Lorsque des comptes d'utilisateurs apparaissent dans un journal, quel que soit le système, nous devons l'identifier de manière unique et apposer notre propre identifiant utilisateur unique.

Composition du modèle

Composant un modèle de n'importe quelle entité, nous le divisons en deux blocs. Le premier bloc est utilisé pour stocker des informations générales sur l'entité, le second est responsable de la compilation d'un modèle de comportement de l'entité. Ce profil peut être utilisé par des règles de corrélation pour identifier les écarts anormaux dans le comportement d'une entité.

Au minimum, les éléments suivants doivent être inclus dans le modèle utilisateur général:

• ID utilisateur unique dans SIEM
• tous ses identifiants provenant de divers systèmes, notamment:
  
  • adresses e-mail externes et internes;
  • Nom complet;
  • Compte OS local
  • compte de domaine;
  • Compte VPN
  • Compte proxy
  • Comptes SGBD
  • Comptes dans d'autres systèmes d'application.
• Unité d'organisation dans Microsoft Active Directory à laquelle l'utilisateur est membre;
• Groupes Microsoft Active Directory dont l'utilisateur est membre.

Au minimum, le modèle de comportement d'un utilisateur doit comprendre:

• type de connexion utilisé (local, distant) et type de canal de communication (filaire, sans fil);
• les appareils utilisés pour accéder au réseau d'entreprise;
• applications utilisées;
• géolocalisation, en particulier pour les utilisateurs distants;
• les ressources de l'entreprise auxquelles l'utilisateur se connecte;
• à qui et quoi les transferts de données (flux d'informations).

Modèle utilisateur

Le profilage des flux d'informations est une tâche difficile pour laquelle SIEM manque souvent de mécanismes pratiques et simples. Mais la création d'un tel profil peut commencer par la messagerie et les ressources réseau partagées utilisées.

Sources de données pour le modèle

Où obtenir les données nécessaires à la construction du modèle? Considérez les deux principes principaux pour obtenir les informations disponibles dans la plupart des SIEM - les méthodes de collecte actives et passives.

Avec la méthode active, SIEM se tourne vers des sources contenant les données nécessaires à la construction du modèle.
Avec la méthode passive, le modèle est rempli à partir des données des événements reçus dans SIEM des sources.

En règle générale, pour obtenir le modèle le plus complet, il est préférable de combiner deux méthodes.

Il est important de comprendre que les données collectées dans le cadre du modèle doivent être constamment mises à jour et effectuées en mode automatique plutôt que manuel. Exactement les mêmes méthodes que celles utilisées pour leur collecte initiale conviendront pour la mise à jour des données.

Déterminez quelles sources peuvent fournir des données pour la construction du modèle et de quelle manière vous pouvez obtenir les informations nécessaires.

Modèle de réseaux et de systèmes informatiques

Identification

Par éléments de réseau et de systèmes informatiques, nous entendons les postes de travail, les équipements de serveur et de réseau et les outils de sécurité de l'information. À l'heure actuelle, dans SIEM et dans les solutions de gestion de la vulnérabilité, ils sont appelés actifs.

Il semble évident que ces actifs peuvent être facilement identifiés par leur adresse IP, leur adresse MAC, leur nom de domaine complet ou leur nom d'hôte (ci-après dénommés les clés d'identification d'origine). Est-ce toujours le cas? Comme indiqué ci-dessus, certains changements se produisent constamment au sein de l'UA. Voyons quelques-uns de ces changements et réfléchissons au comportement de nos clés d'identification d'origine.

1. Utiliser sur un réseau DHCP. Les adresses IP des actifs changent.
2. Commutation de nœuds dans une configuration de cluster. Selon le type de clustering, MAC et IP peuvent changer.
3. Restauration d'un système à partir d'une sauvegarde sur un autre serveur en raison d'une panne critique. Les adresses MAC changent, parfois IP, FQDN et Hostname.
4. Remplacement prévu, modernisation de l'équipement ou des pièces d'enceintes. Presque toutes les clés peuvent changer.

Dans une petite entreprise, ces changements peuvent être extrêmement rares et peuvent être traités par les experts en charge du SIEM. Mais que faire si une entreprise avec un large réseau de succursales? Et loin d'être toujours le service SI a des communications bien établies avec le service informatique, ce qui signifie que l'expert SIEM peut ne pas obtenir les informations nécessaires sur les changements dans l'AS.

Étant donné que vous ne pouvez pas compter séparément sur IP, MAC, FQDN ou Hostname pour identifier un actif, vous pouvez essayer d'identifier immédiatement l'actif par les 4 paramètres. Ici, nous sommes confrontés à un problème global: SIEM fonctionne sur des événements, et ils ne contiennent presque jamais toutes les clés d'identification originales en même temps.

Comment peut-il être résolu? Examinons quelques options:

1. Méthode active utilisant des solutions de niveau base de données de gestion de configuration (CMDB) . Les informations sur les clés d'identification originales peuvent être prises à partir de là. Mais la CMDB contient-elle toutes les clés source des actifs nécessaires à l'identification? Et, plus important encore, tient-il compte des changements d'enceintes décrits ci-dessus? Il est également important de prendre en compte le temps de mise à jour des données dans CMDB, si les données accusent un retard de dizaines de minutes ou d'heures par rapport à l'état réel des haut-parleurs - très probablement, cette solution ne sera pas adaptée à une utilisation dans la corrélation de flux d'événements dans SIEM.
2. Manière active en utilisant la solution de gestion des vulnérabilités . Vous pouvez télécharger ses rapports sur SIEM, comme, par exemple, Micro Focus ArcSight. Mais existe-t-il une garantie qu'un scanner tiers apportera toutes les données nécessaires à l'identification? Quelle sera leur pertinence si les analyses ne sont pas effectuées plus d'une fois par mois (moyenne pour les grandes entreprises), et loin de couvrir l'ensemble de l'infrastructure.
3. Voie passive . Identifiez les actifs des événements, malgré leurs données incomplètes et inexactes. Les événements ne contiennent pas toutes les clés; différentes sources envoient différents jeux de clés. Cependant, c'est le moyen le plus rapide d'obtenir des informations sur les changements de haut-parleurs. En règle générale, les sources génèrent des événements dans toutes les situations décrites ci-dessus, à l'exception du remplacement prévu de l'équipement.
4. Voie hybride . Profitez de toutes les approches à la fois:
   
   • La collecte active avec CMDB permet un remplissage initial initial des actifs SIEM.
   • L'intégration avec Vulnerability Management ajoutera les informations manquantes.
   • Une analyse des événements vous permettra de mettre à jour rapidement le modèle, en tenant compte des spécificités de chaque source individuellement.
   
   La méthode hybride permet de niveler les problèmes des autres, mais elle est difficile à mettre en œuvre.

Pour le moment, je n'ai travaillé qu'avec deux solutions où les fabricants avaient l'expertise pour mettre en œuvre cette approche - IBM QRadar (description générale par référence , les détails de l'algorithme sont fermés) et Positive Technologies MaxPatrol SIEM (les détails de l'algorithme sont fermés). À l'heure actuelle, les deux sociétés continuent d'utiliser et d'améliorer précisément l'approche hybride.

Donc:

1. Les postes de travail, les équipements de réseau et de serveur doivent être identifiés de manière hybride, en agrégeant les données de CMDB, les systèmes de gestion de la vulnérabilité et les événements des sources elles-mêmes.
2. Pour la combinaison correcte et la mise à jour des informations collectées pour l'identification, il est nécessaire de disposer de mécanismes experts qui prennent en compte les caractéristiques de chaque source.

Composition du modèle

Les systèmes informatiques, y compris les logiciels système et applicatifs qui y sont installés, transportent de nombreuses informations nécessaires pour améliorer la précision des règles de corrélation.

Tout comme le modèle utilisateur, le modèle des réseaux et des systèmes informatiques se compose d'une partie commune et comportementale.

La composition du modèle général des réseaux et des systèmes informatiques devrait au moins comprendre:

• matériel (y compris les périphériques externes);
• liquider les utilisateurs;
• les services installés et leur ensemble avec des ports ouverts;
• logiciel installé et sa version;
• mises à jour installées;
• vulnérabilités existantes;
• tâches planifiées
• liste des logiciels pour le démarrage;
• tables de routage;
• ressources réseau partagées.

La composition du modèle comportemental des réseaux et des systèmes informatiques devrait comprendre au moins:

• Interactions réseau de L3 et L4 (avec ce qui interagit et selon quels protocoles);
• La quantité moyenne de données transmises par semaine;
• quels utilisateurs utilisent;
• à partir de quels nœuds la télécommande est implémentée;
• statistiques du fonctionnement des fonctionnalités de sécurité pour cet hôte (réseau et local).

Modèle de réseaux et de systèmes informatiques

Sources de données pour le modèle

La collecte d'informations pour ce modèle est possible de deux manières: active et passive.

Considérez le modèle général:

Modèle de données protégé

Identification

Passons au dernier composant du contexte - le modèle de données protégé.

Le plus souvent, SIEM n'est pas utilisé pour surveiller les données protégées, car il existe des solutions pour la classe DLP (Data Leak Prevention). Cependant, ces connaissances permettent d'évaluer plus précisément l'importance de l'incident. Par exemple, lors de la rédaction d'une règle de corrélation, il serait utile de savoir que l'incident ne se produit pas uniquement sur un poste de travail, mais sur celui qui stocke actuellement le rapport financier de l'année ou d'autres informations confidentielles.

L'identification des informations confidentielles est implémentée par un moteur de recherche d'empreintes digitales dans la solution DLP elle-même. La spécificité du mécanisme ne permet pas de le mettre en œuvre au sein de SIEM. Ainsi, en termes d'identification des données protégées, il est possible de n'utiliser qu'une intégration étroite avec les solutions de classe DLP.

Composition du modèle

Étant donné que DLP met en œuvre la plupart de la surveillance et de la protection des informations confidentielles, la composition du modèle dans SIEM est assez compacte.

Au minimum, les éléments suivants devraient être inclus dans le modèle général des données protégées:

• sur quels actifs les informations confidentielles sont stockées;
• quels utilisateurs ont accès à des informations confidentielles.

Au moins les éléments suivants devraient être inclus dans le modèle comportemental des données protégées:

• entre quels actifs des informations confidentielles sont-elles transmises;
• entre quels utilisateurs des informations confidentielles sont transmises.

Modèle de données protégé

Sources de données pour le modèle

Pour construire un modèle de données protégées, deux méthodes d'obtention d'informations sont également disponibles: active et passive.

Considérez le modèle général:

Modéliser les mécanismes de mise en œuvre dans SIEM

Voyons comment il est possible d'implémenter un modèle de haut-parleur dans SIEM. Pour ce faire, au niveau du SIEM, deux problèmes principaux doivent être résolus:

1. Comment mettre en œuvre la collecte de données active et passive.
2. Où et sous quelle forme stocker le modèle.

La collecte active des données pour le modèle est généralement effectuée par des mécanismes d'intégration SIEM avec des scanners de sécurité. En outre, la collecte active peut être effectuée en téléchargeant des données à partir de sources externes, par exemple, des bases de données.

La collecte passive est réalisée en analysant les événements passant par le SIEM.

En règle générale, dans SIEM de la génération actuelle pour stocker les données de modèle ci-dessus, les listes de tables / liste active / ensemble de référence et similaires sont utilisées. Avec la collecte de données active, des tâches planifiées sont créées pour les remplir à partir de sources externes. Avec la collecte passive, des règles de corrélation distinctes sont créées, au sein desquelles, lorsque les événements nécessaires apparaissent (création d'utilisateurs, suppression de logiciels, transfert de fichiers, etc.), les données de l'événement sont insérées dans la liste des tableaux.

Dans le cas général, toutes les solutions SIEM modernes contiennent tous les éléments nécessaires pour créer et remplir les données du modèle AC décrit.

L'historicité du modèle

L'AS est en constante évolution, il est important de tenir compte, sinon dans les règles de corrélation elles-mêmes, car elles fonctionnent en mode quasi-temps réel et fonctionnent sur l'état actuel de l'AS, puis lors de l'enquête sur un incident. Des minutes, des heures et parfois des mois peuvent s'écouler entre le début d'un incident et son enquête. Avec certaines attaques, jusqu'à 6 mois peuvent s'écouler entre l'introduction d'un attaquant dans le système et la détection SIEM de ses activités ( 2018 Cost of a Data Breach Study by Ponemon ). Pendant ce temps, le paysage du système peut changer radicalement: des utilisateurs sont ajoutés et supprimés, la configuration de l'équipement a changé, l'équipement important pour l'enquête sur l'incident est hors service et les données copiées par l'attaquant d'un hôte ont «débordé» sur un autre. Par conséquent, au cours de l'enquête, il est important d'examiner le modèle de système dans l'état dans lequel il se trouvait au moment de l'incident, et non pas dans l'actuel, lorsque nous avons commencé à enquêter.

: , SIEM, , .

Conclusions

:

1. , , .
2. .
3. SIEM .
4. :
   
   • ;
   • , ;
   • .
5. , , :
   
   • ;
   • .
6. , . .
7. .
8. , , , .
9. SIEM .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4. ( )

SIEM: « ». 5.