Ad-Hoc Log Management im Ernstfall (SEC Defence)

defence

Viele Organisationen, welche kein eigenes Incident Response Team haben, verfügen über keine oder nur sehr mangelhafte Visibility im eigenen Unternehmensnetzwerk. Doch vor Allem für die Aufarbeitung und Behebung des Vorfalls ist es unerlässlich auf allen Systemen angemessene Sichtbarkeit sicherzustellen.

 

Nur so können Angreiferaktivitäten rasch entdeckt, aufgearbeitet und analysiert werden, um das Unternehmensnetzwerk von den unautorisierten Aktivitäten zu säubern und wiederherzustellen. Dieser Blog Post stellt frei verfügbare Tools vor, die sich für ein kurzfristiges Aufsetzen für den Einsatz im Fall eines Security Incidents eignen.

Cyber crime and Incident Management banner - SEC Consult

Einleitung

Cyberkriminalität steigt stetig. Im Vergleich von 2018 auf 2019 stiegen allein in Österreich die angezeigten Fälle um 45% auf 28.439 [1]. Bei der Dwell Time, also der Zeit die ein Angreifer im Netzwerk aktiv ist bis zu dessen Entdeckung, ist eine kontinuierliche Abnahme zu erkennen. Basierend auf den jährlichen Security Reports des Unternehmens FireEye lag der Median der globalen Dwell Time im Jahr 2018 bei 78 Tagen und sank im Jahr 2019 auf 56 Tage. Dies ist ein weiterer deutlicher Rückgang und lässt vermuten, dass Organisationen die Visibility im Netzwerk verbessern und so Angriffe früher erkennen können. Der Prozentsatz der Unternehmen, welche von Externen über eine mögliche Kompromittierung benachrichtigt werden, liegt jedoch im weltweiten Durchschnitt bei 53%[2]

Cyber crime and Incident Management with data banner - SEC Consult

Natürlich soll die Zahl der extern gemeldeten Incidents im Verhältnis zu den selbst bemerkten möglichst gering gehalten werden. Die interne Visibility ist demnach doch noch nicht so ausgeprägt, wie die von aufmerksamen dritten Parteien. Viele Unternehmen sind oftmals nicht genügend vorbereitet und es mangelt an Ressourcen, das Incident Handling eines Sicherheitsvorfalls erfolgreich durchzuführen.

Fehlende Visibility macht es auch den besten Incident Respondern schwer. Externe Cyber Security Incident Response Teams (CSIRTs) starten die Aufarbeitung zumeist in einem ihnen vollkommen unbekannten Netzwerk. Der erste Schritt ist dann die Herstellung eines Grundmaßes an Sichtbarkeit, um den Analysten die benötigten Informationen zur Untersuchung und Behebung des Angriffs zukommen zu lassen. Diese Aufgabe gliedert sich in vier Teilaspekte:

  1. Erhöhung des Log-Detailgrades
  2. Aufsetzen eines zentralen Log-Managementsystems
  3. Transfer der Logs vom Host zum Log-Managementsystem
  4. Erhöhung der Log-Coverage

Diese vier Aspekte werden im Folgenden unter dem Gesichtspunkt der raschen Implementierung in dafür unvorbereiteten Netzwerken erarbeitet.

 

ERHÖHUNG DES LOG-DATEILGRADES

Der erste Schritt ist die Verbesserung des Loggings am Host. Der Analyst benötigt ausreichend Informationen darüber, was auf einem Host passiert, als etwa nur fehlgeschlagene und erfolgreiche Login-Events. Wichtig sind etwa gestartete Prozesse, um sich ein Bild von der Nutzung des Systems zu machen und verdächtige Aktivitäten eines Angreifers nachverfolgen zu können. Die Erläuterungen inklusive Best Practices sowie verfügbare Konfigurationen erfolgen für Windows Systeme und für Linux Systeme getrennt.

A.    Windows

Das Windows Event Log[17] bietet mit der richtigen Konfiguration eine solide Logging-Funktionalität. Mit Sysmon aus den SysInternal Tools [3] gibt es jedoch eine weitere, großartige Möglichkeit zum Logging auf Windows Systemen, welche häufig als umfangreiche Erweiterung zu den normalen Windows Event Logs eingesetzt wird.

1)   Windows Event Log

Die Standardeinstellungen der Windows Event Logs sind nicht ausreichend, um Incident Respondern die erforderliche Einsicht in die Aktivitäten eines Systems zu gewähren. Der erste Schritt ist die Anpassung der Log-Größe. Die standardmäßige Einstellungen haben eine relativ kurze Rotation Time auf Hostlevel, welche sich bei Erhöhung des Log-Detailgrades noch mehr verkürzen würde. Die passende Größe muss natürlich auf die Umgebung und die Systeme angepasst werden, jedoch können die folgenden Werte als erste Richtwerte betrachtet werden.  Die Empfehlungen hierfür basieren auf einer Herausgabe des Australian Cyber Security Centre. [4]

Es wird empfohlen, die maximale Größe des Security Event Logs auf 2 GB und die der Applikation sowie System Event Logs auf 64 MB zu erhöhen. Die wichtigsten Verbesserungsmöglichkeiten der Logs fallen in die Bereiche:

  • Benutzerkonten (Logins, Lockouts, Modifizierungen, NTLM Authentifizierung)
  • Persistenzmechanismen, Credential Access sowie Lateral Movement Techniken (Scheduled Tasks, Services, File Shares, WMI, Object Access, PowerShell)
  • Anti Virus (EMET, Windows Defender, Logs von 3rd-Party AV Lösungen)
  • Prozessausführungen (Process Tracking – sofern Sysmon nicht verfügbar ist, AppLocker, Windows Error Reporting, Code Integrität)

Events in Verbindung mit dem Logging selbst sind ebenfalls von großer Bedeutung, etwa wenn ein Angreifer versucht das Event Logging zu manipulieren, zu stoppen oder die Event Logs zu löschen [4].

Für eine rasche Umsetzung beim Kunden können die vordefinierten Änderungen der Audit Policies via GPOs vorgenommen werden.

2)   Sysmon

Sysmon steht für System Monitor und ist ein Tool, welches von Microsoft entwickelt und kostenfrei zu Verfügung gestellt wird. Es bietet erweiterte Funktionalitäten im Vergleich zum normalen Windows Event Log und kann aufgrund der flexiblen Filtermöglichkeiten stark an die Anforderungen des Netzwerkes angepasst werden. Erwähnenswert ist hierbei auch die Funktionalität der IMPHASH Berechnung des ausgeführten Programms. Dies ist ein Verfahren, bei dem einzelne Teile, wie etwa die aufgerufenen APIs, gehasht werden. Dies ermöglicht eine Erkennung und Korrelation von abgeänderten Schadsoftwares, um Anti Viren Lösungen zu umgehen[3]

Die Sysmon Konfiguration sollte im Normalfall stärker an das Unternehmensnetzwerk angepasst werden. Für den schnellen Einsatz empfiehlt sich jedoch eine vorgefertigte Konfigurationsdatei. Eine öffentlich verfügbare Konfiguration in bereits guter Qualität findet sich im GitHub Repository von Swift On Security[5]. Im weiteren Verlauf kann die Konfiguration iterativ optimiert werden. Das Deployment von Sysmon erfolgt über die im Unternehmen etablierte Software Management Plattform, beispielsweise über SCCM, oder über GPOs. [4]

B.    Linux

Das Linux Auditing System kurz auditd ist das Linux Pendant zum Windows Event Log respektive Sysmon. Es ist ebenfalls stark konfigurierbar und bietet hervorragende Einsicht in die Vorgänge auf Linux Systeme. Als Startpunkt für die rasche Einführung kann die Konfigurationsdatei von Florian Roth[6] herangenommen werden. Sie ermöglicht ein qualitativ hochwertiges Logging welches wie die Sysmon Konfiguration ebenfalls wieder iterativ optimiert werden kann. Die standardmäßige maximale Log-Größe ist für ein stark aktives System oftmals zu gering. Die optimale Größe muss je nach Aktivität, dem Logging-Detailgrad und den verfügbaren Ressourcen des Systems abhängig gemacht werden.  Unter [7] finden sich mehr Informationen zu Logging auf Linux Systemen.

 

ZENTRALES LOG-MANAGEMENTSYSTEM

Der nächste Schritt für die Erhöhung der Visibility im Unternehmensnetzwerk ist die Implementierung eines zentralen Log-Managementsystems. Ein zentrales Log-Management bringt einige Vorteile mit sich. Die Größe der Logs auf den Hosts kann kleiner gehalten werden, ohne dass es Nachteile bei der Sichtbarkeit in die Vergangenheit gibt. Die Speicherung erfolgt zentral und kann so an die gewünschte Retention Time angepasst und etwa der Langzeitarchivierung übergeben werden. Der Zugang zum zentralen Log Management muss streng abgesichert und überwacht werden.

Ein Entfernen oder Manipulieren der Logs auf den Hosts ist – sofern sie bereits and das Log-Managementsystem gesendet wurden – wirkungslos, und kann dadurch sogar erkannt werden. Die abschließenden Argumente hierfür sind die Möglichkeit der Anreicherung der Logs mit weiteren Informationen, der Korrelation von zusammenhängenden Events, dem Auslösen von Alarmen bei verdächtigen Aktivitäten und der einfacheren und effizienteren Analyse der Logs, da die Untersuchung an einer Stelle erfolgen kann und die Analysten sich nicht physisch von System zu System bewegen müssen. [8]

Im Folgenden werden zwei bekannte Open Source Log-Managementsysteme vorgestellt: ELK Stack und Graylog.

A.    ELK Stack

Der ELK Stack[9] ist wohl eines der bekanntesten Open Source Log-Managementsysteme. Das System ist eine Fusion der drei Open Source Projekte ElasticsearchLogstash und Kibana. Ersteres ist eine Engine zur Indexierung, Suche und für Analytics. Zweiteres ist eine Pipeline zur Datenverarbeitung, welche gleichzeitig Daten aus diversen Quellen erfasst, transformiert und an Elasticsearch weiterreicht. Letzteres bietet die grafische Benutzeroberfläche, mit der die Analysten die Daten durchsuchen, Diagramme, Grafiken und Dashboards erstellen können. Nachträglich wurden einzelne Tools zum Transfer von Dateien, etwa Logs, hinzugefügt. Diese Funktionalität wurde Beats genannt. Dies wird im nächsten Kapitel bearbeitet. Mit der Erweiterung der Funktionalität wurde das Projekt in Elastic Stack umbenannt.

Analysten können über Kibana die gesammelten Logs durchsuchen oder Alerts erstellen, um etwa auf entdeckte Indicators of Compromise (IOCs) aufmerksam gemacht zu werden. Die folgende Abbildung zeigt die Ausgabe eines Suchvorgangs auf Kibana:

Kibana Search Results screen - SEC Consult
Abbildung 1 – Kibana Suchergebnisse [8]

B.    Graylog

Graylog startete 2009 in Hamburg als Open Source Projekt und ist mittlerweile ein ebenfalls sehr bekanntes Log-Managementsystem mit Hauptsitz in Texas, USA[10]. Die Funktionalitäten sind dabei sehr ähnlich zu denen des ELK-Stacks.  Das System selbst setzt sich aus Graylog als Applikation und Benutzeroberfläche, MongoDB und Elasticsearch zusammen.  Im Gegensatz zu ELK als Big Data Solution war Graylog von Beginn an als Log-Managementsystem geplant und dementsprechend designt. Besser empfunden werden bei Graylog Punkte wie die Benutzerfreundlichkeit, Simplizität der Installation sowie das Berechtigungssystem. [11]

Die folgende Abbildung zeigt Suchergebnisse in Graylog:

Graylog search results screen - SEC Consult
Abbildung 2 – Graylog Suchergebnisse[11]

Transfer der Logs

Der letzte Schritt zur Einbindung in das zentrale Log-Management ist der Transfer der Logs von den Hosts in. Dazu gibt es diverse Methoden, wie etwa das Event Forwarding unter Windows. Bei der Umsetzung mittels ELK Stack oder mittels Graylog werden bereits Funktionalitäten dafür mitgeliefert. Hervorgehoben werden dafür Winlogbeat für die Übermittlung von Windows Event Logs sowie Sysmon Logs und Filebeat für die Übermittlung von Auditd- oder anderen Applikationslogs unter Linux. [14][15]

Eine komfortable Funktionalität für die Verwaltung der Beat-Konfigurationen unter Graylog ist das Graylog Sidecar. Dabei gibt es einige Features wie die zentrale Verwaltung von Konfigurationen, dem einfachen Deployment der Konfigurationen, der Erstellung von Gruppen mit individuellen Konfigurationen sowie einigen Sicherheitsfeatures. Über Graylog Sidecar lässt sich auch der Status der Transferagents abfragen und steuern. [15]

 

Log Coverage

Bei der Einführung eines zentralen Log-Managements ist es in der Praxis kaum möglich, alle Systeme gleichzeitig in das Log-Managementsystem einzubinden. Log Coverage ist der Anteil der Systeme, welcher im zentralen Log-Management eingebunden sind. Abhängig von der Netzwerkgröße können die Systeme immer nur schrittweise in das Log-Management integriert werden, um die Möglichkeit einer Überlastung zu reduzieren. Anhand der Performance-Überwachung des Log-Managementsystems können weitere Schritte gesetzt werden, um die Skalierbarkeit zu erhöhen. Dazu zählt etwa die Verwendung eines Log-Brokers wie Kafka. [13]

Die Reihenfolge der Systeme für die Einführung in das Log-Managementsystem sollte anhand der Business Kritikalität und der Wahrscheinlichkeit einer Infektion erfolgen. Mit der gestaffelten Einführung wird dann nach und nach die Log Coverage und somit die Visibility innerhalb des Unternehmensnetzwerkes verbessert.

 

Conclusio

Mit frei verfügbarer Software können vollständige Log-Managementsysteme abgebildet werden. Mittels als Open Source verwalteter Konfigurationen zu Komponenten kann der Aufwand für die Implementierung reduziert werden. Die oberflächliche, individuelle Anpassung an die Situation sollte während des Incidents und die detailliertere Anpassung im Nachgang des Incidents vorgenommen werden. Dies kann im laufenden Betrieb via iterativem Verbesserungsprozess geschehen. Das rasche Deployment von zentralen Log-Managementsystemen stellt sich etwas komplizierter dar. In den diversen Quellen zum ELK Stack und Graylog sowie aus einer kurzen Einsicht in Konfigurationsdateien zum automatisierten Deployment solcher Systeme scheint Graylog als einfacher umzusetzen.

Ein weiterer erschwerender Aspekt ist die Art der Implementierung. Zumeist wird ein Log-Managementsystem im internen Netzwerk ohne Zugriff aus dem Internet platziert. Dafür muss der Kunde einen passenden Server mit entsprechenden Ressourcen zu Verfügung haben. Eine Vereinfachung wäre ein Deployment in der Cloud, wobei die Logs über TLS verschlüsselt übertragen werden müssen. Dies hätte den Vorteil der Skalierbarkeit und die bessere Vermeidung von blinden Flecken. Beispielsweise Clientsysteme, welche im Home-Office ohne aktiver VPN-Verbindung genutzt werden. Dabei besteht die Gefahr, dass die Logs auf den Clients überschrieben werden, noch bevor sie an das zentrale Log-Managementsystem gesendet wurden. Bei einem Deployment in der Cloud gilt es ganz besonders, diverse Aspekte hinsichtlich der DSGVO zu klären. Grundvoraussetzungen hierfür sind die verschlüsselte Übertragung der Logs an das Log-Managementsystem, der Einsatz von Diskverschlüsselung, eine strikte Zugriffsbeschränkung für das Log-Managementsystem, Pseudonymisierung von Logs und der Durchsetzung von Retention-Times und der sicheren Löschung nach Ablauf der Frist. [16]

Zum Einfluss der DSGVO auf das Log-Management und insbesondere bei einem Deployment des Systems in der Cloud kann jedoch ein eigener Blog-Post gefüllt werden.

Die rasche Einführung eines umfassenden Log-Managements im Security Incident kann die Zeit bis zur Behebung des Vorfalls drastisch reduzieren. Dies reduziert in weiterer Folge zumeist die Schadensauswirkungen, senkt dadurch Kosten und mögliche weitere rechtliche oder reputationsschädigende Folgen. Einen Plan für ein rasches Deployment von Log-Managementsystemen mit Automatisierungen auszuarbeiten birgt großes Potential für CSIRTaaS Dienstleistungen.

Abschließend sollte jedoch erwähnt werden, dass auch mit der raschen Einführung eines Log-Managements keine vergangenen Logs wiederhergestellt werden können, sondern nur die Visibility im Netzwerk für die momentanen und zukünftigen Ereignisse erhöht wird. Die Implementierung eines umfassenden Log-Managements im Vorhinein ermöglicht eine bessere Planung und Vorbereitung, sowie eine erhebliche Zeitersparnis von der Erkennung bis zur Behebung des Vorfalls und zur Schaden- und Kostenminimierung im Ernstfall.

Q&A

Eine zentrale Funktionseinheit, an die die Logs der Systeme gesendet werden, die die Verwaltung und Indexierung der Logs übernimmt sowie als zentrales Interface zur Analyse mittels Suchfunktionen, Dashboards oder Alert-Funktionalitäten dient.

Zur raschen Herstellung oder Erhöhung der Visibility im Unternehmensnetzwerk bei bereits eingetretenen Security Incidents

Die Einführung eines klassischen Log-Managementsystems erfolgt über einen längeren Zeitraum hinweg und sollte gut und lange geplant sein und mehrere Testphasen beinhalten. Dies garantiert eine optimale Einführung in das Produktivsystem, eine an das Unternehmensnetzwerk sowie an dessen Use Cases angepasste Logging-Strategie und hilft bei der Vermeidung von typischen Fallstricken wie etwa der Überlastung eines unterdimensionierten Log-Managementsystems durch die Flut an Logs. Bei dem hierbei behandelten Ad Hoc Log-Managementsystem liegt der Fokus auf einer möglichst raschen und zumindest rudimentären Einführung eines Log-Managementsystems, um den bereits eingetretenen Security Incident aufklären sowie beheben zu können.

  • Erhöhung des Log-Detailgrades
  • Aufsetzen eines zentralen Log-Managementsystems
  • Transfer der Logs vom Host zum Log-Managementsystem
  • Erhöhung der Log-Coverage im Netzwerk
  • ELK Stack / Elastic Stack
  • Graylog

Der Anteil der Systeme, welche an das zentrale Log-Managementsystem angebunden sind und überwacht werden, an der Gesamtheit der Systeme im Unternehmensnetzwerk.

Dwell Time ist die Zeit, die ein Angreifer im Netzwerk aktiv ist bis zur Entdeckung.

Konfigurieren Sie den Security Event Log auf 2 GB und die Logs der Applikation sowie System Event Logs auf 64 MB.

CSIRTaaS steht für Computer Security Incident Response Teams as a Service. Das bedeutet nichts anderes als die Durchführung von Incident Response als Dienstleistung, wie etwa das SEC Defence Service der SEC Consult.

Sowohl Winlogbeat als auch Filebeat sind Tools, um die Logs vom Host an das zentrale Log-Managementsystem zu senden. Winlogbeat übernimmt die Übermittlung von Windows Event Logs, während Filebeat verschiedenste Logs, vor Allem jedoch auf Linux-Systemen, transferiert..

Sources

[1]ORF, „Starker Anstieg bei Cyberkriminalität,“ 8 Mai 2020. [Online]. Available: https://orf.at/stories/3164864/. [Accessed 05/13/2020].

[2]FireEye Mandiant Services, „M-Trends 2020,“ 2020. [Online]. Available: https://content.fireeye.com/m-trends/rpt-m-trends-2020. [Accessed 05/13/2020].

[3]Microsoft, „Sysmon v11.0,“ 28 April 2020. [Online]. Available: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon. [Accessed 05/14/2020].

[4]Australian Cyber Security Center, „Windows Event Logging and Forwarding,“ 2019. [Online]. Available: https://www.cyber.gov.au/sites/default/files/2019-03/Windows_Event_Logging_Technical_Guidance.pdf. [Accessed 05/14/2020].

[5]Swift On Security, „sysmon-config | A Sysmon configuration file for everybody to fork,“ [Online]. Available: https://github.com/SwiftOnSecurity/sysmon-config. [Accessed 05/14/2020].

[6]F. Roth, „auditd,“ [Online]. Available: https://github.com/Neo23x0/auditd. [Accessed 05/14/2020].

[7]National Security Agency, “Guide to the Secure Configuration of Red Hat Enterprise Linux 5”, 26. August 2011, [Online]. Available: https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm. [Accessed 06/18/2020].

[8]N. Carstensen, „Graylog,“ 29 November 2019. [Online]. Available: https://www.graylog.org/post/what-is-log-management-a-complete-logging-guide. [Accessed 05/14/2020].

[9]Elastic, „The Elastic Stack,“ [Online]. Available: https://www.elastic.co/de/elastic-stack. [Accessed 05/14/2020].

[10]Graylog, „About Graylog,“ [Online]. Available: https://www.graylog.org/about. [Accessed 05/14/2020].

[11]D. Tkachenko, „Logicify – Graylog as a Tool for Technical Monitoring of Software Products,“ 19. Juni 2018. [Online]. Available: https://www.logicify.com/en/blog/graylog-as-a-tool-for-technical-monitoring-of-software-products-we-build/. [Accessed 05/14/2020].

[12]Graylog, „Graylog 3.1 Documentation: Searching,“ [Online]. Available: https://docs.graylog.org/en/3.1/pages/queries.html. [Accessed 05/14/2020].

[13]J. Kosik, „Large-Scale Log Management Deployment,“ June 13, 2018. [Online]. Available: https://uploads-ssl.webflow.com/5ac133a161e365de41ae40d3/5b439fa45a717805ecd1c1cf_Pan-Net%20Deployment%20with%20Graylog.pdf. [Accessed 05/14/2020].

[14]Elastic, „Beats overview,“ [Online]. Available: https://www.elastic.co/guide/en/beats/libbeat/current/beats-reference.html. [Accessed 05/14/2020].

[15]Graylog, „Introduction to Graylog Sidecar,“ [Online]. Available: https://www.graylog.org/features/sidecar. [Accessed 05/14/2020].

[16]Graylog, „Resources | What GDPR Means for Log Management,“ [Online]. Available: https://www.graylog.org/resources/what-gdpr-means-for-log-management. [Accessed 06/12/2020].

[17]Windows Event Log, „Event Viewer | Wikipedia,“ [Online]. Available: https://en.wikipedia.org/wiki/Event_Viewer . [Accessed 06/12/2020].