Get best of the week

Sécurité de l'information Plateforme automatisée de réponse aux incidents

Imaginez un centre de situation typique pour la sécurité de l'information dans une grande entreprise. Dans un monde idéal, le logiciel détecte une activité suspecte et l'équipe de "pirates blancs" commence à taper du poing sur le clavier. Et cela arrive une fois par mois.

Dans le monde réel, ce sont des centaines de faux positifs et du personnel de soutien fatigué. Ils sont obligés de faire face à chaque incident lorsque l'utilisateur a oublié le mot de passe, ne peut pas télécharger le jeu depuis un torrent, un autre film porno au format * .exe, surveiller les pannes de réseau et généralement enquêter sur de nombreuses situations.

Les systèmes SIEM aident à organiser et à corréler les événements à partir des sources. Et ils génèrent des points positifs, dont chacun doit être traité. De ces "tout le monde", la majorité est fausse. Vous pouvez aborder le problème d'autre part, en ayant des scripts pour le traitement des alarmes. Chaque fois que quelque chose fonctionne, ce serait bien d'avoir non seulement la cause de l'alarme, puis de monter dans quatre à cinq systèmes pour des données différentes, et de collecter immédiatement et automatiquement l'ensemble du diagnostic.



Nous avons créé un tel module complémentaire, et cela a beaucoup aidé à réduire la charge des opérateurs. Parce que les scripts de collecte d'informations sont immédiatement lancés et s'il y a des actions typiques, elles sont immédiatement prises. Autrement dit, si vous démarrez le système «dans une telle situation, nous faisons ceci et cela», alors la carte s'ouvrira pour l'opérateur avec la situation déjà réglée.

Quel est le problème avec les systèmes SIEM?


La liste des décalages est fortement surchargée de données brutes. Une carte d'incident spécifique à remplir est transférée sur notre plateforme.

Les cas typiques ont des organigrammes de réaction d'échantillon.

Voici, par exemple, des rapports d'analyse de données sur les erreurs d'authentification des utilisateurs:



Il y a des critères pour les faux positifs: par exemple, je l'ai essayé deux fois - je suis entré à partir du troisième. L'utilisateur reçoit juste une lettre disant que le mot de passe doit être tapé avec soin, le ticket se ferme. S'il a essayé cinq ou six fois, alors des informations détaillées commencent déjà à se rassembler: ce qui s'est passé ensuite, ce qui s'est passé avant, etc. S'il s'est connecté la 10e fois, puis s'est rendu à la base de connaissances et a commencé à télécharger 10 fichiers, il peut y avoir un paramètre pour "bloquer l'accès à la base de connaissances jusqu'à la fin de la procédure et informer l'opérateur". Très probablement, si l'utilisateur n'est pas malveillant, dans ce cas, le service informatique recevra automatiquement un e-mail avec les détails. Peut-être qu'ils apprendront à l'utilisateur à saisir correctement le mot de passe ou aideront à le changer.

Si l'activité est plus dangereuse, le niveau "a ouvert le fichier exécutable dans le courrier, puis quelque chose a commencé à se glisser sur le Web", puis un segment entier ou un sous-réseau peut être automatiquement bloqué. Oui, SIEM peut le faire par lui-même, mais sans réglage fin, peut-être, de telles mesures sont la limite de l'automatisation.

Encore une fois, dans un monde idéal, l'opérateur a accès à tous les systèmes et sait immédiatement quoi faire. Dans le monde réel, il a souvent besoin de trouver quelqu'un responsable pour clarifier quelque chose. Et il est aussi en vacances ou en réunion. Par conséquent, une autre partie importante - dans l'organigramme de la réaction devrait immédiatement être responsable de sections spécifiques des systèmes et des départements. Autrement dit, vous n'avez pas besoin de chercher le téléphone portable de l'employé, le nom de son patron et son téléphone, mais de les voir immédiatement sur une carte ouverte.

Qu'avons-nous fait


  1. , (), - .
  2. , ( ), , .
  3. , -. : , , .
  4. , .
  5. .
  6. ( , , ).
  7. .
  8. GUI -.

L'un de nos principaux clients est SIEM QRadar. Un bon système de détection des menaces, il y a des actions et des étapes pour chaque incident, mais vous ne pouvez pas donner une liste de travail pour un opérateur humain. Quand il s'agit d'une superclasse professionnelle, ce n'est pas nécessaire. En ce qui concerne l'opérateur de la première ligne, il est très important de lui donner des instructions sur quoi et comment faire, et il pourra couvrir la plupart des incidents typiques au niveau d'un spécialiste sympa.

Autrement dit, nous avons supprimé tous les événements manifestement ennuyeux sur la première ligne et ajouté des critères aux scripts qui séparent ennuyeux de ceux ennuyeux. Tout atypique, comme précédemment, incombe aux pros.

Des cas pour des entreprises de plusieurs dizaines de milliers de postes de travail et avec leurs capacités de serveur dans plusieurs centres de données ont été élaborés et prescrits en conséquence pendant environ un an (il existe des relations difficiles entre les départements, ce qui a rendu difficile l'intégration dans différents systèmes). Mais maintenant, chaque sous-tâche de la carte a un responsable spécifique, et c'est toujours pertinent.

La simplicité pour les opérateurs peut être jugée par le fait que lors de la mise en œuvre, le système a d'abord été déployé dans les régions, puis, après quelques semaines, la documentation officielle a commencé à être envoyée. Pendant ce temps, les gens ont déjà commencé à clôturer les incidents en toute confiance.

Comment cela a-t-il commencé?


Il y a SIEM, mais ce qui se passe constamment n'est pas clair. Plus précisément, QRadar génère de nombreux événements, ils relèvent du département de la sécurité de l'information, et il n'y a tout simplement pas de mains pour tout démonter correctement et en détail. Par conséquent, les rapports sont simplement consultés de manière superficielle. L'avantage du SIEM avec cette approche n'est pas très élevé.

Il existe un système de gestion des actifs.

Il existe des serveurs pour scanner le réseau, très bien configurés.

Le rapport allait être excellent, mais ils le regardèrent avec lassitude et repoussèrent.

Le client voulait que ce qu'il achète commence à produire des résultats.

Nous avons placé le centre de service pour les agents de sécurité au sommet (en fait un système de ticket, comme dans le support normal), visualisé l'analyse des données et écrit la plate-forme d'automatisation décrite sur la base d'IBM Resilient + ajouté des réactions typiques. Resilient vient nu, c'est juste un cadre. Nous avons pris comme base les règles de corrélation de QRadar et finalisé les plans de réponse pour les cas d'utilisateurs.



Pendant plusieurs mois, ils ont fait la russification de tout et ont raccroché les bons paquets par API. Dès que nous avons fini, le vendeur a publié la russification, et nous étions un peu tristes.

Environ un mois, ils se sont entraînés et se sont familiarisés avec la documentation (en particulier, comment dessiner de nouveaux organigrammes pour les cartes). Plus ils apprenaient, plus les cas devenaient simples: au début, d'énormes scripts d'actions étaient écrits, puis il s'est avéré qu'ils devenaient une sorte de bibliothèque de cas typiques. Et on pourrait s'y référer dans presque toutes les réactions.

Comparaison des réactions


Incident "Infection virale répétée avec le même malware en peu de temps." Autrement dit, le virus est détecté sur les postes de travail, mais le personnel est nécessaire pour comprendre d'où il provient. La source d'infection est active.

Classique:

  1. Il y a eu une infection virale répétée de l'hôte 192.168.10.5 avec le même malware pendant une courte période, des événements ont été envoyés à SIEM et la règle correspondante a fonctionné.
  2. .
  3. .
  4. .
  5. .
  6. /CMDB-.
  7. .
  8. - , .
  9. / .
  10. Service Desk .
  11. Remplit une application dans le système Service Desk sur la base des résultats d'une enquête pour éliminer la vulnérabilité à cause de laquelle cet hôte a été infecté.
  12. Il attend la fermeture des applications du Service Desk, puis vérifie leur exécution.
  13. Remplit une carte d'incident et ferme l'incident.
  14. Il rend compte à la direction des résultats de ses travaux.
  15. L'analyste recueille des statistiques sur les incidents pour analyser l'efficacité du processus de réponse.

Sur notre plateforme:

  1. Il y a eu une infection virale répétée de l'hôte 192.168.10.5 avec le même malware en peu de temps, les événements ont été envoyés à SIEM et la règle correspondante a fonctionné.
  2. L'opérateur examine la carte d'incident, dans laquelle les informations sur cet hôte, l'état de l'outil de protection antivirus et ses journaux, les vulnérabilités sur l'hôte, les incidents connexes et les personnes responsables de cet hôte ont déjà été téléchargées.
  3. , : , , Service Desk , - .
  4. Service Desk , .
  5. .
  6. .




C'est devenu un peu plus rapide. Mais l'essentiel n'est pas ceci, mais qu'il est possible de trier les tâches en «l'opérateur de première ligne va gérer» et «besoins spéciaux». C'est-à-dire qu'en moyenne, la solution pour chaque billet est devenue beaucoup moins chère et le système est plus évolutif.



En plus de nombreux faux positifs, il y avait de nombreux doublons qui se sont révélés commodes à détecter par le système.



Les cartes ne ressemblent pas à un ensemble de données obscures d'un rapport, mais comme «Vasya a fait ceci et cela sur un hôte. C'est mauvais. L'hôte est responsable de Petya. C'est exactement ce qui s'est passé. Nous devons aller à Petya et dire que l’ordinateur de Vasya de la zone de travail ne peut pas être utilisé pour montrer des présentations lors de conférences. »

Une autre chose importante dans tout cela est que, sur la base de la collecte de données primaires, il est devenu possible de hiérarchiser les tickets. Autrement dit, les principales menaces potentielles apparaissent et nécessitent une attention immédiate, et non dans une file d'attente en direct.

L'automatisation à l'interface avec les tickets informatiques a permis non seulement de collecter toutes les informations sur l'incident, mais aussi de mettre immédiatement des tickets au service informatique. Si vous devez modifier certains paramètres sur le routeur, un ticket provenant du service informatique est alors automatiquement généré, par exemple. Étonnamment, des cas ont commencé à émerger "oublié de changer de compte dans le service, et il essaie de se connecter pendant un mois". Le service informatique ne voit pas de telles situations ni n'ignore l'infrastructure. Et ici, le SI dit - le service ne peut pas se connecter. Et ils ont mis un ticket.

Grâce au typage des fiches de réaction, les incidents ont commencé à être résolus par des méthodes standard. Auparavant, chacune était décidée de manière créative: différentes personnes effectuaient différentes actions.

Le résultat est un bon flux de travail comme dans le CRM moderne. L'incident passe à travers un entonnoir. Un autre problème a été résolu à la dernière étape: des personnes plus tôt fermaient parfois le ticket simplement parce qu'il était fatigué. Autrement dit, le résultat a été mal prescrit. Et maintenant, vous devez prouver au système qu'il s'agit d'un faux positif. Autrement dit, vous pouvez le fermer, comme auparavant, mais il est clair que, qui et dans quelles conditions l'a fait, et il est beaucoup plus facile d'ouvrir les montants. Non seulement «l'utilisateur n'a pas pu exécuter le fichier», mais «a amené le jeu sur la clé USB, a voulu l'installer - ils ont expliqué les règles de la vie une fois de plus». Et c'est déjà clair ce qui s'est passé.

Polyvalence


Maintenant, il y a quelques intégrations dans la production (l'une est très grande avec QRadar et un système de gestion des actifs, une autre est plus petite). Il est possible de se connecter à n'importe quel SIEM à l'aide d'API standard, mais, bien sûr, l'intégration nécessite du temps pour les connecteurs, le raffinement des fichiers et la rédaction des règles de réaction pour les utilisateurs. Néanmoins, cela aide beaucoup à vraiment répondre aux incidents de sécurité et à le faire relativement rapidement et à peu de frais. Il est probable que dans 10 ans, les systèmes SIEM eux-mêmes seront en mesure de le faire, mais jusqu'à présent, notre module complémentaire s'est bien montré.

Si vous voulez le ressentir avec nous ou discuter de son apparence avec vous, voici mon mail AAMatveev@technoserv.com.

More articles:


All Articles