Use-Cases
Wenn vier Teams denselben Report lesen, entstehen vier unterschiedliche Wahrheiten – jeweils im eigenen Tool und in ihrer eigenen Sprache. Die folgenden Use-Cases greifen alle auf ein gemeinsames reguliertes Cyber-Threat-Modell zurück. Jedes Team behält seine Tools, das Wissen bleibt einheitlich, und jeder Use-Case nennt die Regulierung oder das Programm, dem er dient: DORA, NIS2, KRITIS, TIBER-EU oder CTEM.
01–02 · Die Bedrohung kennen
Mehr Feeds machen ein SOC nicht sicherer. Entscheidend ist, zu wissen, welche Akteure für Sie relevant sind, und über ein Modell ihres Verhaltens zu verfügen, hinter dem Ihre Analysten stehen.
Generische Akteurslisten überlassen dem Leser die Frage nach der Relevanz. Die Plattform bewertet eine kuratierte Bibliothek anhand Ihrer Geschäftsparameter, Szenarien und der von Ihnen verfolgten Events und liefert die für Sie relevanten Akteure nach Risiko priorisiert und jeweils mit einer überprüfbaren Begründung zurück.
Einen Report manuell zu veredeln dauert Wochen, und einem Report, der allein von einem Modell veredelt wurde, kann nicht vertraut werden. Hier erstellt die KI den Attack-Graphen, jede Aussage behält ihre Evidenz und ihren Vertrauensgrad, und ein Analyst validiert, bevor etwas das Modell verlässt.
03–06 · Defence-Operations betreiben
Threat-Intelligence, die weder Detection, Hunting noch Response verändert, schafft keine Einsatzbereitschaft. Diese vier Use-Cases basieren auf demselben Modell und bleiben bis zur zugrunde liegenden Aussage rückverfolgbar.
Regeln, die auf Anfrage von einem Sprachmodell erstellt werden, sind Aussagen ohne Kontext. Die Plattform leitet Detektionslogik aus validierten Techniken ab, verknüpft sie mit den verfügbaren Logquellen und erzeugt native Regeln für Ihr SIEM und EDR, wobei die Abdeckung je Angreifer erfasst wird.
Threat-Hunting ohne Hypothese ist bloßes Suchen. Hypothesen werden aus der Vorgehensweise des Angreifers im Modell abgelesen und mit Untersuchungsfragen sowie den Daten verknüpft, die diese beantworten können, sodass Threat-Hunter dort ansetzen, wo der Angreifer zu erwarten ist, statt dort, wo sich das Rauschen befindet.
Eindämmung, bevor die Kampagne verstanden wurde, hinterlässt Lücken. Der Scope wird aus der beobachtbaren Ebene des Modells abgeleitet – Infrastruktur, Ports und verifizierte Indikatoren – und der Graph führt Incident-Responder entlang der Reihenfolge des Angreifers von der Technik über die Logquelle bis zum Event.
Ein CVSS-Score sagt nichts darüber aus, ob ein Angreifer die Schwäche überhaupt erreichen kann. Schwächen und Angriffspfade werden nach Angreifer-Relevanz priorisiert, basierend auf Motivation und Absicht je kritischer Geschäftsfunktion und auf Grundlage desselben Modells, das auch SOC und Red Team nutzen, sodass keine parallele Wahrheit entsteht.
07–08 · Testen und nachweisen
Aufsichtsbehörden fordern Threat-Led-Tests und eine auditierbare Kette von der Threat-Intelligence bis zur Sicherheitsmaßnahme. Beides wird aus dem Modell abgeleitet, statt auf einem leeren Blatt zu beginnen.
Jeder Testzyklus, der bei null beginnt, wiederholt die Recherche des vorherigen. Threat-Profile, Szenarien und Angriffspfade je kritischer Geschäftsfunktion werden aus dem Modell als Datengrundlage für den Targeted Threat Intelligence Report erzeugt – bis zu den Quellen rückverfolgbar und im nächsten Zyklus reproduzierbar.
Auditoren wollen sehen, welche Aussage zu welcher Sicherheitsmaßnahme geführt hat, und nicht ein Richtliniendokument. Das Modell erhält diese Nachvollziehbarkeit je kritischer Geschäftsfunktion: wer sie bedroht und auf welche Weise, was erkannt und was getestet wird. Die Reporting-Engine überführt dies in geprüfte, mit TLP gekennzeichnete Dokumente.
09 · Auf dem Weg zum agentischen SOC
DemnächstAgenten sind nur so gut wie der Kontext, auf dessen Grundlage sie handeln, und dieser Kontext ist meist im Ökosystem eines einzelnen Anbieters gebunden – schwer zu teilen und über einen heterogenen Security-Stack hinweg wiederzuverwenden. Ihre eigenen Agenten oder die mit Ihren Plattformen bereitgestellten Agenten lesen über APIs und MCP validierte Aussagen aus dem regulierten Modell. Plattform wechseln, Wissen behalten.
Compliance-Nachweise
Kritische Geschäftsfunktionen werden so modelliert, wie es die regulatorischen Vorgaben beschreiben, und jede Detection sowie jedes Testszenario bleibt von der zugrunde liegenden Threat-Intelligence bis zur daraus entstandenen Sicherheitsmaßnahme rückverfolgbar.
Beginnen Sie mit zwei davon
Detection-Coverage und Hunting sind das übliche erste Paar. Response, Exposure-Management und Threat-Led-Testing folgen auf demselben Modell.
Kontakt
Machen Sie aus den Berichten und Feeds, die Sie bereits beziehen, ein reguliertes Cyber-Threat-Modell, mit dem Ihr SOC, Ihr Risikomanagement und Ihre Geschäftsleitung arbeiten können. Sagen Sie uns, wo Sie beginnen möchten.
