Laut dem „State of Open Source“-Bericht von OpenLogic verwenden 96 % der befragten Unternehmen Open-Source-Lösungen (OSS). Solche Lösungen sind in allen Segmenten des IT-Marktes zu finden – auch in Infosec-Tools. Und sie werden oft für den Aufbau von SIEM-Systemen empfohlen.
Auf den ersten Blick scheint OSS eine gute Wahl zu sein. Die Hauptfunktion eines SIEM-Systems besteht in der systematischen Erfassung und Korrelation von Telemetriedaten, die du mithilfe bekannter Tools zur Datenspeicherung und -verarbeitung einrichten kannst. Erfasse einfach alle deine Daten mit Logstash, schließe Elasticsearch an, erstelle die benötigten Visualisierungen in Kibana – und schon kannst du loslegen! Nach einer kurzen Suche erhältst du sogar fertige Open-Source-SIEM-Lösungen (die oft auf denselben Komponenten basieren). Bei SIEMs ist es immer von entscheidender Bedeutung, sowohl die Datenerfassung als auch die Datenverarbeitung an die spezifischen Anforderungen deines Unternehmens anzupassen, und ein benutzerdefiniertes OSS-System bietet endlose Möglichkeiten dafür. Außerdem fallen keinerlei Lizenzkosten an. Der Erfolg dieses Unterfangens hängt jedoch von deinem Entwicklungsteam ab, von den Besonderheiten deines Unternehmens, davon, wie lange dein Unternehmen bereit ist, auf Ergebnisse zu warten, und wie viel es bereit ist, in den fortlaufenden Support zu investieren.
Zeit ist Geld
Eine Schlüsselfrage, deren Bedeutung immer wieder unterschätzt wird, ist, wie lange es dauert, bis das SIEM deines Unternehmens nicht nur live geht, sondern auch tatsächlich einen echten einheitlichen Mehrwert liefert. Daten von Gartner zeigen, dass selbst ein fertiges SIEM mit vollem Funktionsumfang durchschnittlich sechs Monate dauert, bis es vollständig implementiert ist – jedes zehnte Unternehmen wendet ein Jahr dafür auf. Und wenn du dein eigenes SIEM erstellst oder ein OSS anpasst, solltest du damit rechnen, dass sich diese Zeitleiste verdoppelt oder verdreifacht. Multipliziere diese Zeit bei der Budgetierung mit den Stundensätzen deiner Entwickler. Es ist auch schwer vorstellbar, dass ein vollwertiges SIEM von einem einzelnen talentierten Individuum stammt – dein Unternehmen muss ein ganzes Team unterhalten.
Der erste Fehler besteht häufig darin, sich daran zu orientierten, wie schnell sich ein Prototyp erstellen lässt. Du kannst ein vorgefertigtes OSS in wenigen Tagen in einer Testumgebung bereitstellen, aber es kann viele Monate – sogar Jahre – dauern, es auf Produktionsqualität zu bringen.
Fachkräftemangel
Ein SIEM muss Tausende von Ereignissen pro Sekunde sammeln, indizieren und analysieren. Der Entwurf eines hoch belasteten Systems oder sogar die Anpassung eines bestehenden Systems erfordert spezielle und gefragte Fähigkeiten. Neben den Entwicklern bräuchte das Projekt hochqualifizierte IT-Administratoren, DevOps-Ingenieure, Analysten und sogar Dashboard-Designer.
Ein weiteres Problem, das SIEM-Entwickler überwinden müssen, ist der Mangel an praktischer Erfahrung, die erforderlich ist, um effektive Normalisierungsregeln, Korrelationslogiken und andere Inhalte zu schreiben, die in kommerziellen SIEM Lösungen bereits enthalten sind. Natürlich sind auch für diese Standardinhalte erhebliche Anpassungen erforderlich, aber die Anpassung an die Standards deines Unternehmens geht schneller und einfacher.
Compliance
Für viele Unternehmen ist der Besitz eines SIEM-Systems gesetzlich vorgeschrieben. Wer ein SIEM selbst entwickelt oder eine OSS-Lösung implementiert, muss erhebliche Anstrengungen unternehmen, um Compliance zu erreichen. Du musst die Fähigkeiten deines SIEM selbst an die gesetzlichen Anforderungen anpassen – im Gegensatz zu den Benutzern kommerzieller Systeme, die oft über einen integrierten Zertifizierungsprozess und alle für die Compliance erforderlichen Tools verfügen.
Manchmal möchte das Management ein SIEM möglichst kostengünstig implementieren, um die Sache vor allem „abzuhaken“. Da sich PCI DSS, DSGVO und andere lokale Regulierungsrahmen jedoch auf die tatsächliche Breite und Tiefe der SIEM-Implementierung konzentrieren – und nicht nur auf ihre bloße Existenz –, würde ein SIEM-System, das ausschließlich zu Show-Zwecken implementiert wird, keiner Prüfung standhalten.
Compliance ist nicht etwas, das du nur zum Zeitpunkt der Implementierung berücksichtigen kannst. Wenn Komponenten deiner Lösung im Rahmen der intern durchgeführten Wartung und des Betriebs nicht mehr aktualisiert werden und das Ende der Lebensdauer erreicht ist, sinken deine Chancen, eine Sicherheitsüberprüfung zu bestehen.
Herstellerbindung vs. Mitarbeiterabhängigkeit
Der zweitwichtigste Grund für Unternehmen, eine Open-Source-Lösung in Betracht zu ziehen, war schon immer die Flexibilität bei der Anpassung an ihre spezifischen Anforderungen sowie die Hoffnung, sich nicht auf die Entwicklungs-Roadmap und die Lizenzierungsvorgaben eines Softwareherstellers verlassen zu müssen.
Beides sind überzeugende Argumente, und können in großen Unternehmen manchmal schwerer wiegen als andere Faktoren. Es ist jedoch von entscheidender Bedeutung, dass du dir bei dieser Wahl der Vor- und Nachteile bewusst bist:
- OSS-SIEMs können einfacher an spezielle Dateneingaben angepasst werden.
- Mit einem OSS-SIEM behältst du die vollständige Kontrolle darüber, wie Daten gespeichert und verarbeitet werden.
- Die Kosten für die Skalierung eines OSS-SIEM ergeben sich hauptsächlich aus dem Preis für zusätzliche Hardware und die Entwicklung der erforderlichen einheitlichen Funktionen.
- Sowohl die anfängliche Einrichtung als auch die fortlaufende Weiterentwicklung eines OSS-SIEM erfordern erfahrene Experten, die sowohl mit den Entwicklungspraktiken als auch mit der SOC-Realität vertraut sind. Wenn die Teammitglieder, die das System am besten kennen, das Unternehmen verlassen oder die Rolle wechseln, kann die Entwicklung des Systems zum Stillstand kommen. Was noch schlimmer ist, es funktioniert allmählich immer weniger.
- Auch wenn die Vorab-Implementierungskosten eines OSS-SIEM niedriger sein können, da keine Lizenzgebühren anfallen, wird dieser Unterschied oft während der Wartungsphase ausgehebelt. Dies ist auf den kontinuierlichen, zusätzlichen Aufwand für qualifiziertes Personal zurückzuführen, das sich ausschließlich der SIEM-Entwicklung widmet. Auf lange Sicht sind die Gesamtbetriebskosten (TCO) für ein OSS-SIEM oft höher.
Qualität der Inhalte
Die Relevanz der Detection and Response-Inhalte ist ein Schlüsselfaktor für die Effektivität eines SIEM. Bei kommerziellen Lösungen werden Updates für Korrelationsregeln, Playbooks und Threat Intelligence-Feeds normalerweise im Rahmen eines Abonnements bereitgestellt. Sie werden von großen Forscherteams entwickelt, sind gründlich getestet und können im Allgemeinen mit minimalem Aufwand von deinem internen Sicherheitsteam implementiert werden. Mit einem OSS-SIEM bist du in Bezug auf Updates auf dich allein gestellt: Du musst Community-Foren, GitHub-Repositorys und kostenlose Feeds selbst durchsuchen. Die Regeln müssen anschließend detailliert geprüft und an deine spezifische Infrastruktur angepasst werden, und das Risiko von Fehlalarmen ist höher. Infolgedessen erfordert die Implementierung von Updates in einem Open-Source-SIEM einen erheblich höheren Aufwand von deinem internen Team.
Der Elefant im Raum: Hardware
Um ein SIEM zu starten, musst du Hardware erwerben oder leasen, und diese Kosten können je nach Systemarchitektur stark variieren. Dabei spielt es keine große Rolle, ob es sich bei dem System um eine Open-Source- oder eine proprietäre kommerzielle Lösung handelt. Wenn du jedoch selbst ein Open-Source-SIEM implementierst, besteht ein größeres Risiko, suboptimale Architekturentscheidungen zu treffen. Auf lange Sicht führt dies zu anhaltend hohen Betriebskosten.
Das Thema Bewertung der Anforderungen an die SIEM-Hardware wird in einem separaten Beitrag ausführlich behandelt.
Schlussfolgerung
Die Idee einer vollständig anpassbaren und anpassungsfähigen Plattform ohne Lizenzgebühren ist zwar sehr reizvoll, es besteht jedoch ein erhebliches Risiko, dass ein solches Projekt dein Entwicklungsteam viel mehr Zeit und Mühe kostet als eine kommerzielle Lösung von der Stange. Eine solche Lösung kann auch deine Fähigkeit beeinträchtigen, neue Innovationen schnell zu übernehmen, und den Fokus deines Sicherheitsteams von der Entwicklung von Erkennungslogiken und Reaktionsszenarien auf die Behandlung hauptsächlich operativer Probleme verlagern. Aus diesem Grund entspricht eine verwaltete, von Experten unterstützte und gut integrierte kommerzielle Lösung oft eher den typischen Unternehmenszielen der effektiven Risikominderung und vorhersehbaren Budgetierung.
Kommerzielle SIEMs ermöglichen es deinem Team, vorgefertigte Regeln, Playbooks und Telemetrie-Parser zu nutzen, sodass es sich auf unternehmensspezifische Projekte konzentrieren kann – z. B. auf Threat Hunting oder die Verbesserung der Transparenz in der Cloud-Infrastruktur – anstatt grundlegende SIEM Funktionen neu zu erfinden und zu verfeinern oder sich abzumühen, um gesetzlich vorgeschriebene Prüfungen mit einem selbst entwickelten System zu bestehen.