Deshalb scheitern SIEM-Projekte Die Top 10 Fehler bei einem SIEM

Anbieter zum Thema

Securepoint GmbH

WatchGuard Technologies GmbH

XOPERO SOFTWARE S.A.

Ein SIEM-System ist ein wichtiges, wertvolles, aber auch komplexes Security-Ökosystem, das tiefgehendes Wissen über diverse Datenquellen erfordert. Genau deshalb passieren oft auch immer wieder die selben Fehler, die ein SIEM-Projekt scheitern lassen. In diesem Beitrag zeigen wir, wie Sie häufige Fehlerquellen vermeiden und ein erfolgreiches SIEM-Projekt realisieren.

Ein Security Information and Event Management (SIEM) ist immer eine besonders komplexes Ökosystem. Umso mehr müssen die verschiedenen Quellen, deren Inhalt, Syntax und Eigenheiten dem jeweiligen Expertenpersonal intensiv bekannt sein.

Keine SIEM-Lösung ist perfekt. Die zahlreichen zu überwachenden Applikationen und Systeme sind häufig auch eigene Entwicklungen und gerade die erzwingen oft, dass SIEM-Teams in der Lage sind solche Datenströme mit eigenen Decodern zu parsen und mit entsprechenden Regeln zu analysieren, ohne sich auf einen Lösungsanbieter verlassen zu können.

Dieser Umstand und auch ein Fehlen eines umfangreiches Asset-Managements, lassen SIEM-Projekte häufig scheitern. Die meiner Meinung nach Top-10 Fehler bei einem SIEM-Projekt, geben einen Überblick über typische Fallstricke.

1. Fehlendes bzw. unvollständiges Asset-Management bzw. Inventar

Unbekannte Assets lassen sich nicht überwachen. Lückenhafte Informationen sorgen daher schnell dafür, dass wichtige Komponenten übersehen werden. So ist zum Beispiel die Überwachung eines Betriebssystems nicht ausreichend, wenn darauf eine produktive Datenbank betrieben wird und der SIEM-Analyst diese Daten nicht bekommt.

2. Ungenügendes Wissen über Datenquellen

Unabhängig davon, für welches Produkt man sich entschieden hat, wird kein SIEM-System mangelhaftes Wissen über die Datenquellen und wie man diese verarbeitet, kompensieren können. SIEM-Analysten bzw. die Fachteams, müssen bis ins kleinste Detail die Struktur der Quellen kennen, gegeben falls individuell anpassen und ihre Dokumentation stets aktuell halten.

3. Quellenanbindung geschieht unter falschen Vorstellungen

Ein weit verbreiteter Irrglauben von IT-Abteilungen ist es, dass man lediglich einen Agenten installiert und schon wäre die Arbeit getan. In der Realität sind komplexe Lösungen zwingend, um die Menge an Daten auf unterschiedlichste Weise, zuverlässig in ein SIEM zu importieren. Dabei ist es nicht unüblich eine breite Palette an Tools zu benutzen.

Ein SIEM-Team braucht deshalb einen erweiterten Sachverstand zu Themen wie Syslog, JSON, Sysmon-4-Windows, Sysmond-4-Linux, auditD und individuelle Entwicklungen. Um hier nicht in ein Chaos und einhergehend finanzielle Katastrophe abzudriften, sollte man sich einen Plan erstellen, der dann Schritt für Schritt konzentriert, abgearbeitet wird. Eine stete rigorose Optimierung und eigene Anpassungen sind essenziell.

4. Infrastruktur der SIEM-Lösung wurde falsch designt

Umso umfangreicher eine zu analysierte IT-Landschaft ist, desto leistungsstärker muss die SIEM-Architektur erstellt werden. Der Einsatz einer simplen VM oder gar eines Containers, widerspricht dem grundsätzlichen Design eines SIEM-Systems. Stattdessen sind leistungsstarke, bei größeren Setups auch geclusterte Systeme notwendig.

5. Die SIEM-Lösung arbeitet in der Cloud, der Datendurchsatz wurde ignoriert

In typisch mittelständigen Unternehmen und auch Konzernen, werden hunderte bis viele Tausende Assets betrieben. Eine Übertragung in die Cloud, kann mangels einer nicht ausreichend dimensionierten Internetleitung schnell die Effektivität eines SIEM behindern, und auch andere Systeme negativ beeinflussen. Als finanziell ruinös, können sich auch zu hohen Datenmengen darstellen.

6. Missinterpretation über den Einsatz eines SIEM

SIEM-Systeme analysieren Logdateien und Datenströme auf Sicherheitsbezogene Ereignisse, sie ersetzen jedoch kein Logmanagement! Zur Fehlersuche und Fehlerdiagnose, muss der IT-Fachmann weiterhin eigenständig mit den Quellen interagieren.

7. Fehlender Support des Herstellers

Egal wie modern eine SIEM-Software ist, sie ist niemals fehlerfrei, dafür immer anspruchsvoll und vielschichtig. Die Komplexität eines SIEM, fordert auch die kompetentesten SIEM-Teams heraus. Folglich sollte immer der direkte Kontakt zu einem Hersteller über einen zuverlässigen und offiziellen Partner gewährleistet sein.

8. Nicht vorhandene Testumgebung

Wer die Anbindung von neuen Assets, Decodern, Regeln, Alarmierungen und sonstigen Erweiterung nicht vorab an einen, dem Produktiv-System nachempfundenen, Test-System ausgiebig testet, wird früher oder später auf eklatante Fehler stoßen und handelt somit fahrlässig. Die nötige Sicherheitsüberwachung kann ausfallen und auch die Evidenzkraft bei juristischen Auseinandersetzungen kann angezweifelt werden.

In der Praxis hat sich folgendes Schichtmodell etabliert:

Produktiv:

• Keine Änderung ohne Ticket bzw. Nachweise.

• Keine Änderung ohne intensiven Test.

• Änderungen nur von wenigen, hochspezialisierten Kräften.

• Ganzheitlich überwacht.

• Isoliert.

• Ganzheitliche Backups (System, Konfigurationen usw.).

Pre-Produktiv:

• Keine Änderung ohne Ticket bzw. Nachweise.

• Implementierungen haben die Anfangs-Testphase bereits durchlaufen.

• Änderungen nur von wenigen, hochspezialisierten Kräften.

• Hier werden Lastentests und Compliance-Anpassungen vervollständigt (z.B.: Regeln die einer MITRE-Nummer oder ISO 27001 Maßnahme zugeordnet werden)

• Beobachtungen von sonstigen Anomalien über einen exakt definierten Zeitraum.

• Ganzheitlich überwacht.

• Einfache Backups.

Test:

• Aktive Testumgebung für die SIEM-Experten.

• Umgebung kann kleiner ausfallen.

• Decoder, Regeln und Scripting werden hier isoliert entwickelt.

• Testung der Wirkungsweise der erstellten Implementierungen.

• Funktionale Überwachung.

• Einfache Backups, ohne hohe Kritikalität.

Alle Test-Fälle sollten genau dokumentiert werden, reproduzierbar und allen Fachpersonal bekannt sein.

9. Zu wenig Zeit für das Projekt

Kunden und/oder Teams, die keine ausreichende Zeit zur Verfügung haben, das Asset-Management zu vervollständigen, sich mit den verschiedenen Technologien auseinander zu setzen und/oder keine Lust haben, die Thematiken zu erlernen, sind immer als K.-O.-Kriterium anzusehen. Nur mit Planung, Geduld und Fachwissen aus der Praxis, ist ein SIEM zu realisieren.

Merke: Ein SIEM ist ein Öko-System, kein „klick-klick-fertig“ Tool!

10. Unnötig große Dienstleister-Teams

In der Regel, benötigt man die Hilfe von zertifizierten Dienstleistern, welche offizielle Partner einer SIEM-Lösung sind. Allerdings sollte man die Auswahl nicht an deren Größe festmachen, sondern vielmehr an der Praxiserfahrung bei der Überwachung von verschiedenen Assets und der Verwendung eines SIEM.

Es nützt nichts, wenn ein Dienstleister sein SIEM-Produkt gut kennt, aber keine nennenswerte Praxiserfahrung über die gängigen zu überwachenden Assets verfügt.

Weiter hilft es nicht, wenn ein Dienstleister eine schnelle Finalisierung eines SIEM-Projektes bewirbt, die Effizienz des SIEM-System jedoch nicht ausreichend ist und viel wichtiger, das Team des Kunden nicht ausreichend geschult wurde.

Ein kleines externes Team, welches mit Geduld und echten Fachwissen (Technik und Compliance aus einer Hand) das IT-Team seines Kunden Schritt für Schritt unterrichtet und gemeinsam das SIEM-Projekt zu Ende bringt, ist die bessere Variante.

Zu schnell „fertig gestellte“ SIEM-Projekte, tendieren eine falsche Sicherheit vorzugaukeln.

Über den Autor: Stephan H. Wenderlich ist Inhaber von „Gray-Hat IT-Security Consulting Stephan H. Wenderlich“. Als passionierter Informatiker liegt seine Expertise bei Informations­sicherheit nach ISO/IEC 27001:2022 und den CIS Criticial Security Controls, sowie allgemeiner, ganzheitlicher IT-Sicherheit.

(ID:50048505)