Agentic SOC Platform: Wie entscheidet der KI-Agent?
Warum die Alert-Bewertung zum Engpass wird
Der größte Teil des Alert-Volumens eines SOC ist wiederholende Arbeit, keine schwierigen Ermessensentscheidungen – für jeden einzelnen Alert muss derselbe Kontext zusammengetragen werden, bevor überhaupt jemand fragen kann, ob er relevant ist. In dieser Wiederholung geht Analystenzeit tatsächlich verloren, und genau dort verändert ein Agentic SOC die Rechnung.
Wie der Agent von SecureVisio entscheidet:
von der Anreicherung bis zur Response
Ein Agentic SOC ist ein Security Operations Center, in dem ein KI-Agent Alerts eigenständig anreichert, bewertet und Reaktionen auslöst. In der SecureVisio-Plattform startet dieser Agent automatisch, unmittelbar nachdem ein Alert zur Bearbeitung zugewiesen wurde – ohne manuellen Auslöser und ohne auf den ersten Blick eines Analysten zu warten. Er handelt innerhalb der Grenzen, die das jeweilige Playbook setzt.
Die Abfolge ist bei jedem Durchlauf dieselbe. Die ersten sieben Schritte sammeln Kontext, der achte klassifiziert, der neunte wählt die Response:
1
2
3
4
5
6
7
8
9
Die Schritte 1 bis 7 sind genau die Arbeit, die sonst von Hand erledigt werden muss: dieselben Abfragen, dieselbe Reihenfolge, für jeden Fall neu. Der Unterschied ist nicht, dass andere Quellen abgefragt werden – sondern dass sie vollständig und in gleicher Tiefe abgefragt werden, auch beim zwanzigsten Alert einer Schicht und auch dann, wenn der Fall auf den ersten Blick unauffällig wirkt. Erst darauf folgt die Klassifikation.
Der wichtigste Satz zu diesem Prozess betrifft den letzten Schritt: Das Modell wählt aus einem vordefinierten Katalog von Reaktionen – es formuliert keine eigenen Eingriffe. Was der Agent auslösen kann, steht vorab fest und ist nicht das Ergebnis einer Textgenerierung. Die Datengrundlage für die Schritte 1 bis 7 liefert die SIEM-Plattform; während der Bearbeitung greift der Agent modulübergreifend auf SIEM, SOAR, UEBA und XDR zu.
Die Klassifikation in Schritt 8 ist eine Entscheidung über den weiteren Bearbeitungsweg innerhalb des Werkzeugs. Ob ein Vorfall zusätzlich einer Meldepflicht unterliegt, ist eine rechtliche Frage, die an anderer Stelle beantwortet wird – nicht vom Agenten.
Autonome SOC-Response bei SecureVisio:
konfigurierbar und an den Kontext gebunden
Der Agent kennt zwei Betriebsmodi, und keiner davon ist der Standard. Er entscheidet entweder selbst, oder er legt dem Operator seine Empfehlung zur Freigabe vor. Welcher der beiden gilt, wird fallweise konfiguriert; beide Wege werden gleichwertig unterstützt. Wer in manchen Szenarien Autonomie will und in anderen nicht, muss sich nicht auf einen Ansatz festlegen.
Die zweite Begrenzung ist die interessantere, weil sie nicht aus einer Berechtigungsliste stammt, sondern aus dem Kontext des betroffenen Systems:
Der Asset-Typ spielt eine Rolle.
Das Blockieren eines Prozesses steht zur Verfügung, wenn der Alert eine Workstation betrifft. Handelt es sich um einen Server, greift der Agent nicht zu diesem Mittel, sondern zu einer der für diesen Fall definierten Alternativen.
Risikoanalyse und BIA begrenzen die zulässige Reaktion.
Das bindet den Eingriff an die Bedeutung, die das betroffene Asset für Ihre Geschäftsprozesse hat. Nicht das technisch Mögliche bestimmt die Reaktion, sondern das im Geschäftskontext Vertretbare.
Die Modulgrenze ist durchlässig, wenn der Kontext es rechtfertigt
Erkennt der Agent Kommunikation mit einem Command-and-Control-Server, blockiert er sie nicht zwingend auf der betroffenen Station – er blockiert dort, wo die Sperre wirksamer ist, auf der Firewall.
Für die Ausführung stehen den Playbooks über 290 benannte System Actions zur Verfügung. Ein erheblicher Teil davon ist rein lesend – diagnostische Abfragen auf dem Endpoint, Suchen in der Knowledge Base, Abfragen externer Dienste. Fünf Beispiele, jeweils mit der Bedingung, unter der sie greifen:
| Beispiel | Wann der Agent dazu greift |
|---|---|
| Sperre auf der Firewall statt auf dem Endpoint | Wenn Command-and-Control-Kommunikation erkannt wurde und die Sperre an der Netzgrenze wirksamer ist als auf der einzelnen Station |
| Granulare Netzsperre über den XDR-Agenten | Wenn nur eine bestimmte Verbindung gesperrt werden muss – blockiert nach Richtung, Adresse und Port, ausgeführt auf einem bestimmten Host, statt den Endpoint vollständig vom Netz zu nehmen |
| Host-Quarantäne über die NAC-Lösung | Wenn der Endpoint als Ganzes vom Netz getrennt werden muss und der Asset-Kontext diesen Eingriff zulässt |
| Granulare Netzsperre über den XDR-Agenten | Wenn nur eine bestimmte Verbindung gesperrt werden muss – blockiert nach Richtung, Adresse und Port, ausgeführt auf einem bestimmten Host, statt den Endpoint vollständig vom Netz zu nehmen |
| Deaktivierung des betroffenen Kontos im Verzeichnisdienst | Wenn die Anomalie am Konto hängt und nicht am System – Alternativen im selben Bereich sind ein erzwungener Passwortwechsel oder das Beenden der Sessions |
| Abgleich eines Indikators über mehrere Threat-Intelligence-Quellen | In der Anreicherungsphase jedes Falls – ein rein lesender Schritt, der nichts in Ihrer Umgebung verändert |
Nachvollziehbarkeit: jeder Schritt bleibt reproduzierbar
Ein Agent, der eigenständig handelt, ist nur so viel wert wie die Möglichkeit nachzuvollziehen, was er getan hat. Jeder Schritt, den der Agent ausführt, wird in der Fallhistorie gespeichert und lässt sich zu jedem späteren Zeitpunkt reproduzieren. Der Analyst sieht nicht nur das Ergebnis, sondern die Begründung für die Aktion; die Entscheidung bleibt damit auditierbar – auch Wochen später und auch für jemanden, der an der ursprünglichen Bearbeitung nicht beteiligt war.
Ebenso wichtig ist das Verhalten im Fehlerfall, und hier sind zwei Fälle zu unterscheiden:
- Fällt ein benötigter Dienst aus, stoppt die Bearbeitung. Auf Dienstebene gibt es kein Ersatzverfahren; der Fall stoppt, statt auf unvollständiger Grundlage weiterzulaufen.
- Ist das Sprachmodell nicht verfügbar, greifen die Fallback-Regeln der Playbooks. Diese sind je Schritt definiert, sodass der Ausfall zu einer abgestuften Einschränkung führt statt zum Stillstand des gesamten Prozesses.
Für den Betrieb bedeutet das: Der Grad der Autonomie ist gesetzt, die Begründung ist sichtbar, der Prozess ist rekonstruierbar, und das Verhalten im Fehlerfall ist vorab bekannt. Das sind die vier Punkte, die darüber entscheiden, ob ein SOC für einen automatisch handelnden Agenten geradestehen kann.
Evidence
Gartner ★ 4.8/5
Reviews
Bewertungen ansehen
G2 ★ 5/5
Peer Insights
Bewertungen ansehen
ISO 27001
Zertifikat
ISO 9001
Zertifikat
Security Made in Poland
Poland Security Congress
250+
Kunden in Europa
Deloitte Fast 50
Führendes Unternehmen · 2022
Geplant für Q4 2026: ein MCP-Server für die
Werkzeugauswahl des Agenten
Wir planen einen MCP-Server (rund 40 Dienste), damit der Agent seine Werkzeuge selbst auswählen kann, statt an feste Playbook-Schritte gebunden zu bleiben, und damit Incidents perspektivisch in natürlicher Sprache gesteuert werden können. Was heute gilt, ist alles oben Beschriebene: Der Agent handelt innerhalb der Grenzen des Playbooks, und seine Reaktionen stammen aus einem vordefinierten Katalog.
