SIEM-Systeme richtig konfigurieren: Wie Unternehmen Sicherheitslücken in der Bedrohungserkennung schließen

SIEM-Effektivität auf dem Prüfstand: Wo Bedrohungserkennung versagt

Laut einem Beitrag von Securelist zeigen Wirksamkeitsprüfungen bei Unternehmenskunden deutliche Schwachstellen im Betrieb von Security Information and Event Management-Systemen. Die komplexen Plattformen zur Bedrohungserkennung sind nur so leistungsfähig wie ihre Konfiguration und die angebundenen Datenquellen. Eine einmalige Einrichtung bei der Implementierung genügt nicht: Sowohl die IT-Infrastruktur als auch Angriffstechniken entwickeln sich kontinuierlich weiter.

Die Sicherheitsexperten haben eine Bewertungsmethodik entwickelt, die sich auf Kaspersky SIEM bezieht, aber auf beliebige Lösungen übertragen werden kann. Die Untersuchung deckt typische Betriebsfehler auf und zeigt Optimierungsansätze.

Systematische Bewertung in elf Dimensionen

Die Effektivitätsprüfung konzentriert sich auf elf zentrale Bereiche: Zusammensetzung und Umfang der Datenquellen, deren Abdeckung, Datenflüsse, Normalisierungskorrektheit, Funktionsfähigkeit und Genauigkeit der Erkennungslogik, deren Abdeckung, Verwendung von Kontextdaten, technische Integration in SOC-Prozesse, Umgang der Analysten mit Warnmeldungen, Weiterleitung von Informationen an andere Systeme sowie Bereitstellungsarchitektur und Dokumentation.

Die Analyse erfolgt mehrstufig: Zunächst werden vorhandene Unterlagen ausgewertet, um Implementierungsziele und -einstellungen zu erfassen. Anschließend befragen die Prüfer Systemingenieure, Analysten und Administratoren zu aktuellen Aufgaben und Problemen. Den umfangreichsten Teil bildet die Datensammlung innerhalb des SIEM mit Lesezugriff auf das System.

Drei Kategorien von Betriebsproblemen

Die identifizierten Schwachstellen lassen sich in drei Gruppen einteilen: Leistungsprobleme betreffen Betriebsfehler in Systemkomponenten und werden üblicherweise vom technischen Support behoben. Effizienzprobleme treten auf, wenn das System zwar funktioniert, aber eingeschränkt oder fehlerhaft genutzt wird. Erkennungsprobleme zeigen sich, wenn die Warnmeldungen überwiegend Fehlalarme darstellen und das System Vorfälle übersieht.

Unvollständige Quelleninventare

Bei Wirksamkeitsprüfungen stellen die Analysten häufig fest, dass das Verzeichnis der angebundenen Quelltypen nicht aktualisiert wird, wenn sich die Infrastruktur verändert. Teilweise erfolgte seit der ersten Bereitstellung keine Anpassung mehr, was die Erkennungsmöglichkeiten einschränkt. Bestimmte Quelltypen bleiben für das System vollständig unsichtbar.

Die Prüfer sind auch auf ungewöhnliche Fälle gestoßen: In einer Infrastruktur mit Windows- und Linux-Hosts war die Überwachung nur für eine Betriebssystemfamilie eingerichtet. Um solche Lücken zu identifizieren, empfehlen die Experten einen Abgleich der angebundenen Quelltypen mit dem tatsächlichen Bestand.

Die Fachleute haben ein Referenzblatt mit Systemtypen erstellt, die in den meisten Unternehmen vorkommen. Hohe Priorität haben Quellen für Fernzugriff, externe Dienste mit Internetzugang, externer Perimeter, Endpunkt-Betriebssysteme und Informationssicherheits-Tools. Mittlere Priorität erhalten Fernzugriffsverwaltung innerhalb des Perimeters, interne Netzwerkkommunikation, Verfügbarkeitsüberwachung sowie Virtualisierungs- und Cloud-Lösungen. Niedrige Priorität wird Geschäftsanwendungen, internen IT-Diensten und Fachabteilungs-Software zugeordnet.

Fehlende Datenströme von Kollektoren

Laut Securelist empfängt der SIEM-Kern durchschnittlich von 38 Prozent der konfigurierten Kollektoren keine Ereignisse. Für diese Quellen können zwar Korrelationsregeln existieren, diese werden jedoch niemals ausgelöst. Da ein einzelner Kollektor hunderte Workstations bedienen kann, bedeutet der Ausfall eines einzigen Kollektors den Verlust der Überwachungsvisibilität für einen erheblichen Infrastrukturteil.

Die Lokalisierung dieser Probleme umfasst zwei Schritte: Zunächst wird der Collector-Status überprüft, um diejenigen mit Status „Offline“, „Gestoppt“ oder „Deaktiviert“ zu identifizieren. Anschließend erfolgt die Prüfung des Ereignisflusses durch statistische Erfassung über einen optimalen Zeitraum. Die Experten empfehlen, mehrere Abfragen für verschiedene Zeiträume durchzuführen, da manche Quellen nur selten Telemetriedaten übertragen.

Lückenhafte Quellenabdeckung

Selbst wenn Ereignisse fließen, bedeutet dies nicht automatisch vollständige Abdeckung. Das System empfängt möglicherweise nicht von allen Quellen eines bestimmten Typs Daten. Ein Beispiel: Bei der Bereitstellung werden Workstations sofort zur Überwachung angebunden, während das Serversegment zurückgestellt wird. Das SIEM empfängt und normalisiert Windows-Ereignisse und die Korrelationsregeln funktionieren – ein Vorfall im nicht überwachten Serversegment bliebe jedoch unentdeckt.

Die Analysten empfehlen, die Anzahl eindeutiger Datenquellen zu ermitteln, die Protokolle eines bestimmten Typs senden, und diese mit der tatsächlichen Anzahl zu vergleichen.

Ressourcenverschwendung durch Rohdatenspeicherung

Die Option zur Beibehaltung von Rohereignissen kann nützlich sein für die Entwicklung benutzerdefinierter Normalisierer oder zur Speicherung von Ereignissen, die bei Vorfalluntersuchungen benötigt werden. Eine unachtsame Verwendung verursacht jedoch mehr Schaden als Nutzen.

Durch Aktivierung dieser Option verdoppelt sich die Ereignisgröße in der Datenbank praktisch, da Original- und normalisierte Version gespeichert werden. Dies wirkt sich besonders bei Kollektoren mit hohem Volumen aus, die Ereignisse von NetFlow, DNS, Firewalls und anderen Quellen empfangen. Häufig wird die Option zum Testen eines Normalisierers aktiviert, nach Abschluss der Konfiguration aber nicht deaktiviert.

Normalisierungsprobleme führen zu Erkennungsausfällen

Wie beim Fehlen von Quellereignissen führen Normalisierungsfehler zum Ausfall der Erkennungslogik, da diese auf bestimmten Informationen in definierten Ereignisfeldern basiert. Die Prüfer identifizieren mehrere Problemtypen: Der Ereignisfluss wird überhaupt nicht normalisiert, Ereignisse werden nur teilweise normalisiert, der Normalisierer analysiert nur Header und platziert den gesamten Text in einem einzigen Feld, oder es kommt ein veralteter Standard-Normalisierer zum Einsatz.

Die Identifizierung dieser Probleme ist aufgrund des hohen Telemetriedatenvolumens und der Vielzahl von Parsern anspruchsvoll. Die Experten empfehlen zunächst zu prüfen, welche mitgelieferten Normalisierer verwendet werden und ob deren Versionen aktuell sind. Bei den Bewertungen stoßen sie häufig auf auditd-Ereignisse, die mit einem veralteten Normalisierer bearbeitet werden.

Nur 43 Prozent Regelabdeckung

Laut Securelist beträgt die durchschnittliche Abdeckung der Korrelationsregeln für Quellen lediglich 43 Prozent. Zwar ist diese Zahl nur ein Richtwert, da verschiedene Quellentypen unterschiedliche Informationen liefern – die Berechnung basiert jedoch auf der Definition, dass mindestens eine Korrelationsregel pro Quelle vorhanden sein sollte.

Das bedeutet: Für mehr als die Hälfte der angebundenen Quellen führt das SIEM keine aktive Erkennung durch. Gleichzeitig werden Aufwand und Systemressourcen für Anbindung, Wartung und Konfiguration dieser Quellen aufgewendet. In manchen Fällen ist dies formal gerechtfertigt, etwa wenn Protokolle nur für Compliance-Anforderungen benötigt werden – dies stellt jedoch eher die Ausnahme dar.

Die Analysten raten nicht dazu, einfach weniger Quellen anzubinden. Im Gegenteil: Quellen sollten angebunden werden, aber gleichzeitig muss die entsprechende Erkennungslogik entwickelt werden. Andernfalls wird dies vergessen oder verschoben, während die Quelle sinnlos Systemressourcen verbraucht.

Übermäßige Fehlalarme belasten SOC-Teams

Ein Wirksamkeitskriterium für Korrelationsregeln ist eine niedrige Falsch-Positiv-Rate. Die Erkennungslogik kann jedoch eine ungewöhnlich hohe Anzahl von Warnmeldungen generieren, die physisch nicht verarbeitet werden können – unabhängig von der SOC-Teamgröße.

In erster Linie sollte die Erkennungslogik während der Entwicklung getestet und verfeinert werden. Allerdings kann selbst eine gut abgestimmte Korrelationsregel aufgrund von Änderungen im Ereignisfluss oder der Infrastruktur übermäßige Warnmeldungen generieren. Die Lösung kann in der Änderung der Erkennungslogik, dem Hinzufügen von Ausnahmen oder der Anpassung von Ereigniserfassung und Normalisierung bestehen.

Fehlende Threat-Intelligence-Integration

SIEM-Integrationen mit anderen Systemen bilden üblicherweise einen wichtigen Bestandteil der Ereignisverarbeitung und Alarmbereicherung. Besonders die Integration mit Threat-Intelligence-Daten oder Indicators of Compromise wirkt sich direkt auf die Erkennungsleistung aus.

Ein SIEM ermöglicht die Überprüfung von Objekten anhand verschiedener Reputationsdatenbanken oder Blocklisten. Zahlreiche Quellen für diese Daten lassen sich nativ integrieren oder erfordern nur minimalen Aufwand.

Die Verwendung von Threat Intelligence innerhalb eines SIEM kann auf verschiedenen Ebenen implementiert werden: auf Datenquellenebene, auf Ebene der nativen SIEM-Funktionalität oder auf Ebene der Erkennungslogik. In Standardszenarien läuft die Integration letztendlich darauf hinaus, eine Korrelationsregel zu entwickeln, die bei Erkennung einer Übereinstimmung mit bekannten Indicators of Compromise einen Alarm auslöst.

Fehlende Weiterentwicklung nach Bereitstellung

Damit ein SIEM effektiv arbeiten kann, muss es aktuelle Daten über die überwachte Infrastruktur und zu erkennende Bedrohungen enthalten. Beide Elemente verändern sich kontinuierlich: Neue Systeme, Software, Benutzer, Sicherheitsrichtlinien und Prozesse werden in die Infrastruktur eingeführt, während Angreifer neue Techniken und Tools entwickeln.

Ein perfekt konfiguriertes System ist nach fünf Jahren Betrieb ohne zusätzliche Konfiguration nicht mehr in der Lage, die veränderte Infrastruktur oder neue Bedrohungen vollständig zu erkennen. Praktisch alle Komponenten – Ereigniserfassung, Erkennung, zusätzliche Integrationen für Kontextinformationen und Ausschlüsse – müssen gewartet und aktualisiert werden.

Die Experten empfehlen, die ursprüngliche Leistungsbeschreibung oder andere Bereitstellungsunterlagen mit dem aktuellen Systemzustand zu vergleichen. Wenn keine oder nur minimale Änderungen erfolgt sind, weist das SIEM sehr wahrscheinlich Bereiche für Wachstum und Optimierung auf.

Weitere typische Schwachstellen

Laut dem Beitrag von Securelist stoßen die Analysten häufig auf zusätzliche Probleme: Diskrepanzen zwischen Lizenzkapazität und tatsächlicher Auslastung, fehlende Verwaltung der Benutzerrechte innerhalb des Systems, schlechte Organisation anpassbarer Ressourcen mit chaotischen Namenskonventionen, Verwendung von Standardressourcen ohne Anpassung an die Infrastruktur sowie deaktivierte native Integrationen mit externen Systemen wie LDAP, DNS und GeoIP.

Die meisten Effektivitätsprobleme resultieren aus der natürlichen Verschlechterung der innerhalb des Systems implementierten Prozesse. Die Aufrechterhaltung der Wirksamkeit umfasst daher die Strukturierung dieser Prozesse, die Überwachung der Qualität des SIEM-Einsatzes in allen Phasen und die regelmäßige Überprüfung aller Systemkomponenten und Ressourcen.

Fazit: Regelmäßige Überprüfung unerlässlich

Ein SIEM stellt ein leistungsstarkes Werkzeug zur Überwachung und Bedrohungserkennung dar, mit dem Angriffe in verschiedenen Phasen an nahezu jedem Infrastrukturpunkt identifiziert werden können. Bei unsachgemäßer Konfiguration und Bedienung kann es jedoch unwirksam werden und dennoch erhebliche Ressourcen verbrauchen. Die regelmäßige Überprüfung von Komponenten, Einstellungen, Erkennungsregeln und Datenquellen ist daher unerlässlich.

Kaspersky bietet Nutzern der eigenen SIEM-Plattform einen Bewertungsservice an. Nach der Prüfung erstellen die Experten eine Empfehlungsliste zur Behebung identifizierter Probleme. Diese stellen keine verbindlichen Anweisungen dar, sondern Hinweise auf Bereiche, die Aufmerksamkeit und Analyse erfordern, um die Produktleistung zu verbessern, die Genauigkeit der Bedrohungserkennung zu erhöhen und eine effizientere Nutzung zu ermöglichen.