Die Erkennung testen: Negativkontrollen statt grüner Dashboards
Das Dashboard zeigt frische Daten, aber eine geänderte Ergebniskennung lässt die Anmelderegel unbemerkt leer laufen.
Der Prüfauftrag
Für einen eigenen SIEM-Erkennungsfall mit dokumentierter Logquelle, Regel und Bearbeitungsweg. Richtwert: 90 Minuten bei vorhandenen Testdaten; längere Regelintervalle und Datenlatenzen zusätzlich. Replay-Tests und echte Ereignisketten getrennt ausweisen.
Am Ende hast du:Ein Erkennungsfall hat überprüfte Treffer und Nichttreffer sowie belegte Grenzen von Datenerfassung, Alarmierung und Bearbeitung.
Beweisen statt vermuten.
Im isolierten Testarbeitsbereich ein freigegebenes synthetisches Ereignispaar für die Kopie einer Regel 'fehlgeschlagene Anmeldung des Testkontos' auswerten. Bei getrennten Test-IDs unterscheidet sich fachlich nur das Ergebnis: einmal fehlgeschlagen, einmal erfolgreich. Bestehen: Beide Ereignisse sind eingegangen, genau der Fehlerfall trifft und der Erfolgsfall nicht. Regelversion, Zeitfenster und Ausnahmen mit sichern; dieses Replay belegt nicht die echte Sensorstrecke.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Eine falsifizierbare Erkennungshypothese festlegen: Ereignis, Identität, Ergebnis, Zeitfenster und erwartete Alarmentscheidung.
So belegst du es: Regelsteckbrief mit mindestens einem erwarteten Treffer und einem möglichst ähnlichen Nichttreffer.
Nachweis und nächsten Schritt notieren
Pflichtfelder vom Quellereignis bis zur normalisierten Tabelle prüfen; fehlende oder falsch typisierte Werte sichtbar machen.
So belegst du es: Verknüpfte Roh- und Normalereignisse mit Zeit, Ergebnis, stabiler Identitäts-ID und Testkennzeichen.
Nachweis und nächsten Schritt notieren
Lookback, Ausführungsintervall und reale Ingestionsverzögerung gemeinsam gegen verpasste oder doppelte Ereignisse prüfen.
So belegst du es: Zeitdiagramm und belegter Test am Zeitfensterrand; verspätete Daten ausdrücklich berücksichtigt.
Nachweis und nächsten Schritt notieren
Eine harmlose Positivkontrolle über die echte Quelle erzeugen und bis zur zuständigen Bearbeitung verfolgen.
So belegst du es: Zusammenhängende IDs und Zeitpunkte für Ereignis, Eingang, Regelmatch, Alarm, Routing und Annahme.
Nachweis und nächsten Schritt notieren
Eine Negativkontrolle mit genau einer geänderten entscheidenden Eigenschaft auswerten; erwartete Nichttreffer vom Ausfall der Pipeline unterscheiden.
So belegst du es: Versionierte Testpaare, Soll-Ist-Entscheidung und nachgewiesener Eingang beider Testereignisse.
Nachweis und nächsten Schritt notieren
Ausnahmen, Unterdrückung, Schwellwerte und Incident-Gruppierung auf verdeckte Treffer und unnötige Mehrfachalarme prüfen.
So belegst du es: Regel- und Ausnahmestand sowie getrennte Nachweise für Match, Alert und angelegten beziehungsweise zugeordneten Incident.
Nachweis und nächsten Schritt notieren
Ausfall einer dedizierten Testquelle sowie deaktivierte oder fehlerhafte Testregeln als Betriebsfehler erkennbar machen.
So belegst du es: Gesonderter Health-Alarm mit Besitzer und Frist; ausbleibende Sicherheitsalarme werden nicht als Entwarnung gewertet.
Nachweis und nächsten Schritt notieren
Die getestete Regelversion, Parser, Daten und Grenzen sichern und bei relevanten Änderungen erneut prüfen.
So belegst du es: Reproduzierbarer Testbericht mit bekannten Blindstellen und ohne Zugangsdaten oder unnötige personenbezogene Inhalte.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
Ein Query-Treffer ist noch kein zugestellter Alarm; ein Alarm ist noch kein bearbeiteter Incident. Synthetisch eingespielte Daten prüfen die vorgelagerten Sensoren nicht. Ein gesunder Connector beweist keine korrekte Regel. Erwartete Nichttreffer sind nur aussagekräftig, wenn die Testdaten nachweislich angekommen und vom geprüften Lauf erfasst worden sind.
OWASP: Logging Cheat Sheet — Verification ↗Microsoft Learn: Scheduled analytics rules ↗Microsoft Learn: Monitor analytics rule health and integrity ↗Microsoft Learn: Enable Sentinel auditing and health monitoring ↗CISA und Partner: Best practices for event logging and threat detection ↗Prüfbericht / Selbsteinschätzung
Die Erkennung testen: Negativkontrollen statt grüner Dashboards · v2026.11 · 10.11.2026 ·
0/8 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Eine falsifizierbare Erkennungshypothese festlegen: Ereignis, Identität, Ergebnis, Zeitfenster und erwartete Alarmentscheidung.
Status: Offen
Erwarteter Nachweis: Regelsteckbrief mit mindestens einem erwarteten Treffer und einem möglichst ähnlichen Nichttreffer.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Pflichtfelder vom Quellereignis bis zur normalisierten Tabelle prüfen; fehlende oder falsch typisierte Werte sichtbar machen.
Status: Offen
Erwarteter Nachweis: Verknüpfte Roh- und Normalereignisse mit Zeit, Ergebnis, stabiler Identitäts-ID und Testkennzeichen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Lookback, Ausführungsintervall und reale Ingestionsverzögerung gemeinsam gegen verpasste oder doppelte Ereignisse prüfen.
Status: Offen
Erwarteter Nachweis: Zeitdiagramm und belegter Test am Zeitfensterrand; verspätete Daten ausdrücklich berücksichtigt.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Eine harmlose Positivkontrolle über die echte Quelle erzeugen und bis zur zuständigen Bearbeitung verfolgen.
Status: Offen
Erwarteter Nachweis: Zusammenhängende IDs und Zeitpunkte für Ereignis, Eingang, Regelmatch, Alarm, Routing und Annahme.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Eine Negativkontrolle mit genau einer geänderten entscheidenden Eigenschaft auswerten; erwartete Nichttreffer vom Ausfall der Pipeline unterscheiden.
Status: Offen
Erwarteter Nachweis: Versionierte Testpaare, Soll-Ist-Entscheidung und nachgewiesener Eingang beider Testereignisse.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Ausnahmen, Unterdrückung, Schwellwerte und Incident-Gruppierung auf verdeckte Treffer und unnötige Mehrfachalarme prüfen.
Status: Offen
Erwarteter Nachweis: Regel- und Ausnahmestand sowie getrennte Nachweise für Match, Alert und angelegten beziehungsweise zugeordneten Incident.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Ausfall einer dedizierten Testquelle sowie deaktivierte oder fehlerhafte Testregeln als Betriebsfehler erkennbar machen.
Status: Offen
Erwarteter Nachweis: Gesonderter Health-Alarm mit Besitzer und Frist; ausbleibende Sicherheitsalarme werden nicht als Entwarnung gewertet.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Die getestete Regelversion, Parser, Daten und Grenzen sichern und bei relevanten Änderungen erneut prüfen.
Status: Offen
Erwarteter Nachweis: Reproduzierbarer Testbericht mit bekannten Blindstellen und ohne Zugangsdaten oder unnötige personenbezogene Inhalte.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
Ein Query-Treffer ist noch kein zugestellter Alarm; ein Alarm ist noch kein bearbeiteter Incident. Synthetisch eingespielte Daten prüfen die vorgelagerten Sensoren nicht. Ein gesunder Connector beweist keine korrekte Regel. Erwartete Nichttreffer sind nur aussagekräftig, wenn die Testdaten nachweislich angekommen und vom geprüften Lauf erfasst worden sind.