DetectionEngineering.
Detection Engineering behandelt Erkennungslogik wie ein versioniertes technisches Produkt. Anforderungen, Datenquellen, Regeln, Tests, Freigaben, Deployment, Tuning und Stilllegung werden nachvollziehbar verbunden. Eine umfangreiche Regelsammlung ohne Datenprüfung und Testnachweis ist keine Detection-Abdeckung.
Marktdichte: mittel. Zehn Plattformen und offene Ansätze decken Content Lifecycle, Detection as Code und plattformübergreifende Bereitstellung ab.
Von der Hypothese zur getesteten Regel.
Eine Detection braucht Angriffstechnik, erwartete Telemetrie, Logik, Testfall, Owner, Zielplattform und Qualitätsstatus. Änderungen an Parsern oder Quellen können ihre Wirkung brechen, ohne dass sich die Regel selbst verändert.
SIEM und XDR führen Regeln aus. Threat Intelligence liefert Hypothesen. Detection Engineering steuert und prüft den Inhalt über diese Plattformen hinweg. Security Validation bestätigt, ob die erwartete Aktivität tatsächlich erkannt wird.
Lifecycle und Ausführung trennen.
| Plattform | Schwerpunkt | Stärke | Geeignet für | Vor Auswahl prüfen |
|---|---|---|---|---|
| Anvilogic | Detection Engineering Plattform | Entwicklung und Deployment über mehrere Datenplattformen | Multi-SIEM- und Data-Lake-SOCs | Unterstützte Ziele und Regelübersetzung |
| CardinalOps | Detection Posture Management | Coverage, Content und Lückensteuerung | SOCs mit mehreren Detection-Plattformen | Datenquellenprüfung und Deployment-Tiefe |
| SOC Prime | Detection Content Plattform | Breite Regelbibliothek und Plattformübersetzung | Teams mit schnellem Content-Bedarf | Lokale Validierung, Tuning und Lizenzrechte |
| SnapAttack | Detection Engineering und Testing | Verbindung von Angriff, Regel und Test | Purple Teams und Detection Engineers | Zielplattformen und Automatisierungsgrad |
| Panther | Detection as Code | Versionierbare Python-basierte Erkennungen | Cloud-native Engineering-Teams | Programmieraufwand und Plattformbindung |
| Sigma | Offenes Regelformat | Portable Beschreibung von Log-Detections | Herstellerübergreifende Content-Pipelines | Backend-Konvertierung und semantische Unterschiede |
| Microsoft Sentinel | KQL Analytics Rules | Regelbetrieb und Automation im Microsoft-Stack | Sentinel- und Defender-SOCs | Versionskontrolle, Testdaten und Abhängigkeiten |
| Google SecOps YARA-L | Cloud Detection Engine | Regeln auf normalisierter, grosser Telemetrie | Google SecOps Umgebungen | Parserqualität und Sprachkompetenz |
| Elastic Detection Engine | Offene Detection Engine | Regelverwaltung und APIs im Elastic-Stack | Elastic Security Teams | Content-Pflege und Datenmodell |
| Splunk Enterprise Security | Correlation Search Lifecycle | Reifer Security Content im Splunk-Ökosystem | Grosse Splunk-SOCs | Content-Abhängigkeiten, Tests und Deployment-Prozess |
Eine Detection kontrolliert verändern.
- Regel aus einem dokumentierten Angriffsszenario ableiten.
- Benötigte Felder und Quellen automatisiert prüfen.
- Positiv-, Negativ- und Lasttest versionieren.
- Deployment, Rollback, Tuning und Coverage-Status nachvollziehen.
SIEM und XDR führen Inhalte aus. Threat Intelligence liefert Hypothesen. Security Validation prüft ihre Wirkung.
Security Tool Navigator · Gebiet 09
Im Gebiet Security Operations einordnen.
Diese Werkzeugklasse gehört zum Gebiet Security Operations. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.