Leitfaden zur Konfigurierung der Windows Event-Protokollierung

Windows[English]Die Protokollierung von Ereignissen durch Windows lässt Raum für Verbesserungen. Unternehmen haben mit den Standardvorgaben Microsofts keinen ausreichenden Überblick über die Aktivitäten auf ihren Workstations und Servern. Das australische Signals Directorate (ASD) und das Australian Cyber Security Centre (ACSC) haben einen Leitfaden für die Konfiguration der Windows-Protokollierung veröffentlicht, der Hinweise auf Verbesserungen in der Protokollierung unter Windows gibt.


Anzeige

Das australische Signals Directorate (ASD) hat bei seinen Untersuchungen immer wieder festgestellt, dass die Unternehmen keinen ausreichenden Überblick über die Aktivitäten auf ihren Workstations und Servern haben, schreibt man hier. Ein guter Überblick über die Vorgänge in der Umgebung eines Unternehmens ist für die Durchführung einer effektiven Untersuchung unerlässlich. Eine gute Protokollierung hilft andererseits auch bei der Reaktion auf Cybersicherheitsvorfälle, indem sie wichtige Einblicke in die Ereignisse im Zusammenhang mit einem Cybersicherheitsvorfall liefert und die Gesamtkosten für die Reaktion auf diese Vorfälle verringert.

Configuring Windows-Logging

Die Tage bin ich über obigen Tweet auf einen von ASD/ACSC herausgegebenen Leitfaden für die Konfiguration der Windows-Protokollierung gestoßen. Der Leitfaden, der sich hier abrufen lässt, wurde für die Einrichtung und Konfiguration der Windows-Ereignisprotokollierung und -weiterleitung entwickelt. Der Leitfasen soll auch eine Protokollierung sowohl zur Erkennung als auch die Untersuchung bösartiger Aktivitäten unterstützen, indem er ein ideales Gleichgewicht zwischen der Erfassung wichtiger Ereignisse und der Verwaltung von Datenmengen herstellt. Dieser Leitfaden ist laut Beschreibung auch als Ergänzung zu bestehenden hostbasierten Systemen zur Erkennung und Verhinderung von Eindringlingen gedacht.

Dieser Leitfasen richtet sich an IT-Fachleute für Informationstechnologie und Cybersicherheit und behandelt die Arten von Ereignissen, die erzeugt werden können, und eine Bewertung ihres relativen Werts, die zentrale Sammlung von Ereignisprotokollen, die Aufbewahrung von Ereignisprotokollen und empfohlene Gruppenrichtlinieneinstellungen zusammen mit Implementierungshinweisen.Das Ganze ist etwas sperrig, aber für den einen oder anderen Administrator unter der Leserschaft dieses Blogs vielleicht als Anregung hilfreich.


Anzeige


Anzeige

Dieser Beitrag wurde unter Windows abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

4 Antworten zu Leitfaden zur Konfigurierung der Windows Event-Protokollierung

  1. Mario sagt:

    Danke für diesen Link.
    Frage in die Runde: Habt jemand schon Erfahrung damit?
    Wie macht Ihr die Auswertung auf dem "Collector"?

    • 1ST1 sagt:

      Wir haben für verschiedene Themenbereiche (Netzwerkkomponenten, Windows/Linux, Gatweways, Firewall, …) verschiedene "Kollektoren", also sprich SIEM, AD-Audit-System, Netzwerkmonitoring usw. Je nach Lösung die man verwendet, verlangen die für Windows auch noch zusätzliche Audit-Settings, was die Australier da vorschlagen ist nur der Anfang… Man kann z.B. auch DNS-Auflösungen aus einem AD-DNS loggen oder die lokalen Firewall-Logs einfangen und an so ein System weiterleiten. Da findet man dann mitunter auch Datenpakete die über DNS ausgeschleust werden oder Systeme, die eigentlich keine Namensauflösungen von externen Adressen machen sollten, es aber trotzdem tun.

      Ein guter SIEM-Einstieg für das Monitoring wäre z.B. das kostenlose/opensource Wazuh (das bekommt seine Ereignisse über einen zu installierenden Agent oder per Syslogprotokoll), aber das erfordert bei der Einrichtung viel Handarbeit, weil du z.B. erstmal überlegen musst, welche Windows-Event-IDs du einsammeln willst und musst da gibts nämlich keine (öffentlichen) Empfehlungen und ein "Full Take" sprengt alle Dimensionen (was Linux so loggt ist dagegen lächerlich wenig) , und das ist dann erstmal Textadventure bis das läuft, denn für Windows-Events ist darin kaum was vordefiniert (eher Beispiele was man machen könnte und manches davon ist nur Spielerei ohne Nutzen), für manche Events muss dann noch der Parser angepasst werden, damit Wazuh die Werte korrekt zuordnet, die ganzen Mitre-Klassifizierungen für die Events musst du auch noch konfigurieren, usw. und dann brauchst du halt Storage im zweistelligen TB-Bereich, für die Erfassung von Systemen in vierstelliger Anzahl um einen aussagekräftigen Zeitraum, mindestens 1/2 Jahr, archivieren zu können. Wazuh war unser Einstieg um erste Erfahrungen zu sammeln, wir können inzwischen darüber genau sehen was sich wann und wo angemeldet hat, egal ob Linux oder Windows, welche Prozesse gestartet wurden, was von Applocker gesperrt wurde, wer sein Passwort wechselte oder gesperrt wurde, wer welche Gruppenrichtlinien oder Gruppenmitgliedschaften geändert hat und vieles vieles mehr, momentan prüfen wir allerdings den Umstieg auf was kommerzielles, ohne hier Namen zu nennen. Wazuh ist schonmal nett, aber komm bloß nicht auf die Idee, das über seine Mitre-Matrix Alarme per Email auslösen zu lassen, du ertrinkst in False-posives, weswegen das eigentlich nur zu Analysezwecken brauchbar ist, aber nicht für Prävention (Active Response).

  2. 1ST1 sagt:

    Die Event-Audits lokal zu aktivieren ist ein erster wichtiger Schritt. Im zweiten Schritt muss man sich allerdings auch überlegen, ob man auf jedem System einzeln in die Eventlogs schauen möchte, oder ob man das alles zentral in einem SIEM oder einem AD-Audit-Tool sammeln will, wo man dann systemübergreifend zentral nach Ereignissen suchen kann. Aber die Windows-Systeme auf diese Weise zu monitoren ist nur die Hälfte, was ist mit sonstigen Systemen im Netz, Überwachung vom Proxy, VPN, DNS, Firewall, Storage (man denke an die Ransomware-verschlüsselten ESXi-Volumes), wie wärs mal mit einer Klasifizierung und Zugrifssrechte-Analyse auf den Fileservern, Datenbanken, Sharepoint, Exchange und andere Mailserver, Monitoring in der Clout (Azure, AWS, Google, …), man kann das Spiel sehr weit treiben um tatsächlich einen Überblick zu bekommen. Da gibts dann ganz viele unterschiedliche Lösungen, die von einem einfachen kostenlosen Syslog-Server bis welchen mit verhaltensbasierend lernender KI hin zum Gegenwert eines oder mehreren netten Autos pro Jahr reichen. Und neben den Softwarelizenzen braucht man je nach Lösung auch noch nennenswert viel Storage um die ganzen Events zentral zu sammeln. Aber sowas ist schon cool, wenn man es hat. Wenn man hat, muss man halt mit dem Betriebsrat reden, weil damit prinzipiell eine Mitarbeiterüberwachung möglich ist, da müssen Vereinbarungen getroffen werden.

  3. Mario sagt:

    Gerade habe ich noch über eine interessanten Artikel gefunden, der zu diesem Thema hier passt:
    Security Onion ist eine Open-Source-Plattform für Threat Hunting, Security-Monitoring und Log-Manage¬ment. Es versammelt freie Tools wie Kibana, Elastic Fleet, InfluxDB, CyberChef oder Suricata. Die Lösung bietet Zugang zu diesen Werkzeugen über eine Web-Konsole. Wir zeigen, wie sie sich für die Log-Analyse von Windows nutzen lässt.
    https://www.windowspro.de/thomas-joos/windows-eventlog-analysieren-security-onion

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.