Reduzierung der Erkennungszeit bei Sicherheitsverletzungen: Verfügbarkeit der Log-Daten

Hallo nochmal! Im vorherigen Artikel, haben wir bereits festgestellt, dass viele Dinge außer Kontrolle geraten können, wenn man ein virtuelles oder ein vollständiges SOC aufbaut, insbesondere wenn es darum geht, das SIEM als Kerntechnologie jedes SOC zu operationalisieren. Wir haben auch festgestellt, dass Automatisierung der Weg ist wenn man mit modernen Bedrohungen und dem durch SIEM- und SOC-Technologien erzeugten Aufwand Schritt halten möchte. Heute beginnen wir mit der Analyse jedes SIEM-Bereitstellungs- und Betriebskomponenten Stück für Stück, das erste, das einem in den Sinn kommt, ist die Datenverfügbarkeit. Es gibt viele Faktoren, die die Erkennungszeit von Sicherheitsverletzungen beeinflussen und ab 2015 liegt sie immer noch im Durchschnitt über 200 Tagen, aber das liegt nicht daran, dass SIEM die Technologie der Wahl für die Erkennung von Sicherheitsverletzungen ist. Ein SIEM kann Ihnen nur die Ausgabe basierend auf den Eingaben geben, die es erhält, und wenn wir etwas bei den Eingaben verpassen, sollten wir nicht erwarten, dass die Ausgabe vollständig, umsetzbar ist, und manchmal werden wir überhaupt keine Ausgabe haben.Ist es wirklich die Schuld des SIEM, dass es Protokolle (und Vorfälle) verpasst? Nun, das hängt wieder von vielen Faktoren ab, und um diesen Schlamassel zu beseitigen und das SIEM kontinuierlich funktionsfähig zu halten, muss die Person, die für seine Administration/Wartung verantwortlich ist (hat Ihr Unternehmen eine, oder?), zu jedem Zeitpunkt über genügend Informationen verfügen, um diese zwei Fragen zu beantworten: „Wird das gesamte logdaten im Rahmen gesammelt?“ und wenn die Antwort NEIN ist „Liegt das Problem auf der Seite des SIEM oder außerhalb davon?“. Wenn die Antwort auf die erste Frage ein NEIN ist, seien Sie versichert, dass Sie wichtige Dinge verpassen, die direkten Einfluss auf Ihre Vorfallserkennungszeit und -genauigkeit haben. Und die Wahrheit ist, keine SIEM-Lösung beantwortet dies einfach aus der Box – es ist immer eine manuelle Anstrengung, diese Frage zu beantworten.Haben Sie jemals ein SIEM gesehen, das sagt „Die Verfügbarkeit Ihrer Netzwerkprotokolldaten beträgt 85%“? Ich nicht. Dennoch haben wir immer noch eine zweite Frage, die offensichtlich auch nicht vom System beantwortet wird, da es die erste nicht beantworten kann. Aber alles ist nicht verloren, und es gibt Antworten, wenn jemand genug Recherche betrieben oder genug Zeit und Mühe darauf verwendet hat, sie manuell zu suchen.Lassen Sie uns einige Beispiele betrachten basierend darauf, wie man Protokolldaten sammelt, und beginnen wir mit dem am häufigsten verwendeten Mechanismus zur Protokollsammelsystem – syslog. Es ist unwahrscheinlich, dass man eine SIEM-Implementierung nennen kann, die kein Syslog überhaupt verwendet. Es gibt viele Möglichkeiten, wie Daten mit Syslog verloren gehen können: ein Daemon im Pipe-Sammelsystem verliert Daten, wenn die Sammelkomponente gestoppt wird; ein UDP (Standard) Syslog-Protokoll garantiert keine Paketzustellung, ein hohes Volumen von Syslog-Verkehr (sowohl UDP als auch TCP) kann durch Puffergrößenbeschränkungen und Bandbreitenbeschränkungen beeinträchtigt werden und sogar durch Spezifikationen der Paketverarbeitungsrate einer bestimmten Netzwerkkarte. Selbst im Falle des Lesens von Protokolldaten aus einer Datei muss man Dateirotationen und -integrität berücksichtigen. Die Diagnose dieser Probleme ist immer eine manuelle Routinearbeit, die das Lesen von Diagnoseprotokollen der SIEM-Komponenten selbst umfasst. Wenn es denn Diagnosedaten gibt! Selbst die hässlichsten Diagnosedaten sind besser als gar keine Diagnosedaten und eine billige Ausrede wie „oh, unser SIEM ist so magisch, dass es keine Fehler hat!“. Als nächstes wären wir beschäftigt mit dem Erstellen (oder Wiederverwenden?) von Korrelationsinhalten, die Protokollflussmengen und Abweichungen basieren (ist wirklich jemand mit den Ergebnissen eines solchen Inhalts zufrieden? Was ist mit den Ressourcen, die er verbraucht?), TCPdump ausführen, um Paketausfallraten zu überprüfen, die Verfügbarkeit von Komponenten über externe Quellen zu überwachen… Warten Sie, ich denke, wir haben mindestens 3 zusätzliche Werkzeuge gefunden, die dem SIEM hinzugefügt werden müssen, um sich selbst zu überwachen, nur um eine einfache Frage zu beantworten: „Was ist % der Verfügbarkeit meiner Netzwerkprotokolldaten?“. Wenn wir von konkreten Versuchen sprechen, dies automatisch zu machen, zum Beispiel Splunk auf Splunk, sind sie wirklich effizient? Wie viel zusätzliche $$ Lizenzkosten muss man hinzufügen, um die Selbstdiagnose der SIEM-/Protokollverwaltungsplattform zu ermöglichen und wie viel Performance-Overhead erzeugt diese beliebteste App? ..

Okay, lassen Sie uns Syslog und Splunk für ein paar Minuten beiseite legen und über die zweitbeliebteste Protokollquelle nachdenken – Microsoft Windows Event Log. Um die Probleme kurz zu halten: Protokollrotation, Netzwerkbandbreite, Authentifizierungsfehler / Passwortsperren, Instabilität von WMI und JCIFS, hohe Auslastung vielbeschäftigter Windows-Server (Dateiaudit, Active Directory etc.). Die Überwachung dessen würde wiederum einen ganzen Satz von Werkzeugen erfordern, und diese Werkzeuge werden sich im Vergleich zu den Syslog-Überwachungstools unterscheiden! Wir können eine lange Liste fortführen, einschließlich Datenbanken, Firewalls/ngfw/ips/ngips/utm (hallo OPSEC & SDEE) und werden noch mehr Dinge entdecken, die außerhalb des SIEM passieren, auf die SIEM keinen Einfluss hat, aber davon wissen muss (!), und es muss diese Informationen schnell und genau an den Administrator liefern. Doch für diejenigen, die bis hier gelesen haben, gibt es gute Nachrichten, da SIEM (oder die meisten SIEMs) selbst lesbare (fast) Diagnoseprotokolle haben. Diese schwer zu findenden Diagnose-Dateien, versteckten API-Aufrufe oder mehrzeilige Java-Stack-Traces enthalten Bits und Bytes von Informationen, die Antworten auf viele der oben aufgeworfenen Fragen liefern könnten. Und indem wir diese zusammenfügen und sinnvolle Profilmetriken anwenden können wir diese zwei einfachen Fragen beantworten, die einen großen Unterschied bedeuten, ob Ihre geschäftskritische Sicherheitsdetektionsplattform wie beabsichtigt funktioniert oder ob das Problem ignoriert / halb behoben wird, indem man mehr FTE auf das Problem wirft. Automatisierung ist hier für alle, die sicherstellen wollen, dass ihre Protokolldaten wie im Projekt geplant, von der Organisation/Kunden gefordert und sie eine ordnungsgemäße Rendite auf ihre SIEM-Investition erhalten. Ich hoffe, das gibt Ihnen einiges zu bedenken. Bleiben Sie dran!

PS: Falls Sie einer der HPE ArcSight-Experten sind, gibt es noch mehr gute Nachrichten! Als Teil einer globalen Initiative, um SIEM-Plattformen wertvoll zu machen und die Zeit von SIEM-Experten weltweit zu sparen, bietet SOC Prime einen kostenlosen Online-Sofort-SIEM-Gesundheitscheck-Service an, der agent.log-Dateien verarbeiten und Ihnen in weniger als 5 Minuten die 5 kritischsten Probleme und Lösungen zur Verfügung stellen kann. Haben Sie eine agent.log? Stellen Sie sie hier und sehen Sie selbst!