085: Was ist ein SIEM System?

00:00:07: Hallo und willkommen zu einer weiteren Folge von Blue Screen Wissen.

00:00:10: Ich habe sie in der letzten Folge schon angekündigt. Wir werden uns heute mal

00:00:14: damit beschäftigen, wie man denn Protokolle an einem zentralen Ort speichern

00:00:18: kann, wie man die auswerten kann.

00:00:20: Wir reden mal darüber, was bringt denn das überhaupt, sich mit den Protokollen

00:00:24: zu beschäftigen. Und ja, natürlich gebe ich auch Tipps, wie man das dann entsprechend machen kann.

00:00:30: Deswegen Thema unserer heutigen Folge ist SIEM.

00:00:34: SIEM, diese Abkürzung bedeutet Security Incident and Event Monitoring,

00:00:40: also eine Überwachung von allem, was irgendwo sicherheitsrelevant ist,

00:00:44: was an Ereignissen da ist, an Ereignissen, die vielleicht auch einen tieferen Blick wert sind.

00:00:51: Und da sammelt man natürlich auf den einzelnen Geräten jede Menge Protokolle.

00:00:56: Wenn man sich heute mal anschaut, es gibt das Ereignisprotokoll von Windows.

00:01:01: Wir haben auf Firewalls, wie in der letzten Folge gehört, entsprechende Logs.

00:01:05: Wir haben in Virtualisierungslösungen, in Antiviruslösungen,

00:01:10: überall entsprechend Protokolle.

00:01:13: Und das Problem ist, diese Protokolle sind jeweils auf einer eigenen Insel für

00:01:17: sich gespeichert. Das heißt, meine Firewall weiß nur, was die Firewall weiß

00:01:21: und mein Windows weiß nur, was Windows weiß.

00:01:23: Ist für mich als Admin natürlich relativ schwierig, das Ganze irgendwie unter einen Hut zu bekommen.

00:01:28: Vielleicht möchte ich ja auch nachvollziehen, weil ich einen Vorfall hatte im

00:01:33: eigenen Unternehmen, wie konnte das denn überhaupt passieren?

00:01:36: Und das ist eine doch relativ schwierige Situation, wenn ich halt eben nicht

00:01:41: zentral die Möglichkeit habe, diese ganzen Protokolle A zu sehen,

00:01:46: B miteinander in Korrelation zu bringen.

00:01:49: Also zum Beispiel zu verstehen, hier kam eine Mail, mein Anwender hat einen

00:01:54: Anhang geöffnet, dieser Anhang hat Chartcode beinhaltet, vielleicht ein aktives

00:01:58: Element in einem Office-Dokument.

00:02:01: Dann wurde eine Verbindung aus dieser Excel-Datei mit einem Makro aufgebaut,

00:02:06: von innen nach außen in die Zone Internet.

00:02:08: Hier hat ein Download stattgefunden. Diese Software wurde auf dem Endgerät gespeichert, wurde dort gestartet,

00:02:14: hat dann weitere Prozesse gestartet und dann sich entsprechend auf dem PC eingenistet

00:02:20: und hat dann daraufhin folgend weiterhin versucht, sich auf anderen Geräten

00:02:24: in meinem Netzwerk auszubreiten.

00:02:25: Wenn ich kein zentrales Management für sowas habe, kriege ich das tatsächlich

00:02:29: wahrscheinlich gar nicht raus.

00:02:31: Und das ist gerade nach einem Vorfall ein ganz großes Problem.

00:02:34: Ohne Protokolle, ohne Telemetrie kann man wirklich überhaupt gar nicht oder

00:02:39: nur sehr schwer mit sehr viel Aufwand nachvollziehen, wie denn es überhaupt so weit kommen konnte.

00:02:43: Und damit fehlt mir natürlich auch die Möglichkeit, nächste Schritte oder eine

00:02:48: Aufbereitung des Vorfalls zu machen, um zu sagen, was kann ich denn für die

00:02:52: Zukunft besser machen, damit sowas eben einfach nicht mehr passiert.

00:02:55: Und da bietet es sich halt einfach an, ein zentrales Event-Management,

00:03:00: ein zentrales Log-Management dafür aufzubauen.

00:03:03: Wie kann ich sowas tun? Nun, es gibt zum Beispiel auf Linux den Syslog-Server, Syslog-NG.

00:03:10: Den kann man sich einfach in eine Linux-Distribution reininstallieren und dann

00:03:15: sammelt der ab sofort sowohl die Protokolle von dem Linux-Server,

00:03:19: auf dem es installiert ist.

00:03:20: Man kann aber auch sogenanntes Log-Forwarding einrichten von anderen Linux-Maschinen,

00:03:25: sodass die dann eben ihre Protokolle zu meinem zentralisierten Syslog-Server übertragen.

00:03:31: Die Auswertbarkeit davon ist natürlich Linux-artig erstmal, wenn man das nur

00:03:37: out of the box verwendet, relativ naja.

00:03:39: Also damit zu arbeiten macht an der Stelle nicht so wirklich richtig viel Spaß.

00:03:43: Aber es ist eine kostenlose Möglichkeit, wenn man sagt, ich möchte zentrales

00:03:47: Log-Management betreiben.

00:03:48: Eine gute Alternative, die ich tatsächlich auch in der Vergangenheit immer wieder

00:03:53: eingesetzt habe, ist Splunk.

00:03:56: Splunk gehört mittlerweile zu, ich glaube, IBM,

00:04:00: Lenovo, Quatsch, das stimmt gar nicht, Cisco hat die gekauft,

00:04:03: die gehören mittlerweile zu Cisco,

00:04:05: es gibt aber eine kostenfreie Community-Version, zumindest gibt es die Stand

00:04:10: heute immer noch, ich bin mal gespannt, wie lange es die noch geben wird und

00:04:13: mit dieser Community-Version kann ich bis zu 500 Megabyte Protokolldaten an einem Tag verarbeiten.

00:04:19: Heißt also, ich installiere mir den Splunk-Server mit der Community-Lizenz zum

00:04:24: Beispiel auf einem Windows-Server, bekomme dann eine Datenbank dort,

00:04:29: einen Log-Receiver, der eben die Protokolle von anderen Maschinen,

00:04:33: sei es jetzt Linux oder auch zum Beispiel macOS Windows,

00:04:37: einer Firewall, einer Storage-System, was auch immer, entsprechend sammelt.

00:04:41: Und damit bekomme ich dann zusätzlich aber auch einen Webservice.

00:04:45: Über diesen Webservice kann ich mir dann meine Suchen und meine Abfragen entsprechend

00:04:49: zusammenbauen und habe damit dann die Möglichkeit, einfach verschiedene Ereignisse

00:04:54: in einen Bezug zueinander zu setzen.

00:04:57: Ist vielleicht am Anfang nicht ganz einfach, das Ganze zu verstehen,

00:05:01: wie sowas funktioniert, aber wenn man es mal durchverstanden hat,

00:05:05: dann kann man damit schon relativ viel tun.

00:05:06: Ein großer Vorteil, den ich an der Stelle auch immer anbringen kann,

00:05:10: ist, wenn heute ein Angreifer sich in eurem System irgendwie rumtreibt und vielleicht

00:05:16: seine Arbeit erledigt hat, dann wird er versuchen, auch seine Spuren zu verwischen,

00:05:20: damit man ihm eben nicht so schnell auf die Schliche kommen kann.

00:05:23: Heißt, der Angreifer wird auf den System, wo er gewesen ist und auf die er Zugriff

00:05:26: hatte, versuchen, die Protokolle zu löschen.

00:05:28: Habe ich ein zentrales Logmanagement, dann sind die Protokolle ja aber schon ganz woanders.

00:05:33: Das ist ein ganz großer Vorteil, weil ich eben die Protokolle außerhalb von

00:05:39: dem eigentlichen betroffenen System speichere.

00:05:41: Vielleicht gehe ich sogar so weit und betreibe das Logmanagement außerhalb meiner

00:05:45: eigenen Infrastruktur.

00:05:47: Beispielsweise in der Cloud, und dann kann das der Angreifer halt nicht mehr löschen.

00:05:51: Das heißt, ich bekomme eine unlöschbare, permanente Protokollierung von allem, was mich interessiert.

00:05:57: Idealerweise sollte man wirklich alles locken, dann hat man es später auch,

00:06:01: also lieber zu viel als zu wenig, auch wenn das natürlich zu Intransparenz unter

00:06:05: Umständen erstmal führen kann.

00:06:06: Aber diese Locks habe ich dann und damit habe ich auch die Möglichkeit,

00:06:10: einfach zurückzuschauen, was ist denn passiert.

00:06:12: Also das ist auch ein ganz wichtiger Punkt. Ja, und mit Splunk beispielsweise

00:06:17: kann ich meine Windows-Server-Clients, meine gesamte Infrastruktur an der Stelle schon mal bekommen.

00:06:23: Wie gesagt, das Limit ist an der Stelle aber 500 MB am Tag.

00:06:28: Klingt jetzt erstmal wenig. Üblicherweise, dadurch, dass Protokolle ja meistens

00:06:32: einfach nur Text sind, kommt man damit aber schon relativ gut über die Runden.

00:06:36: Wo es schwierig wird, wenn man Virtualisierung zum Beispiel auch noch dort reinloggen

00:06:41: lässt, bei VMware das sogenannte Scratch-Log zum Beispiel, wenn man ein Cluster

00:06:45: aus drei, vier, fünf Servern hat,

00:06:47: die sprechen so viel in ihrem Protokoll, dass die definitiv die 500 MB am Tag knacken werden.

00:06:53: Aber dann kann man sich ja vielleicht noch eine zweite Splunk-Instanz aufsetzen,

00:06:57: wo halt dann eben diese Logs reinlaufen.

00:06:59: Meiner Meinung nach wichtig, ich habe die Logs, ich habe sie so,

00:07:02: dass sie auch keiner löschen kann. Wenn ich sie brauche, kann ich darauf zugreifen

00:07:06: und kann einfach damit mal eine Suche starten.

00:07:08: Ich kann mir zum Beispiel auch vorgefertigte Suchen, wie zum Beispiel nach Begriffen

00:07:13: wie Error oder Failed oder Access Denied zusammenbauen, um einfach mal drüber zu gucken,

00:07:18: was passiert denn eigentlich in meiner Infrastruktur, eben nicht nur auf einem

00:07:22: Gerät, sondern über alle Geräte hinweggesucht und damit kommt man zumindest

00:07:26: schon mal ein ganz gutes Stück weit.

00:07:28: Es gibt natürlich auch Alternativen. Greylock ist eine Alternative,

00:07:32: die Open Source ist. Das Ganze funktioniert dann auch mit Elasticsearch.

00:07:36: Das heißt, damit kann ich mir auch solche Suchen zusammenbauen,

00:07:39: ist aber vielleicht ein bisschen sperriger einfach, das Ganze dann zu bedienen.

00:07:43: Aber es ist auf jeden Fall eine sehr performante und gute Lösung,

00:07:47: mit der man sich auch Automatisierungen schreiben kann.

00:07:51: Tja, das Ganze gibt es aber natürlich auch noch in schön, aber halt dann eben

00:07:56: nicht mehr in kostenlos.

00:07:58: Wenn man sagt, okay, ich möchte jetzt vielleicht auch noch meine Protokolle

00:08:02: aus einer Cloud-Anwendung haben,

00:08:04: zum Beispiel habe ich vielleicht bei Amazon in AWS irgendwelche Services laufen

00:08:08: oder in der GCP, in der Google Cloud oder in der Microsoft Cloud,

00:08:13: da habe ich ja auch Protokolle.

00:08:14: Das heißt, Anmeldungen an diesem Service, Dienstveränderungen,

00:08:18: neu eingerichtete Services, Zugriffe, was auch immer, auch diese Protokolle

00:08:23: möchte ich gerne ja vielleicht haben oder auch von meiner Antivirus-Lösung.

00:08:27: Und da ist es so, dass wir halt aus der Praxis heraus einfach die Empfehlung tätigen können,

00:08:33: wenn ein Unternehmen heute zum Beispiel sehr Microsoft-lastig ist.

00:08:37: Dann würde ich dort auf jeden Fall empfehlen, wenn man zum Beispiel auch den

00:08:41: Defender for Endpoint mit dabei hat, der ja auch sehr viel Protokolle schreibt,

00:08:44: dass man diese ganzen Protokolle dann auch innerhalb des Microsoft-Kosmos einfach

00:08:49: lässt und dort einfach aufhebt.

00:08:51: Dafür gibt es den Azure Sentinel und der Sentinel ist so ähnlich wie Splunk einfach zu sehen.

00:08:57: Das heißt, der sammelt auch alles, was an Protokollen kommt,

00:09:00: einmal aus der Cloud, meine ganzen Logins, meine Sachen, die der Defender so

00:09:04: macht, was Intune treibt, Firewall-Regeln,

00:09:08: Auswertung der Firewalls für Services, die auf Azure laufen.

00:09:11: Zusätzlich kann ich aber auch mit dem Microsoft Arc Agent auf meiner lokalen

00:09:17: Infrastruktur arbeiten. Das heißt, ich kann mir dort ein Stück Software installieren,

00:09:20: was mir dann sämtliche Protokolle von meinen Windows-Servern rüberbringt, auch in den Sentinel.

00:09:26: Zusätzlich kann der aber auch mit klassischem Syslog, also TCP, UDP, Port 514 umgehen.

00:09:32: Ich kann also auch hier weiterhin meine Logs weitergeben, Log-Forwarding machen

00:09:38: an den Sentinel und damit bekomme ich eben eine Cloud-Lösung,

00:09:42: die meine Protokolle alle außerhalb des eigenen Hauses speichert.

00:09:46: Das ist auch nicht löschbar für einen Angreifer und dadurch,

00:09:50: dass hier natürlich eine ganz andere Form der Intelligenz dahinter steckt.

00:09:54: Ich sage jetzt nicht KI, aber es ist halt sehr gutes Machine Learning,

00:09:56: was da einfach drin steckt, weiß dieses System oder lernt dieses System der

00:10:01: Sentinel eben auch, wie stehen die Dinge in Verbindung.

00:10:04: Der Sentinel weiß zum Beispiel auch, was ist eine schadhafte IP-Adresse,

00:10:09: weil der halt mit solchen Sachen ausgestattet wird.

00:10:11: Und wenn da wirklich was auftauchen sollte, was ich in meiner Überwachung habe,

00:10:16: dann bekomme ich automatisch eine Benachrichtigung.

00:10:18: Ich bekomme die Möglichkeit, das Ganze wie einen Vorfall zu behandeln.

00:10:22: Ich kann Personen hinterlegen, die sich darum kümmern sollen, bitte.

00:10:25: Ich kann mir einen automatischen Ticket erstellen lassen und ich bekomme auch Handreichungen.

00:10:29: Das heißt, ich kann nachvollziehen über den Sentinel, wie ist der Angriff über

00:10:34: die Bühne gegangen, wie konnte das Ganze überhaupt stattfinden.

00:10:36: Diese ganzen Sachen, die bekomme ich mit einer Lösung, zum Beispiel mit dem Microsoft Sentinel.

00:10:41: Gibt aber auch andere Lösungen, es gibt Alternativen.

00:10:44: Damit kann ich sowas dann halt tun. Und das ist was, was wirklich eine unglaubliche

00:10:49: Transparenz einfach in meinen Datenverkehr reinbringt.

00:10:52: Und wer mich lange genug kennt und vielleicht auch mit mir schon zusammengearbeitet

00:10:56: hat, der weiß, die Aussage von mir, die kommt immer wieder.

00:10:59: Die Wahrheit liegt am Ende im Traffic.

00:11:01: Ich muss mich früher oder später sowieso mit dem Traffic auseinandersetzen,

00:11:05: weil da sehe ich halt alles.

00:11:07: Na ja gut, wenn es verschlüsselter Traffic ist, vielleicht nicht ganz alles.

00:11:10: Aber ansonsten, da steckt halt die Wahrheit drin. Und damit kann ich halt auch

00:11:14: nachvollziehen, was ist denn überhaupt passiert.

00:11:17: Vielleicht noch an der Stelle ein Punkt, weil ich es gerade ja schon erwähnt

00:11:20: habe. Ich habe es mir jetzt nicht aufgeschrieben. Mir fällt es aber ein an der

00:11:23: Stelle, dass man da auch mal drüber reden sollte.

00:11:25: Das Thema verschlüsselter Traffic, also HTTPS, TLS-verschlüsselter Datenverkehr,

00:11:31: ist natürlich ein Thema, wo auch ein CM-System nichts mit anfangen kann.

00:11:35: Also es ist für das System so, wie wenn ihr jetzt zum Beispiel auf eurem eigenen

00:11:39: Gerät euch mal ein Wireshark installieren würdet, dann einfach mal im Internet

00:11:43: surft und euch dann anguckt, was wurde dort aufgezeichnet.

00:11:46: Es ist halt nur Datenbrei, weil der Datenbrei halt einfach entsteht,

00:11:50: weil es verschlüsselt wurde.

00:11:51: Also da kann auch ein Splunk, ein Sentinel oder wer auch immer nicht reingucken.

00:11:56: Es gibt aber die Möglichkeit, wenn man das möchte, dass man zum Beispiel an

00:12:00: einer Firewall sogenannte SSL-Interception fährt.

00:12:03: Das heißt, jedes Endgerät, was ich in meiner Infrastruktur habe,

00:12:07: bekommt ein Zertifikat.

00:12:08: Dieses Zertifikat kommt von meiner Firewall und die Firewall kann dann den Traffic

00:12:14: aufbrechen, kann reinschauen, was wird denn hier gesprochen.

00:12:17: Und danach, wenn es ausgewertet wurde, wenn das Regelwerk entsprechend gezogen

00:12:22: hat und das Protokoll aufgezeichnet wurde, dann mache ich das Paket wieder zu.

00:12:26: Damit es halt dann nach der Firewall oder dem Gerät, was eben hier SSL Intercept

00:12:30: spielt, wieder sicher ist.

00:12:32: Das bietet natürlich eine gewaltige Transparenz auf der einen Seite.

00:12:35: Auf der anderen Seite braucht es dazu natürlich aber auch Vertrauen.

00:12:38: Das heißt, wenn ihr in eurem eigenen Unternehmen darüber nachdenkt,

00:12:41: sowas wie SSL Interception zu nutzen, dann sprecht bitte definitiv vorher mit der Geschäftsleitung.

00:12:46: Wenn ihr einen Betriebsrat habt, müsst ihr auf jeden Fall auch mit dem sprechen.

00:12:50: Und darüber informieren, was dort technologisch möglich ist.

00:12:54: Weil es ist halt einfach ein Thema, die Leute verlassen sich darauf,

00:12:56: dass ihre Daten sicher sind, wenn das kleine Schlosssymbol zum Beispiel im Browser da ist.

00:13:00: An der Stelle brechen wir allerdings die Verschlüsselung auf,

00:13:03: gucken rein und machen es wieder zu, was theoretisch ein Datenschutzthema sein

00:13:08: kann. Und da sollte man auf jeden Fall drüber sprechen.

00:13:10: Ja, okay. Und damit haben wir jetzt also sozusagen unsere Logs,

00:13:16: wir haben eine Auswertung, wir haben eine automatische Alarmierung,

00:13:18: wenn wir das Ganze eingerichtet haben und wir sind jetzt in der Lage nachzuvollziehen,

00:13:23: was denn im eigenen Netzwerk passiert,

00:13:25: wer von wo was getan hat und haben dann auch die Möglichkeit,

00:13:29: wenn es einen Vorfall gegeben hat, hier wirklich nachzuvollziehen,

00:13:32: warum ist das Ganze passiert.

00:13:35: Ich kann es nur empfehlen, nutzt das auf jeden Fall. Aus Sicht des Datenschutzes

00:13:39: vielleicht an der Stelle auch noch ein kleiner Hinweis.

00:13:42: Wir sammeln hier natürlich ganz viele Daten und diese Daten sollten halt auch

00:13:47: dann nicht für alle Ewigkeiten aufgehoben werden.

00:13:49: Also auch hier gilt das System der Datensparsamkeit.

00:13:52: Wenn ihr solche Protokolle aufzeichnet, dann solltet ihr die vielleicht auch

00:13:57: nach einem definierten Zeitraum, zum Beispiel nach 90 Tagen oder länger,

00:14:00: auch wieder wegschmeißen.

00:14:02: Auf der einen Seite bläst es sonst das System unnötigerweise auf,

00:14:05: auf der anderen Seite sind wir halt dazu angehalten im Rahmen der DSGVO,

00:14:10: dass wir diese Daten halt auch nur zum Zwecke der Verarbeitung für den Zeitraum,

00:14:15: wo wir sie benötigen, aufheben, speichern und danach wieder entfernen,

00:14:19: weil sich natürlich aus diesen ganzen Protokollen halt auch unter Umständen

00:14:23: Profile erstellen lassen.

00:14:24: Weil, wenn ich weiß, mein Mitarbeiter XY hat immer die gleiche IP-Adresse bei

00:14:30: mir im System, der hat immer den gleichen Client, könnte ich natürlich über

00:14:34: diese Protokolle in einer Korrelation, in einer guten Abfrage,

00:14:37: die ich mir zusammenbauen kann.

00:14:39: Halt natürlich auch sehr viele Schlüsse und Rückschlüsse ziehen,

00:14:42: die vielleicht jetzt nicht dafür geeignet sind, um einen Sicherheitsvorfall

00:14:47: zu analysieren, sondern weil man halt einfach neugierig ist.

00:14:49: Und das gilt es definitiv zu verhindern.

00:14:52: Ich bekomme immer wieder auch mal Anfragen von Geschäftsführern,

00:14:56: ob es denn nicht auch möglich wäre, mit diesen Protokollen zum Beispiel eine

00:14:59: Intent-Analyse zu machen.

00:15:01: Also kriege ich dann raus beispielsweise, ob meine Mitarbeiterin regelmäßig,

00:15:05: meine Mitarbeiter auf Jobportalen rumsurft, bekomme ich mit,

00:15:09: wann er das tut oder wann sie das tut und könnte ich daraus nicht ableiten,

00:15:13: dass die Person gerade...

00:15:15: Ja, drauf und dran ist, den Job zu wechseln, sich woanders hin zu bewerben,

00:15:19: um dann halt dieser Person vielleicht auch jetzt schon Rechte zu entziehen,

00:15:23: damit sie eben kein Insiderwissen rausträgt und so weiter und so fort.

00:15:27: Es ist halt, ja, mit Spider-Man gesagt, mit großer Macht kommt auch eine große Verantwortung.

00:15:32: Das gilt natürlich für diese Protokolle auch, weil das ist halt, das ist das Gold.

00:15:36: Also diese Daten sind wirklich das, was jeden Tag getan wird und daraus lassen

00:15:40: sich halt Rückschlüsse entsprechend ziehen.

00:15:42: Deswegen bitte an dieser Stelle sauber damit umgehen,

00:15:46: safe damit umgehen, auch fair mit den Daten umgehen und vor allem im eigenen

00:15:50: Unternehmen mit Betriebsrat, mit Datenschutzbeauftragten, mit Geschäftsleitung

00:15:54: sprechen und hier auch ganz klar definieren,

00:15:56: was wird zu welchem Zweck für welchen Zeitraum aufgehoben, wer hat da drauf

00:16:00: Zugriff, vielleicht gibt es ja sogar die Möglichkeit ein Vier-Augen-System einfach

00:16:04: einzuführen, damit keiner da alleine in diesen Daten rumwühlt.

00:16:08: Jo, und das war es tatsächlich schon für diese Folge von Blue Screen Wissen.

00:16:12: Ich hoffe, ihr konntet wie immer was Hilfreiches für euch mitnehmen aus der Folge.

00:16:16: Ihr könnt mir auch gerne mal Vorschläge dalassen. Ihr habt unten in den Shownotes

00:16:20: die Möglichkeit, mir eine Nachricht zukommen zu lassen.

00:16:23: Nutzt diese Möglichkeiten, schlagt mir gerne auch mal ein Thema vor,

00:16:26: über was ich sprechen soll. Und ansonsten empfehlt gerne den Podcast weiter,

00:16:30: empfehlt gerne die Pegasus weiter.

00:16:32: Das hilft uns ganz ungemein für die Sichtbarkeit.

00:16:35: Folgt uns, liked uns, abonniert uns. Wir sind nicht nur im Podcast-Universum

00:16:40: zu Hause, sondern man findet uns natürlich auch auf YouTube.

00:16:42: Vielleicht guckt ihr auch gerade dieses Video auf YouTube.

00:16:45: Dann klickt doch einfach unten auf die Glocke, folgt dem Kanal, abonniert den Kanal.

00:16:49: Und ja, dann würde ich mich freuen, wenn wir uns auch zur nächsten Folge von

00:16:53: Blue Screen Wissen wiederhören. Macht's gut, bis dahin. Euer Alex.

00:16:58: Music.