SecureVisios Automatisierungsmodell: Warum die Untersuchung stattfindet, bevor der Analyst eintrifft

Die meisten Security-Operations-Teams haben dasselbe Problem – nur in unterschiedlichem Ausmaß: Alerts treffen schneller ein, als Analysten sie untersuchen können. Die Standardantwort lautete bisher „mehr Personal einstellen” oder „Regeln besser abstimmen”. SecureVisios Antwort ist strukturell anders – die Untersuchung wird in die Reaktion integriert, nicht ihr nachgelagert.

Betrachtet man die tatsächliche Funktionsweise der Plattform, geht es beim Automatisierungsmodell weniger darum, dass Skripte ablaufen, sondern vielmehr darum, dass Kontext automatisch durch jede Phase der Incident-Behandlung weitergeleitet wird. Dieser Unterschied ist bedeutsamer, als er zunächst erscheinen mag.

Das Problem mit „Alert, dann Untersuchen”

Der klassische SIEM-Workflow läuft sequenziell ab. Ein Alert wird ausgelöst. Ein Analyst öffnet ihn. Der Analyst durchsucht manuell Logs, prüft Reputationsdatenbanken, analysiert Benutzeraktivitäten, ordnet das Ereignis dem MITRE ATT&CK-Framework zu – und entscheidet dann, was zu tun ist. Jeder dieser Schritte ist eine Übergabe, und jede Übergabe bedeutet Latenz.

SecureVisio geht einen anderen Weg: Die Untersuchung findet während des Triages statt, nicht danach. Wenn ein menschlicher Analyst einen Incident zu Gesicht bekommt, ist ein erheblicher Teil der kontextuellen Vorarbeit bereits geleistet.

AutoTriage: Parallelisierung statt sequenzieller Abarbeitung

Das deutlichste Beispiel ist das AutoTriage-Szenario. Sobald ein Incident erstellt wird, prüft das System sofort, ob für denselben Benutzer (ctx.User) oder dieselbe IP (ctx.IP) am selben Tag bereits verwandte Incidents existieren. Ist dies der Fall, werden sie automatisch zusammengeführt. Kein Analyst muss das doppelte Muster erst erkennen.

Falls nicht, protokolliert AutoTriage das Ereignis nicht einfach und wartet. Stattdessen werden eine Reihe paralleler, vollständig automatisierter Analyseschritte angestoßen:

• Analyse des Netzwerkverkehrs anhand bekannter Angriffsindikatoren
• Vergleich der Benutzeraktivitäten mit Verhaltens-Baselines
• Entity-Behavior-Analyse
• MITRE ATT&CK-Technik-Mapping
• Log- und Ereignisanalyse auf Anomalien
• Threat-Intelligence-Integration auf Basis der Ereignisdaten
• Knowledge-Base-Abfrage zu früherer Aktivität auf dem betroffenen Host
• Überprüfung von Benutzerkonten auf Anzeichen einer Kompromittierung

Diese Schritte laufen nicht sequenziell, sondern gleichzeitig ab. Und entscheidend: Keiner davon erfordert eine Initiierung durch einen Analysten.

Das verdient besondere Beachtung. Ein Analyst, der Triage manuell durchführt, arbeitet diese Prüfungen nacheinander ab und wechselt dabei zwischen verschiedenen Tools. AutoTriage fasst all das in die Voruntersuchungsphase zusammen. Wenn das Ticket auf dem Schreibtisch eines Menschen landet, sind bereits Bedrohungsbewertung, Verhaltenskontext und MITRE-Mappings beigefügt.

Das erklärte Ziel – in der Dokumentation explizit formuliert – ist es, dass Analysten sich auf Entscheidungen konzentrieren können, die Expertenwissen erfordern, und nicht auf wiederkehrende Sammeltätigkeiten.

Playbooks, die den Unterschied zwischen automatisch und manuell wirklich verstehen

Playbooks sind nicht binär. Man wählt nicht zwischen „vollautomatisch” und „erfordert menschliche Beteiligung”. Einzelne Schritte, einzelne Pläne oder das gesamte Szenario können – in beliebiger Granularität – als automatisch oder manuell markiert werden, je nachdem, was für die eigene Organisation sinnvoll ist.

Das ist nützlicher, als es klingt. Ein Szenario kann automatisch Host-Informationen sammeln, automatisch Reputationsdatenbanken abfragen, automatisch prüfen, ob eine IP bereits auf einer Blockliste steht – und dann innehalten und dem Operator eine Entscheidung präsentieren, bei der der relevante Kontext bereits vorausgefüllt ist. Der Operator wählt eine Option (Konto sperren, IP zur Blockliste hinzufügen, keine Maßnahme erforderlich), fügt einen Kommentar hinzu, und das Szenario wird fortgesetzt.

Das System unterstützt auch bedingte Progression. Der condition-Block eines Schritts bestimmt, ob diese Aktion überhaupt ausgeführt wird – ist die Bedingung nicht erfüllt, wird der Schritt übersprungen und das Szenario läuft weiter. Außerdem lässt sich konfigurieren, ob nicht gematchte Antworten in einem Suchschritt das Szenario stoppen oder fortfahren lassen.

In der Praxis entsteht so ein Workflow, bei dem die Automatisierung die deterministischen Teile übernimmt und Menschen die mehrdeutigen – ohne dass jemand explizit zwischen beiden wechseln muss.

Log-Suche ohne Expertenwissen in Query-Sprachen

Ein oft unterschätzter Aspekt ist das Backtracking. Operatoren können Logs direkt aus der Incident-Ansicht heraus durchsuchen – mit einer SQL-ähnlichen Syntax, bei der die Autovervollständigung verfügbare Felder, Objekte und Funktionen inline anzeigt.

Der Log-Browser verfügt zudem über eine Schlüsselwortsuche, die alle Felder abgleicht: Die Eingabe eines Benutzernamens zeigt zunächst, in welchen Feldern dieser Name erschienen ist (DstUserName, SrcUserName usw.), bevor die gefundenen Frames angezeigt werden. Begriffe lassen sich mit % als Platzhalter kombinieren.

Diese Suchen können direkt in Playbook-Schritte eingebettet werden. Ein Szenario kann automatisch eine rückblickende Suche ausführen – etwa ob ein Zielbenutzer innerhalb eines Zeitfensters relativ zum Ereignis auf anderen Rechnern eingeloggt war – und anhand der Ergebnisanzahl verzweigen. Es lässt sich prüfen, ob DstUserNameseit dem Tag des Ereignisses in Login-Events auf anderen Systemen aufgetaucht ist. True, wenn count > 0, andernfalls false.

Damit wird „prüfen, ob dieser Benutzer Lateral Movement betrieben hat” zu einem Szenario-Schritt – und nicht zu einer Analysten-Aufgabe.

PAM-Integration: Der Teil, den Security-Automatisierung meist falsch macht

Automatisierte Remediation-Aktionen haben fast immer ein Credential-Problem. Das Skript muss sich authentifizieren, um etwas zu tun – ein AD-Konto deaktivieren, eine IP blockieren, einen externen Dienst abfragen. Der naive Ansatz bettet Credentials direkt in das Skript oder die Konfiguration ein. Das ist ein Sicherheitsproblem in einem Sicherheitsprodukt.

SecureVisio begegnet dem durch eine integrierte PAM-Integration (Privileged Access Manager). Wenn eine Systemaktion mit dem Flag „Global name” für einen Parameter konfiguriert ist, wird der Wert zur Ausführungszeit aus dem PAM bezogen – nicht in der Szenariokonfiguration gespeichert. Das Szenario selbst enthält zu keinem Zeitpunkt die Zugangsdaten.

Das Dokumentationsbeispiel ist die Aktion [ADManager] Disable User, die ihr Authentifizierungstoken, das Passwort und den Benutzernamen direkt beim Ausführen aus dem PAM bezieht. Ein Analyst, der diese Aktion auslöst – oder das System, das sie automatisch auslöst – sieht diese Credentials nicht und muss sie nicht handhaben.

Das ist aus zwei Gründen relevant: Es ermöglicht die vollständige Automatisierung authentifizierungspflichtiger Aktionen ohne manuelle Credential-Eingabe, und es hält sensible Zugangsdaten aus Szenariokonfigurationen heraus, wo sie von jedem mit Zugriff auf den Playbook-Editor eingesehen oder exportiert werden könnten.

KI als Szenario-Schritt – nicht nur als Chat-Fenster

SecureVisio verfügt über eine KI-Assistenten-Chatoberfläche für Analysten. Dieser Teil ist vergleichsweise unkompliziert – Chat öffnen, aus vordefinierten Prompts wählen, eine Zusammenfassung oder Klassifikation des Incidents erhalten.

Weniger offensichtlich ist, dass KI auch innerhalb von Automatisierungsszenarien als erstklassiger Aktionstyp verfügbar ist.

Die Aktion „KI-Assistent” in einem Szenario lässt sich so konfigurieren, dass spezifische Kontextdaten an das Modell übergeben werden: der letzte Ereignis-Frame, Ergebnisse vorheriger Schritte im Szenario, angehängte Dateien, der Verlauf oder das SIEM-Regelskript, das den Alert ausgelöst hat. Die Antwort des Modells kann automatisch in die Zwischenablage übertragen oder für nachgelagerte Schritte gespeichert werden. Das Szenario hält nicht an und wartet auf einen Menschen, der den Chat öffnet.

KI-Analyse kann damit Teil der automatisierten Triage-Pipeline sein – nicht als separates Tool, das ein Analyst manuell konsultiert. Die Architektur behandelt KI genauso wie jede andere Anreicherungsquelle: als etwas, das Inputs entgegennimmt und strukturierte Outputs zurückliefert, die das Szenario weiterverarbeiten kann.

Das Prompt-System verfügt zudem über eine Profilebene – Prompts sind in Profile organisiert, und Profile können an bestimmte Response-Teams und Szenariotypen gebunden werden. Ein für ein Netzwerk-Intrusion-Szenario erstellter Prompt kann von einem für Endpoint-Kompromittierung getrennt gehalten und im passenden Teamkontext angezeigt werden.

Was das tatsächlich verändert

Die Automatisierungsphilosophie hier lautet nicht „Analysten ersetzen”. Sie lässt sich eher so beschreiben: Analysten sollen keine Aufgaben übernehmen, die das System mit gleicher oder besserer Genauigkeit erledigen kann.

Zu prüfen, ob ein Benutzer sich auf anderen Rechnern eingeloggt hat, ist deterministisch. VirusTotal nach einem Hash zu befragen, ist deterministisch. Doppelte Incidents von derselben IP am selben Tag zusammenzuführen, ist deterministisch. Ein Ereignis anhand seiner Kategorie einem MITRE-Technique zuzuordnen, ist deterministisch. All das kostet Analysten-Zeit – und keines davon erfordert Analysten-Urteilsvermögen.

Die Aspekte, die Urteilsvermögen erfordern – ist dieses Verhalten im Geschäftskontext tatsächlich bösartig? Welche Reaktion ist angesichts der Asset-Kritikalität angemessen? – die gehen weiterhin an Menschen, allerdings mit bereits vollständig zusammengestelltem deterministischen Kontext.

Die praktische Konsequenz: Die Incident-Response-Zeit sinkt nicht, weil Analysten schneller arbeiten, sondern weil sie an einem späteren, besser informierten Punkt in den Prozess einsteigen. Die wiederkehrenden Sammeltätigkeiten werden nicht schneller erledigt – sie werden erledigt, bevor überhaupt jemand zuschaut.