Réduire le Temps de Détection des Violations : Disponibilité des Données de Journalisation

Bonjour encore ! Dans l’article précédent, nous avons déjà établi que de nombreuses choses peuvent échapper à notre contrôle lorsque l’on se lance dans la construction d’un SOC virtuel ou à grande échelle, surtout lorsqu’il s’agit d’opérationnaliser le SIEM comme technologie centrale de tout SOC. Nous avons également établi que l’automatisation est la voie à suivre si l’on veut suivre le rythme des menaces modernes et de la surcharge générée par les technologies SIEM et SOC. Aujourd’hui, nous commençons à analyser chaque composant de déploiement et d’opérations SIEM pièce par pièce, le premier qui vient à l’esprit est la disponibilité des données. De nombreux facteurs impactent le temps de détection des violations et, depuis 2015, il est toujours supérieur à 200 jours en moyenne, mais ce n’est pas parce que le SIEM est une technologie de choix pour la détection des violations. Un SIEM ne peut vous fournir que le résultat basé sur les entrées qu’il reçoit, et si nous manquons quelque chose à l’entrée, nous ne devrions pas nous attendre à ce que le résultat soit complet, exploitable et parfois nous n’aurons pas de résultat du tout.Est-ce vraiment la faute du SIEM s’il manque des journaux (et des incidents) ? Eh bien, cela dépend à nouveau de nombreux facteurs et pour clarifier ce désordre et maintenir le SIEM continuellement opérationnel, une personne responsable de son administration/maintenance (votre entreprise en a un, n’est-ce pas ?) doit avoir suffisamment d’informations à tout moment pour répondre à ces deux questions : « Toutes les données de journaux pertinentes sont-elles collectées ? » et si la réponse est NON « Le problème vient-il du SIEM ou de l’extérieur ? ». Si la réponse à la première question est NON, soyez assuré que vous passez à côté de choses importantes qui ont un impact direct sur votre temps de détection des incidents et sur la précision. Et la vérité est qu’aucune solution SIEM ne répond simplement à cela prêt à l’emploi – c’est toujours un effort manuel pour répondre à cette question.Avez-vous déjà vu un SIEM qui dit « La disponibilité de vos données de journaux réseau est de 85 % » ? Moi non plus. Cependant, nous avons encore une deuxième question qui évidemment n’est pas non plus répondue par le système puisqu’il ne peut pas répondre à la première. Mais, tout n’est pas perdu et des réponses existent si on fait suffisamment de recherches ou si on consacre suffisamment de temps et d’efforts pour les chercher manuellement.Considérons quelques exemples basés sur la façon dont on collecte les données de journaux et commençons par le mécanisme de collecte de journaux le plus courant – syslog. Il est peu probable que l’on puisse nommer une implémentation SIEM qui n’utilise pas du tout syslog. Il existe de nombreuses façons dont les données peuvent se perdre avec syslog: un démon sur méthode de collecte de tuyau perd des données lorsque le composant collecteur est arrêté; le protocole syslog UDP (par défaut) n’a aucune garantie de livraison de paquets, un volume élevé de trafic syslog (à la fois UDP et TCP) peut être entravé par les limites de taille de tampon et les limites de largeur de bande et même les caractéristiques de traitement du taux de paquets d’une carte NIC concrète. Même dans le cas de la lecture des données de journaux depuis un fichier, on doit considérer la rotation des fichiers et l’intégrité. Le diagnostic de ces problèmes est toujours une tâche routinière manuelle qui implique de lire les journaux de diagnostic des composants SIEM eux-mêmes. S’il possède des données de diagnostic pour commencer ! Même les données de diagnostic les plus laides sont meilleures qu’aucune donnée de diagnostic du tout et une excuse bon marché du type « oh, notre SIEM est si magique qu’il n’a pas d’erreurs ! ». Ensuite, nous serions occupés à construire (ou réutiliser ?) du contenu de corrélation qui établit une référence des volumes de flux de journaux et des écarts (Quelqu’un est-il vraiment satisfait des résultats d’un tel contenu ? Qu’en est-il des ressources qu’il consomme ?), à faire tourner TCPdump pour vérifier les taux de perte de paquets, à surveiller la disponibilité des composants par des sources externes… Attendez, je pense que nous avons conçu au moins 3 outils supplémentaires qui doivent être ajoutés à SIEM pour se surveiller lui-même, juste pour répondre à une simple question « Quel est le % de disponibilité de mes données de journaux réseau ? ». Si nous parlons de tentatives concrètes pour rendre cela automatique, disons, Splunk sur Splunk, sont-elles vraiment efficaces ? Combien de $$ supplémentaires du coût de licence faut-il ajouter pour pouvoir auto-diagnostiquer la plateforme SIEM/Gestion des Journaux et quelle surcharge de performance cette appli la plus populaire produit-elle ?..

Okay, mettons de côté syslog et Splunk quelques minutes et pensons à la deuxième source de journaux la plus populaire – Microsoft Windows Event Log. Pour résumer les problèmes : rotation des journaux, largeur de bande du réseau, erreurs d’authentification / blocages de mots de passe, instabilité WMI et JCIFS, charge élevée des serveurs Windows actifs (audit des fichiers, Active Directory, etc.). La surveillance de cela nécessiterait à nouveau tout un ensemble d’outils et ces outils seront différents par rapport aux outils de surveillance syslog ! Nous pourrions continuer avec une longue liste incluant les bases de données, les pare-feu/ngfw/ips/ngips/utm (bonjour OPSEC & SDEE) et découvrir encore plus de choses qui se passent en dehors du SIEM, que le SIEM n’a pas d’effet sur mais doit savoir (!) et il doit fournir cette information de manière rapide et précise à l’administrateur. Pourtant, pour ceux qui lisent jusqu’ici, il y a de bonnes nouvelles, puisque le SIEM (ou la plupart des SIEM) lui-même a des journaux de diagnostic lisibles (presque). Ces fichiers de diagnostic difficiles à trouver, appels API cachés ou traces de pile java multilignes contiennent des bits et des octets d’information qui pourraient fournir des réponses à beaucoup des problèmes soulevés ci-dessus. Et en les combinant ensemble et en appliquant des métriques de profilage significatives nous pouvons répondre à ces deux questions simples qui font toute la différence entre savoir si votre plateforme de détection de sécurité critique pour l’entreprise fonctionne comme prévu ou ignorer le problème / le résoudre à moitié en mobilisant plus de ressources FTE pour le problème. L’automatisation est là pour tous ceux qui veulent s’assurer que leurs données de journaux sont disponibles comme prévu dans le projet, requis par l’organisation/le client et qu’ils obtiennent un retour approprié sur leur investissement SIEM. J’espère que cela vous donne matière à réflexion. Restez à l’écoute !

P.S. Au cas où vous faites partie des experts HPE ArcSight, il y a encore de bonnes nouvelles ! Dans le cadre d’une initiative mondiale pour faire en sorte que les plateformes SIEM délivrent de la valeur et gagnent du temps aux experts SIEM du monde entier, SOC Prime fournit un service gratuit de contrôle instantané de la santé du SIEM en ligne, qui peut absorber les fichiers agent.log et vous fournir les 5 problèmes critiques les plus importants et leurs solutions en moins de 5 minutes. Vous avez un agent.log ? Jetez-le ici et voyez par vous-même !