Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

Bonjour, dans les articles précédents, nous nous sommes familiarisés avec le travail d'ELK Stack. Discutons maintenant des possibilités qui peuvent être réalisées par un spécialiste de la sécurité de l'information en utilisant ces systèmes. Quels journaux peuvent et doivent être saisis dans elasticsearch. Examinons quelles statistiques peuvent être obtenues en configurant des tableaux de bord et si cela présente un profit. Comment pouvez-vous mettre en œuvre l'automatisation des processus de sécurité de l'information à l'aide de la pile ELK. Dessinons l'architecture du système. Au total, la mise en œuvre de toutes les fonctionnalités est une tâche très vaste et difficile, c'est pourquoi la solution a reçu un nom distinct - TS Total Sight.

Actuellement, les solutions qui consolident et analysent les incidents de sécurité de l'information en un seul endroit logique gagnent rapidement en popularité. En conséquence, le spécialiste reçoit des statistiques et une frontière d'action pour améliorer l'état de la sécurité de l'information dans l'organisation. Nous nous sommes fixé cette tâche en utilisant la pile ELK, et par conséquent nous avons divisé la fonctionnalité principale en 4 sections :

  1. Statistiques et visualisation ;
  2. Détection des incidents de sécurité de l'information ;
  3. Priorisation des incidents ;
  4. Automatisation des processus de sécurité de l'information.

Ensuite, nous examinerons chacun de plus près individuellement.

Détection des incidents de sécurité de l’information

La tâche principale de l'utilisation d'elasticsearch dans notre cas est de collecter uniquement les incidents de sécurité des informations. Vous pouvez collecter les incidents de sécurité des informations à partir de n'importe quel moyen de sécurité s'ils prennent en charge au moins certains modes d'envoi de journaux, la norme est l'enregistrement syslog ou scp dans un fichier.

Vous pouvez donner des exemples standard d'outils de sécurité et plus encore, à partir desquels vous devez configurer le transfert des journaux :

  1. Tous les outils NGFW (Check Point, Fortinet) ;
  2. Tous les scanners de vulnérabilités (PT Scanner, OpenVas) ;
  3. Pare-feu d'applications Web (PT AF);
  4. analyseurs de flux net (Flowmon, Cisco StealthWatch) ;
  5. Serveur AD.

Une fois que vous avez configuré l'envoi des logs et des fichiers de configuration dans Logstash, vous pouvez corréler et comparer avec les incidents provenant de différents outils de sécurité. Pour ce faire, il est pratique d'utiliser des index dans lesquels nous stockerons tous les incidents liés à un appareil spécifique. En d’autres termes, un index regroupe tous les incidents sur un seul appareil. Cette répartition peut être mise en œuvre de 2 manières.

La première option Il s'agit de configurer la configuration Logstash. Pour ce faire, vous devez dupliquer le journal de certains champs dans une unité distincte avec un type différent. Et puis utilisez ce type à l’avenir. Dans l'exemple, les journaux sont clonés à partir de la lame IPS du pare-feu Check Point.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

Afin de sauvegarder ces événements dans un index distinct en fonction des champs du journal, par exemple, tels que les signatures d'attaque IP de destination. Vous pouvez utiliser une construction similaire :

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",<IP_address_elasticsearch>:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

Et de cette façon, vous pouvez enregistrer tous les incidents dans un index, par exemple par adresse IP ou par nom de domaine de la machine. Dans ce cas, nous l'enregistrons dans l'index "smartdefense-%{dst}", par adresse IP de la destination de la signature.

Cependant, différents produits auront des champs de journal différents, ce qui entraînera un chaos et une consommation inutile de mémoire. Et ici, vous devrez soit remplacer soigneusement les champs des paramètres de configuration de Logstash par des champs prédéfinis, qui seront les mêmes pour tous les types d'incidents, ce qui est également une tâche difficile.

Deuxième option de mise en œuvre - il s'agit d'écrire un script ou un processus qui accédera à la base de données élastique en temps réel, extraira les incidents nécessaires et les enregistrera dans un nouvel index, c'est une tâche difficile, mais cela vous permet de travailler avec les journaux à votre guise, et sont directement en corrélation avec les incidents provenant d'autres équipements de sécurité. Cette option vous permet de configurer le travail avec les journaux pour qu'il soit le plus utile pour votre cas avec une flexibilité maximale, mais ici le problème se pose de trouver un spécialiste capable de le mettre en œuvre.

Et bien sûr, la question la plus importante, et qu'est-ce qui peut être corrélé et détecté ??

Il peut y avoir plusieurs options ici, et cela dépend des outils de sécurité utilisés dans votre infrastructure, quelques exemples :

  1. L’option la plus évidente et, de mon point de vue, la plus intéressante pour ceux qui disposent d’une solution NGFW et d’un scanner de vulnérabilités. Il s'agit d'une comparaison des journaux IPS et des résultats de l'analyse des vulnérabilités. Si une attaque a été détectée (non bloquée) par le système IPS et que cette vulnérabilité n'est pas fermée sur la machine finale sur la base des résultats de l'analyse, il est nécessaire de dénoncer, car il existe une forte probabilité que la vulnérabilité ait été exploitée. .
  2. De nombreuses tentatives de connexion depuis une machine vers différents endroits peuvent symboliser une activité malveillante.
  3. Utilisateur téléchargeant des fichiers de virus en raison de la visite d'un grand nombre de sites potentiellement dangereux.

Statistiques et visualisation

La chose la plus évidente et la plus compréhensible pour laquelle ELK Stack est nécessaire est le stockage et la visualisation des journaux, dans les articles précédents il a été montré comment créer des journaux à partir de divers appareils à l'aide de Logstash. Une fois les journaux transférés dans Elasticsearch, vous pouvez configurer des tableaux de bord, qui ont également été mentionnés dans les articles précédents, avec les informations et les statistiques dont vous avez besoin grâce à la visualisation.

Exemples:

  1. Tableau de bord des événements de prévention des menaces avec les événements les plus critiques. Ici, vous pouvez indiquer quelles signatures IPS ont été détectées et d'où elles proviennent géographiquement.

    Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

  2. Tableau de bord sur l'utilisation des applications les plus critiques pour lesquelles des informations peuvent être divulguées.

    Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

  3. Analysez les résultats de n’importe quel scanner de sécurité.

    Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

  4. Journaux Active Directory par utilisateur.

    Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

  5. Tableau de bord de connexion VPN.

Dans ce cas, si vous configurez les tableaux de bord pour qu'ils se mettent à jour toutes les quelques secondes, vous pouvez obtenir un système assez pratique pour surveiller les événements en temps réel, qui peut ensuite être utilisé pour répondre le plus rapidement aux incidents de sécurité de l'information si vous placez les tableaux de bord sur un emplacement séparé. écran.

Hiérarchisation des incidents

Dans des conditions de grandes infrastructures, le nombre d'incidents peut devenir excessif et les spécialistes n'auront pas le temps de traiter tous les incidents à temps. Dans ce cas, il faut tout d’abord souligner uniquement les incidents qui constituent une grande menace. Le système doit donc prioriser les incidents en fonction de leur gravité par rapport à votre infrastructure. Il est conseillé de mettre en place une alerte email ou télégramme pour ces événements. La priorisation peut être mise en œuvre à l'aide des outils Kibana standard en configurant la visualisation. Mais avec les notifications, c'est plus difficile : par défaut, cette fonctionnalité n'est pas incluse dans la version de base d'Elasticsearch, uniquement dans la version payante. Par conséquent, soit achetez une version payante, soit, encore une fois, rédigez vous-même un processus qui informera les spécialistes en temps réel par e-mail ou par télégramme.

Automatisation des processus de sécurité de l'information

Et l’un des éléments les plus intéressants est l’automatisation des actions en cas d’incidents de sécurité de l’information. Auparavant, nous avons implémenté cette fonctionnalité pour Splunk, vous pouvez en lire un peu plus ici article. L'idée principale est que la politique IPS n'est jamais testée ou optimisée, même si dans certains cas, elle constitue un élément essentiel des processus de sécurité de l'information. Par exemple, un an après la mise en œuvre de NGFW et l'absence d'actions d'optimisation d'IPS, vous accumulerez un grand nombre de signatures avec l'action Détecter, qui ne seront pas bloquées, ce qui réduit considérablement l'état de sécurité des informations dans l'organisation. Vous trouverez ci-dessous quelques exemples de ce qui peut être automatisé :

  1. Transfert de la signature IPS de Détecter à Prévenir. Si Prevent ne fonctionne pas pour les signatures critiques, cela signifie un dysfonctionnement et une grave lacune dans le système de protection. Nous modifions l'action dans la politique en de telles signatures. Cette fonctionnalité peut être implémentée si le périphérique NGFW dispose de la fonctionnalité API REST. Cela n'est possible que si vous avez des compétences en programmation ; vous devez extraire les informations nécessaires d'Elastcisearch et envoyer des requêtes API au serveur de gestion NGFW.
  2. Si plusieurs signatures ont été détectées ou bloquées dans le trafic réseau à partir d'une adresse IP, il est alors logique de bloquer cette adresse IP pendant un certain temps dans la politique du pare-feu. L'implémentation consiste également à utiliser l'API REST.
  3. Exécutez une analyse de l'hôte avec un scanner de vulnérabilités, si cet hôte possède un grand nombre de signatures IPS ou d'autres outils de sécurité ; s'il s'agit d'OpenVas, vous pouvez alors écrire un script qui se connectera via ssh au scanner de sécurité et exécutera l'analyse.

Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

Vue totale TS

Au total, la mise en œuvre de toutes les fonctionnalités est une tâche très vaste et difficile. Sans avoir de compétences en programmation, vous pouvez configurer les fonctionnalités minimales, qui peuvent être suffisantes pour une utilisation en production. Mais si vous êtes intéressé par toutes les fonctionnalités, vous pouvez faire attention à TS Total Sight. Vous pouvez trouver plus de détails sur notre En ligne. En conséquence, l’ensemble du schéma opérationnel et de l’architecture ressemblera à ceci :

Vue totale TS. Outil de collecte d'événements, d'analyse d'incidents et d'automatisation de la réponse aux menaces

Conclusion

Nous avons examiné ce qui peut être implémenté à l'aide de la pile ELK. Dans les articles suivants, nous examinerons séparément les fonctionnalités de TS Total Sight plus en détail !

Alors restez à l'écouteTelegram, Facebook, VK, Blog de la solution TS), Yandex.Den.

Source: habr.com

Ajouter un commentaire