Detection Engineering erklärt

Detection Engineering ist für viele Unternehmen inzwischen gesetzt. Lesen Sie, warum.Gorodenkoff | shutterstock.com



Detection Engineering war einst ein Nischenbereich, der vor allem für Großunternehmen relevant war. Inzwischen wird die Methodologie allerdings in diversen Branchen als unverzichtbar für den Security-Betrieb angesehen.



In diesem Beitrag erfahren Sie:




was Detection Engineering ist,



wie es sich von Threat Detection unterscheidet,



welche Aspekte die Adoption treiben,



welche Voraussetzungen dabei erfüllt sein sollten, und



welche Rolle KI und Automatisierung dabei spielen können.




Was ist Detection Engineering?



Beim Detection Engineering geht es darum, Systeme zu entwickeln und zu implementieren, mit denen potenzielle Sicherheitsbedrohungen innerhalb der spezifischen Technologieumgebung eines Unternehmens identifiziert werden können – ohne dabei in einer Flut von Fehlalarmen unterzugehen. Dazu werden intelligente Regeln erstellt, um potenziell verdächtige oder schadhafte Vorgänge in den Netzwerken oder Systemen eines Unternehmens zu identifizieren und entsprechend aussagekräftige Warnmeldungen darüber zu generieren.



Der Detection-Engineering-Prozess umfasst in der Regel:




Bedrohungen zu modellieren,



die TTPs der Angreifer zu analysieren,



Detection-Regeln zu schreiben, zu testen und zu validieren, sowie



sich an neue Bedrohungen oder Angriffstechniken anzupassen.




Laut dem vom SANS Institute und Anvilogic veröffentlichten „State of Detection Engineering Report 2026“ (Download gegen Daten) investieren 80 Prozent der befragten Organisationen (und 85 Prozent der Großunternehmen) inzwischen aktiv in Detection Engineering. Von diesen verfügen mittlerweile 60 Prozent über eigene, dedizierte Teams in diesem Bereich. Und: 67 Prozent der Befragten geben an, dass Detection Engineering ausgeprägten Support durch das Management genießt.



Die Ergebnisse des Reports deuten darauf hin, dass viele Unternehmen Detection-Engineering-Praktiken nicht nur eingeführt, sondern zu einem strategischen Fokuspunkt ihrer Cybersecurity-Bemühungen gemacht haben. Oder, wie die Studienautoren es ausdrücken: „Noch vor einem Jahrzehnt war Detection Engineering relativ unbekannt. Heute ist es essenziell für die Security Operations.“



Der Report beschreibt zudem, wie sich die Detection-Engineering-Praktiken im Laufe der letzten Jahre weiterentwickelt haben. Waren diese zunächst übermäßig abhängig von herstellerspezifischen Konsolen und proprietären Sprachen, hielten dann nach und nach Softwareentwicklungsprinzipien wie CI/CD Einzug.



Detection Engineering vs. Threat Detection



Laut den Verfechtern des Ansatzes unterscheidet sich Detection Engineering wesentlich von herkömmlicher Threat Detection – mit Blick auf Ansatz, Methodik und die Integration in den Development Lifecycle:




So sind traditionelle Threat-Detection-Prozesse in der Regel reaktiv und stützen sich auf vordefinierte Regeln und Anbietersignaturen – die Anpassungsmöglichkeiten für die Anwender sind limitiert.



Im Gegensatz dazu kommen beim Detection Engineering Prinzipien der Softwareentwicklung zum Einsatz, um eine benutzerdefinierte Detection-Logik für eine spezifische Unternehmensumgebung und ihre Bedrohungslandschaft zu erstellen und zu pflegen. Das Ziel besteht darin, maßgeschneiderte Mechanismen zu entwickeln, um unternehmensspezifische Bedrohungen erkennen zu können.




Deshalb geht Detection Engineering oft mit einem stärkeren Fokus auf verhaltensbasierte Erkennungsmethoden einher, wie Heath Renfrow, CISO und Mitbegründer des Cyber-Recovery-Anbieters Fenix24, erklärt: „Detection Engineering ist verhaltensgesteuert, kontextsensitiv und auf die einzigartige Bedrohungslandschaft eines einzelnen Unternehmens zugeschnitten. Es ist ein Mix aus Security Operations, Threat Intelligence und Data Science.“



Warum Detection Engineering eingeführt wird



Die Einführung von Detection Engineering wird von einer ganzen Reihe von Faktoren vorangetrieben. Der wichtigste ist die Tatsache, dass Standard-Detection-Mechanismen nicht ausreichen: „Diese erfassen keine Baseline für die Umgebung, reduzieren die Anzahl der Fehlalarme nicht und – was besonders beunruhigend ist – warnen nicht immer vor den wirklich wichtigen Ereignissen“, konstatiert Johnathon Miller, Vice President of Security Operations beim Plattformanbieter Lumifi Cyber.



Generische Warnmeldungen, die den organisatorischen Kontext nicht berücksichtigen, haben sich vielerorts zum Problem entwickelt und fördern die „False Positive Fatigue“ – wie auch die vorab zitierte Studie belegt:




64 Prozent der Befragten geben an, unter hohen Fehlalarmraten zu leiden,



61 Prozent haben mit unpräzisen Detection-Mechanismen zu kämpfen, und



34 Prozent berichten von zeitlich verzögerten Updates und Optimierungen.




„Herkömmliche Methoden zur Bedrohungserkennung waren in der Vergangenheit statisch: Wenn a gleich a ist, wird eine Warnmeldung ausgelöst“, erklärt Kevin Gonzalez, Vice President of Security, Operations and Data bei Anvilogic. Laut dem Experten handle es sich oft um starre Black-Box-Mechanismen, denen es an Flexibilität bei der Anpassung mangele. Diese Ansätze seien laut Gonzalez zwar bis zu einem gewissen Grad nützlich, würden im Zuge einer Skalierung aber unüberschaubar – insbesondere bei hybriden Umgebungen.



Ein weiteres Problem ist das wachsende Ausmaß und die zunehmende Raffinesse der Sicherheitsbedrohungen. Angreifer setzen immer ausgefeiltere und schwerer zu erkennende Techniken ein – darunter Fileless Malware, Zero-Day-Exploits sowie „Living off the Land“- und Supply-Chain-Attacken. Die zunehmende Nutzung der Cloud hat darüber hinaus neue Schwachstellen eröffnet und blinde Flecken geschaffen, die mit herkömmlichen Detection-Methoden oft nur schwer abzudecken sind.



„Unternehmen erkennen mittlerweile, dass proaktive Erkennungstechniken die Verweildauer der Angreifer verkürzen, die Reaktionsfähigkeit verbessern und die allgemeine Cyberresilienz stärken. Zudem legen Compliance-Frameworks und auch Cyberversicherer zunehmend gesteigerten Wert auf robuste Detection-Strategien“, meint Sicherheitsentscheider Renfrow.



Detection Engineering – die Voraussetzungen



Zu den Unternehmen, die auf Detection Engineering setzen, zählen Firmen aus dem Bankensektor, der Tech- und Cybersecurity-Branche sowie dem Healthcare-Bereich. Also hauptsächlich Branchen, die strengen regulatorischen Anforderungen unterliegen oder regelmäßig zum Ziel raffinierter Angreifer werden.  



Tatsächlich können jedoch die meisten Unternehmen mit einer komplexen IT-Infrastruktur von Detection Engineering profitieren – zum Beispiel auch mit Blick auf Security Operations Center (SOCs), wie Michael Mumcuoglu, CEO beim Detection-Engineering-Anbieter CardinalOps, erklärt: „Nicht nur die Bedrohungslandschaft verändert sich, sondern auch die eigene interne IT-Infrastruktur. Das kann zu Abweichungen bei der Detection führen, so dass die Regeln nicht mehr eingehalten und somit auch keine Warnmeldungen mehr ausgelöst werden.“



Als zentrale Voraussetzungen für den Aufbau von Detection-Engineering-Fähigkeiten gelten unter Sicherheitsexperten:




Daten: Detection-Engineering-Teams benötigen Zugriff auf Protokolle und Security-Event-Daten von Endgeräten, Netzwerken, Cloud-Umgebungen und Sicherheits-Tools sowie auf eine zentralisierte SIEM– oder Log-Management-Plattform, um diese zu aggregieren und zu normalisieren.



Qualifiziertes Personal: Detection Engineers, Security-Analysten und Threat Researcher sind nötig, um Detection-Regeln zu entwickeln und zu verfeinern.



Formalisierte Prozesse: Diese sind essenziell, um Bedrohungen zu modellieren, zu testen und Threat-Daten in die Incident Response zu integrieren.




CISO Renfrow empfiehlt Detection-Engineering-Interessierten zudem, Frameworks wie MITRE ATT&CK zu nutzen, um sicherzustellen, dass bekannte Adversary-Techniken abgedeckt werden. Zusätzlich rät der Sicherheitsentscheider Anwenderunternehmen dazu, Adversary-Emulation-Tools einzusetzen, um die Effektivität ihrer Bemühungen zu validieren.



Automatisiertes Detection Engineering



Bei der Optimierung und Automatisierung von Detection-Regeln können auch künstliche Intelligenz (KI) und Machine Learning (ML) unterstützen, wie ein weiterer Blick auf den Report von SANS und Anvilogic deutlich macht. Demnach:




setzen 45 Prozent der Studienteilnehmer in ihren Detection-Engineering-Programmen KI ein, um Anomalien zu erkennen sowie Regeln zu generieren und Warnmeldungen zu triagieren.



sind 88 Prozent davon überzeugt, dass KI in den nächsten drei Jahren erheblichen Einfluss auf ihre Detection-Engineering-Programme haben wird.



nutzen 93 Prozent der Befragten aktuell eine Form der Automatisierung in ihrem Detection-Engineering-Workflow ein – oder planen damit.




„Einer der stärksten Anwendungsfälle für KI ist es, riesige Datenmengen zu analysieren, um Anomalien zu identifizieren. Insbesondere, wenn es um KI-Modelle geht, die auf benutzerdefinierten Datensätzen trainiert wurden“, meint auch Glenn Thorpe, Senior Director of Security Research and Detection Engineering beim Plattformanbieter GreyNoise Intelligence.



Geht es darum, Detection-Engineering-Prozesse zu automatisieren, nehmen Anwender vor allem drei Bereiche in den Fokus. Sie:




mappen ihre Detection-Abdeckung mit dem MITRE-ATT&CK-Framework,



identifizieren fehlerhafte oder falsch konfigurierte Detection-Regeln, und



operationalisieren Threat-Informationen in umsetzbare Erkennungsregeln.




Security-Experte Thorpe warnt Unternehmen allerdings davor, nach einer Einheitslösung zu suchen, um Detection-Engineering-Kapazitäten aufzubauen: „Um ein effektives Team in diesem Bereich aufzubauen, sind vor allem eine kreative, vielschichtige Denkweise und Neugierde gefragt.“



Ein guter Ausgangspunkt wäre laut dem Manager, die Kerndaten des eigenen Unternehmens zu identifizieren und Menschen zu finden, die diese aus unterschiedlichen Perspektiven analysieren können: „Verschaffen Sie sich ein realistisches Bild davon, was Sie nicht wissen – und schließen sie dann diese Informationslücken. Dabei werden Sie wahrscheinlich feststellen, dass schon kleinere Veränderungen mehr Transparenz schaffen und es erleichtern, den Netzwerk-Traffic zu verstehen.“ (fm)



Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen.