SIEM-Beratung: Angriffe erkennen statt Logs sammeln
Ein SIEM erkennt nur, was Sie ihm beibringen. Viele Installationen speichern teuer Daten, ohne dass jemand die richtigen Fragen daran stellt. Wir helfen bei Strategie, Tool-Auswahl, Log-Quellen, Use Cases und dem Betriebsmodell, damit aus Datenvolumen Erkennung wird.
- Use Cases bestimmen, was das SIEM überhaupt erkennt
- Ingest + Retention die zwei Kostentreiber jedes SIEM
- MTTD / MTTR Kennzahlen für Erkennung und Reaktion
- 3 Modelle eigenes SOC, Managed SOC/MDR oder Hybrid
Was ein SIEM leistet, und was nicht
Security Information and Event Management: Logs aus vielen Quellen sammeln, normalisieren, korrelieren und bei definierten Mustern alarmieren. Der Rest ist Menschen- und Prozessarbeit.
- Sammeln
Log-Quellen anbinden
Firewalls, Identitätsdienste, Endpunkte, Server, Cloud-Plattformen, Anwendungen. Jede Quelle kostet Volumen und Pflege. Nicht jede Quelle liefert Erkennungswert, aber jede erhöht die Rechnung.
- Korrelieren
Muster über Quellen hinweg erkennen
Der Mehrwert gegenüber Einzel-Logs: ein fehlgeschlagener Login, danach ein erfolgreicher von einer neuen IP, danach eine Rechteänderung. Erst die Verkettung macht daraus einen Alarm.
- Alarmieren
Use Cases als Regelwerk
Erkennung basiert auf Use Cases: definierte Regeln und Analysen, was verdächtig ist und wie darauf reagiert wird. Ohne gepflegte Use Cases bleibt das SIEM ein teurer Log-Speicher.
Vertiefung Use-Case-Entwicklung: Wie Use Cases strukturiert, an MITRE ATT&CK ausgerichtet und getestet werden, beschreiben wir ausführlich auf unserem Schwesterportal siem-use-cases.de.
Eigenes SOC, Managed SOC oder Hybrid?
Die Technik ist der kleinere Teil. Ein SIEM braucht Menschen, die rund um die Uhr Alarme bewerten, Regeln pflegen und im Vorfall handeln. Drei Wege, das zu organisieren.
| Modell | Geeignet wenn | Vorteile | Zu beachten |
|---|---|---|---|
| Eigenes SOC | Ausreichend Personal für Schichtbetrieb, hohe Regulierung, eigene Sicherheitsstrategie und viel eigene Anwendungslandschaft. | Volle Kontrolle über Daten, Regeln und Priorisierung. Wissen über die eigene Umgebung bleibt im Haus. | Personalaufbau und -bindung, Betriebskosten rund um die Uhr, Aufbauzeit. Für die meisten mittelständischen Unternehmen schwer zu halten. |
| Managed SOC / MDR | Kein eigenes Sicherheitsteam im Schichtbetrieb, Bedarf an schneller Wirksamkeit, Fokus auf Kerngeschäft. | Erkennung und erste Reaktion ab Vertragsbeginn, Skaleneffekte des Anbieters, planbare Kosten. | Vertragliche Regelung von Reaktionszeiten, Zuständigkeiten im Vorfall, Datenhaltung und Ausstieg. Wissen über Ihre Umgebung muss aktiv übergeben werden. |
| Hybrid | Kleines internes Team vorhanden, das Steuerung und Kontext übernimmt, aber keinen 24/7-Betrieb leisten kann. | Interne Hoheit über Strategie und Use Cases, externe Abdeckung außerhalb der Bürozeiten und bei Spitzen. | Klare Schnittstellen und Eskalationswege zwischen intern und extern, sonst fallen Alarme zwischen zwei Stühle. |
In vier Schritten zu einer Erkennung, die zu Ihnen passt
Erst die Frage, was erkannt werden soll, dann die Daten, dann das Werkzeug. In dieser Reihenfolge, nicht umgekehrt.
-
Strategie und Anforderungen
Welche Angriffe und Fehler müssen Sie erkennen, welche Vorgaben gelten (NIS2, ISO 27001, Kundenverträge, Versicherer), wer reagiert im Vorfall? Ergebnis: Erkennungsziele, Betriebsmodell-Empfehlung und ein Budgetrahmen, den die Geschäftsleitung tragen kann.
-
Log-Quellen priorisieren
Aus den Erkennungszielen leiten wir ab, welche Quellen wirklich gebraucht werden, mit welcher Detailtiefe und wie lange. Daten für Forensik landen in günstigen Speicherstufen, nicht im teuren Analysebereich. Das ist der größte Hebel für die Kosten.
- Identitätsdienste und Endpunkte liefern meist den höchsten Erkennungswert
- Volumenschätzung je Quelle vor der Anbindung, nicht nach der ersten Rechnung
-
Tool-Auswahl und Anbieterauswahl
Wir bewerten Plattformen wie Microsoft Sentinel, Splunk, Elastic Security, IBM QRadar oder Wazuh anhand Ihrer Kriterien: Lizenzmodell, Integration in Ihre Landschaft, Betriebsaufwand, Skalierbarkeit. Bei Managed-Modellen zusätzlich Anbieter, Vertrag und Schnittstellen.
-
Use Cases, Betrieb, Kennzahlen
Ausgehend von den priorisierten Bedrohungen entstehen Use Cases mit Erkennungslogik, Reaktionsablauf und Zuordnung zu MITRE ATT&CK. Dazu ein Betriebskonzept mit Rollen, Tuning-Routine für False Positives und Kennzahlen (MTTD, MTTR, Abdeckung), die regelmäßig berichtet werden.
Kennzahlen und Nachweise
Ob ein SIEM wirkt, lässt sich messen. Diese Größen gehören in den regelmäßigen Bericht an die Geschäftsleitung, und sie sind gleichzeitig Nachweise gegenüber Aufsicht und Auditoren.
- MTTD
Zeit bis zur Erkennung
Wie lange vergeht zwischen Beginn eines Angriffs oder einer Fehlfunktion und dem Alarm? Gemessen an realen Vorfällen und an regelmäßigen Tests mit simulierten Angriffen.
- MTTR
Zeit bis zur Reaktion
Wie lange dauert es vom Alarm bis zur Eindämmung? Hier entscheidet sich, ob das Betriebsmodell funktioniert: Erreichbarkeit, Entscheidungsbefugnis, eingeübte Abläufe.
- MITRE ATT&CK
Abdeckung der Angriffstechniken
Welche der für Sie relevanten Techniken sind durch Use Cases abgedeckt, welche nicht? Die Matrix macht Lücken sichtbar und ist eine verständliche Grundlage für Priorisierung und Budget.
- False Positives
Qualität der Alarme
Ein hoher Anteil an Fehlalarmen ermüdet Analysten und lässt echte Vorfälle untergehen. Die Rate gehört in jeden Bericht, das Tuning der Regeln in jeden Betriebsplan.
- NIS2, § 30 BSIG
Bewältigung von Vorfällen und Wirksamkeit
Das NIS2-Umsetzungsgesetz verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen und zur Bewertung der Wirksamkeit. Alarmprotokolle, Reaktionsnachweise und Kennzahlenberichte aus dem SIEM-Betrieb belegen beides.
- Kritische Anlagen
Systeme zur Angriffserkennung
Betreiber kritischer Anlagen sind verpflichtet, Systeme zur Angriffserkennung einzusetzen. Ein SIEM mit dokumentierten Use Cases, Betriebskonzept und regelmäßiger Überprüfung ist der übliche Weg, diese Pflicht zu erfüllen und nachzuweisen.
Erkennt Ihr SIEM, was es erkennen soll?
Wenn Sie mehrere dieser Punkte nicht mit Ja beantworten können, verdient das SIEM eher eine Überprüfung als einen Ausbau.
- Wir haben schriftlich festgelegt, welche Angriffe und Fehler das SIEM erkennen soll.
- Jede angebundene Log-Quelle ist mindestens einem Use Case zugeordnet.
- Wir kennen unser tägliches Ingest-Volumen und wissen, welche Quellen es treiben.
- Aufbewahrungsfristen sind je Datenart festgelegt und nach Speicherstufen getrennt.
- Es ist geregelt, wer einen Alarm auch nachts und am Wochenende bewertet und wer entscheiden darf.
- Wir testen regelmäßig, ob definierte Angriffe tatsächlich einen Alarm auslösen.
- MTTD, MTTR und False-Positive-Rate werden erhoben und an die Geschäftsleitung berichtet.
- Die Abdeckung der relevanten MITRE-ATT&CK-Techniken ist dokumentiert und wird jährlich überprüft.
Beratung für IT-Sicherheit und Compliance aus Eschborn
JAMORIE berät Unternehmen bei Informationssicherheit und Compliance, aus Eschborn bei Frankfurt, mit Erfahrung im Mittelstand. Wir verkaufen keine Lizenzen und keinen SOC-Betrieb, sondern helfen, die richtigen Entscheidungen zu treffen.
-
Herstellerunabhängig
Wir empfehlen die Plattform und das Betriebsmodell, die zu Ihrer Landschaft, Ihrem Personal und Ihrem Budget passen. Keine Partnerprovision entscheidet mit.
-
Kosten von Anfang an im Blick
Wir planen Log-Quellen, Retention und Speicherstufen, bevor die erste Rechnung kommt. Bei bestehenden Installationen finden wir die Quellen, die viel kosten und wenig erkennen.
-
Eingebettet in Compliance
SIEM-Betrieb, Vorfallmanagement und Nachweise für NIS2 und ISO 27001 denken wir zusammen. So wird aus dem Werkzeug ein belegbarer Teil Ihres Sicherheitsmanagements.
SIEM und SOC kurz beantwortet
Brauchen wir überhaupt ein SIEM?
Die ehrliche Antwort lautet: Sie brauchen Angriffserkennung und eine Reaktion darauf. Ob das ein eigenes SIEM ist, ein Managed SOC oder ein MDR-Dienst, hängt von Größe, Regulierung und Personal ab. Ein SIEM ohne Menschen, die Alarme bearbeiten, erzeugt Kosten und Scheinsicherheit. Deshalb beginnen wir bei der Frage nach dem Betriebsmodell, nicht beim Produkt.
Welches SIEM ist das richtige?
Es gibt kein bestes Produkt, nur das passende für Ihre Landschaft. Microsoft Sentinel, Splunk, Elastic Security, IBM QRadar oder Wazuh unterscheiden sich in Lizenzmodell, Integrationstiefe, Betriebsaufwand und Community. Wer stark auf Microsoft 365 und Azure setzt, hat andere Kriterien als ein Unternehmen mit heterogener Infrastruktur oder Open-Source-Strategie. Wir bewerten anhand Ihrer Anforderungen, nicht anhand von Marktanteilen.
Warum werden SIEM-Kosten so oft unterschätzt?
Weil der Kostentreiber das Datenvolumen ist: was täglich eingespeist (Ingest) und wie lange es vorgehalten wird (Retention). Wer alle Logs sammelt, zahlt für Daten, die kein Use Case je auswertet. Die Gegenmaßnahme ist eine priorisierte Liste der Log-Quellen, abgeleitet aus den Erkennungszielen, plus günstigere Speicherstufen für Daten, die nur für Forensik gebraucht werden.
Was ist ein Use Case im SIEM-Kontext?
Ein Use Case beschreibt ein Angriffs- oder Fehlverhalten, das erkannt werden soll, die dafür nötigen Log-Quellen, die Erkennungslogik und die Reaktion darauf. Ohne Use Cases korreliert ein SIEM nichts Sinnvolles. Die Zuordnung zu Techniken aus MITRE ATT&CK macht sichtbar, welche Angriffsphasen abgedeckt sind und wo Lücken bleiben.
Was verlangt NIS2 in Sachen Angriffserkennung?
§ 30 BSIG verlangt von betroffenen Einrichtungen unter anderem Maßnahmen zur Bewältigung von Sicherheitsvorfällen und zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen. Betreiber kritischer Anlagen müssen zusätzlich Systeme zur Angriffserkennung einsetzen. Ein SIEM oder ein MDR-Dienst ist ein üblicher Weg, diese Anforderungen umzusetzen und zu belegen.
Woran messen wir, ob das SIEM etwas bringt?
An wenigen Kennzahlen, die regelmäßig berichtet werden: Zeit bis zur Erkennung (MTTD), Zeit bis zur Reaktion (MTTR), Abdeckung der relevanten MITRE-ATT&CK-Techniken durch Use Cases und die False-Positive-Rate. Dazu regelmäßige Tests, ob definierte Angriffe tatsächlich einen Alarm auslösen. Ein SIEM, das nie einen echten Vorfall meldet, ist entweder sehr gut oder blind.
Sprechen wir über Ihre Angriffserkennung
Im kostenlosen Erstgespräch klären wir Ausgangslage, Erkennungsziele und das passende Betriebsmodell. Ohne Produktbindung, mit konkreten nächsten Schritten.
- Einordnung: eigenes SOC, Managed SOC/MDR oder Hybrid
- Die Log-Quellen mit dem besten Verhältnis von Erkennungswert zu Kosten
- Erste Use Cases und Kennzahlen für den Bericht an die Geschäftsleitung
Danke, wir rufen Sie an.
Sie hören innerhalb eines Werktags von uns, meist deutlich schneller. Wenn Sie lieber gleich einen festen Termin wählen möchten, geht das direkt im Kalender auf jamorie.eu.
Termin selbst wählen