Et rien ne semblait de bon augure, mais à un moment donné, des réflexions sur la nécessité de travailler avec une plate-forme alternative sont apparues et sont devenues de plus en plus insistantes. Et la principale locomotive ici était le développement actif des centres GosSOPKA. Pour devenir l'un de ces centres, nous avons dû utiliser le logiciel fourni"Garantie et assistance technique par des organisations russes qui ne sont pas sous le contrôle direct ou indirect de personnes physiques étrangères et (ou) de personnes morales" (Arrêté du FSB du 06.05.2019 n ° 196, clause 3.4). Comment nous avons
Cadre de la série animée "Catdog"
On a entendu dire qu'il y a des SOC qui professent la
- Quelle solution choisir?
- Comment intégrer le nouveau système SIEM dans le fonctionnement TIER1?
- Comment toutes les nombreuses intégrations internes qu'ArcSight doivent actuellement être transférées vers la nouvelle plate-forme?
- Comment synchroniser l'idéologie de développement de contenu SIEM et fournir des ensembles symétriques de règles de détection?
Le choix d'une solution n'a pas été une tâche facile. Partout, nous devions plonger dans un tourbillon dont nous n'avions rien à estimer. En conséquence, nous avons décidé de faire un choix d'une manière différente - d'utiliser le SIEM du fournisseur, qui nous a promis une priorité élevée d'améliorations en fonction de nos exigences et dont nous avons cru aux promesses. Ainsi, un partenariat technologique avec Positive Technologies est né et MaxPatrol SIEM est apparu dans l'entonnoir de nos SIEM.
Ok, nous avons une nouvelle plateforme. Mais qui travaillera avec elle?
Pour être honnête, nous avions d'abord le sentiment que nous ne pouvions pas nous passer d'une deuxième équipe travaillant en parallèle avec la nouvelle boîte à outils. Ce sentiment a été renforcé par le fait que même les lignes d'analystes seniors qui ont participé aux tests du deuxième SIEM l'ont trouvé difficile à accepter. Par conséquent, dans un premier temps, le concept a été dessiné comme suit: deux lignes TIER1, chacune affûtée avec son propre instrument, et le TIER2 multi-plateforme. Avec le facteur de préparation multiplateforme comme facteur de croissance pour un spécialiste de T1 à T2.
C'est à cette époque que nous avons accumulé suffisamment de raisons pour diviser notre 1ère voie en TIER1 et TIER2 (plus à ce sujet dans une autre série d'articles). Et comme, dans le concept initial, T2 devrait fonctionner avec les deux plates-formes, nous avons transformé tous les incidents MP SIEM dans la 2ème voie, formée des 1ers combattants les plus expérimentés qui ont été immergés dans le nouveau SIEM. Pour l'avenir, je dirai que les ingénieurs de la 2ème ligne ont perçu le MP SIEM plus positivement que leurs collègues analystes seniors - cela nous a donné l'espoir que la plate-forme pourrait être entièrement débarquée sur la 1ère ligne, et ne pas clôturer plusieurs spécialistes.
La question de l'intégration dans un seul écosystème n'a pas non plus été aussi douloureuse que prévu - peut-être a-t-elle été aidée par le fait que la flexibilité et la redondance de configuration ont été initialement incluses dans les mécanismes d'intégration développés. Il n'y a pas eu de victoires particulièrement importantes dont je voudrais me vanter. Nous avons rapidement intégré le nouveau système dans l'écosystème et les processus d'enquête, et maintenant le traitement des incidents de divers SIEM ne diffère pour les gars que par l'interface du SIEM lui-même. Tous les mécanismes de routage et de hiérarchisation, tous des informations enrichissantes pour la prise de décision, tous les modèles de notification sont identiques et se trouvent aux mêmes endroits familiers.
Et le contenu?
Vous n'irez pas loin avec un SIEM «vide» sans contenu (règles de corrélation des événements de sécurité de l'information et d'identification des incidents) et vous ne pourrez pas identifier de nombreuses menaces (nous n'utilisons pas de contenu encadré), donc la tâche de développer rapidement des règles de corrélation sur une nouvelle plate-forme pour les scénarios JSOC déjà existants s'est imposée. Au début, nous avons décidé de nous en sortir avec un peu de sang et de transférer les règles d'ArcSight en copiant la logique d'implémentation, mais cela s'est avéré être une erreur sur laquelle nous nous sommes gravement brûlés: une architecture de produit complètement différente nécessitait «sa propre» approche de développement. J'ai dû former cette approche, et à un rythme accéléré. Une interaction étroite avec le fournisseur a beaucoup aidé, qui nous a conseillé sur les problèmes émergents, a pris en compte la mise en œuvre de nos demandes pour affiner les puces existantes et créer de nouvelles puces dans la fonctionnalité.Le revers de la médaille est que nous devions régulièrement réécrire le contenu pour qu'il fonctionne correctement sur cette toute nouvelle fonctionnalité. Mais, comme on dit, changer ou mourir, donc nous ne nous sommes pas plaints (enfin, sauf peut-être à l'intérieur de l'équipe autour d'un verre de thé).
Au stade initial, seuls les analystes expérimentés de 4ème ligne, qui ont mangé le chien tout en travaillant avec ArcSight, étaient engagés dans le développement du contenu pour le nouveau SIEM. Curieusement, certains gars avaient déjà subi une déformation professionnelle à ce moment-là et avaient formé une "dépendance" à un SIEM spécifique avec son haut niveau de maturité. Le passage à une nouvelle plateforme était difficile pour eux à la fois psychologiquement et techniquement. Plus tard, l'équipe de développement a été considérablement élargie avec de nouveaux membres, incl. les gars de la 3e ligne, et rien que pour eux, ce sujet a décollé beaucoup plus facilement et souvent même plus productif.
Malgré la liste transversale de scénarios pour les deux SIEM, leur mise en œuvre peut sérieusement différer, principalement en raison des limites de l'architecture et des fonctionnalités des différentes plates-formes. Par exemple, dans ArcSight, dans la règle de corrélation, vous ne pouvez pas spécifier une vérification de l'existence d'un enregistrement dans la feuille active par correspondance non stricte, mais dans MP SIEM, vous le pouvez. D'autre part, MP SIEM ne génère pas d'événements internes pour ajouter ou supprimer un enregistrement de la liste de table, et ArcSight peut le faire, et dans un certain nombre de scénarios, cette fonction est utilisée. J'ai dû
Dans le même temps, il était très important de transmettre à la 1ère ligne que la logique d'enquête sur les incidents ne dépend pas du SIEM sur lequel ils sont générés, et que le nouveau SIEM est un nouvel outil pour résoudre toutes les mêmes tâches. Il a ses propres caractéristiques qu'il faut étudier, mais rien ne change radicalement.
Et le travail sur la 1ère ligne a commencé à bouillir
L'immersion de TIER1 dans le travail avec MP SIEM s'est déroulée progressivement et selon le processus, déboguée avec l'introduction de nouveaux employés. Les critères d'incidents ont été déterminés, qui ne sont pas très effrayants à donner à l'analyse de la 1ère ligne, qui n'a pas encore beaucoup d'expérience avec MP SIEM:
- peu de détails critiques sur les incidents (hôtes / réseaux et comptes non classés);
- longs délais de SLA;
- faible intensité de main-d'œuvre de l'incident (nous avons accumulé des statistiques lors du traitement des incidents au TIER2);
- règles de corrélation pas très furieuses (oui, vous devez y chercher la première ligne).
Les scénarios conformes à ces critères ont été divisés en plusieurs étapes et ont été remis un à un aux ingénieurs TIER1 - après avoir passé les «crédits» et avoir eu accès à la solution du pool d'incidents.
En conséquence, nous avons dans notre portefeuille d'outils deux SIEM, sur lesquels sont lancés des scénarios absolument identiques par essence et logique de traitement.
Alexey Krivonogov, directeur adjoint de Solar JSOC pour le développement du réseau régional