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:
- Erhöhung des Log-Detailgrades
- Aufsetzen eines zentralen Log-Managementsystems
- Transfer der Logs vom Host zum Log-Managementsystem
- 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 Elasticsearch, Logstash 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:
