Sicherheitsfälle und Playbooks (SOAR)

Das Produkt Sicherheitsereignisse macht aus den Funden Ihrer Erkennungsregeln, Ihrer Threat Intelligence und Ihrer verbundenen Sicherheitsprodukte Fälle: einen Fall für jede Sache, die eine Untersuchung wert ist, und darin gebündelt alle Erkennungen zum selben Benutzer, zum selben Host oder zur selben Adresse. Analysten bearbeiten die Fälle in einer Warteschlange, und Playbooks reagieren darauf, von selbst oder auf Knopfdruck.

So funktioniert es#

Öffnen Sie Produkte → Sicherheitsereignisse → Sicherheitsfälle → Offene Fälle für die Warteschlange. Mir zugewiesen, Nicht zugewiesen, Geschlossene Fälle und Alle Fälle sind eigene Seiten daneben, und jede listet die Fälle, die ihr Name sagt.

Bevor Sie beginnen#

Fälle und Playbooks folgen den drei Security-Rollen. Project Owner und Project Admin dürfen alles.

Jedes dieser Rechte lässt sich auch einzeln vergeben, vom Erstellen eines Falls bis zum Genehmigen der Schritte eines Playbooks; siehe Berechtigungsreferenz.

Woher Fälle kommen#

Jede Quelle ist standardmäßig eingeschaltet. Eine Verbindung eröffnet Fälle für Hoch und höher, sofern Sie keine andere Stufe wählen; die Warnungen darunter werden weiterhin als Ereignisse importiert.

Wie Erkennungen gruppiert werden#

Eine Erkennung betrifft eine Entität: den Wert, nach dem ihre Regel gruppiert, etwa die IP-Adresse bei einer Brute-Force-Regel, oder den Indikator, den ein Threat-Intelligence-Treffer nennt. Eine Erkennung ohne Entität steht für sich allein.

• Gibt es bereits einen offenen Fall zu dieser Entität, wird die Erkennung ihm zugeordnet. Die Entitäten und das ATT&CK-Mapping des Falls wachsen, und seine Priorität steigt auf die der Erkennung, sinkt aber nie.
• Gibt es keinen, wird ein neuer Fall eröffnet, benannt nach der Erkennung und mit deren Priorität.
• Eine Erkennung, die erneut auslöst, zählt in ihrer Zeile hoch, statt eine weitere hinzuzufügen.

Die Priorität eines Falls ergibt sich aus dem Schweregrad der Erkennung:

Einen Fall bearbeiten#

Ein Fall durchläuft vier Status. Er kann einen davon überspringen, etwa wenn ein False Positive direkt aus „Neu“ heraus geschlossen wird, und er kann wieder geöffnet werden.

Die Seite des Falls bietet alles, um ihn zu bearbeiten:

• Oben: Assign to Me, Run Playbook, Vorfall melden und Close Case, die Statusschritte und die Priorität im Menü daneben.
• Status200 AI: was Status200 AI aus dem Fall gelesen hat, die Priorität und das Playbook, die es vorschlägt, und die Beweise dahinter. Siehe Status200 AI in der Sicherheit.
• Erkennungen: was ausgelöst hat, um den Fall zu eröffnen oder ihn zu ergänzen, wie oft, und das neueste passende Ereignis.
• Entitäten: die Benutzer, Hosts und Adressen, um die es im Fall geht, mit ihrer Aktivität in allen Ihren Sicherheitsereignissen der letzten 7 Tage. Jede öffnet sich in Korrelieren.
• MITRE ATT&CK: die Taktiken und Techniken, denen seine Erkennungen zugeordnet sind, jeweils verlinkt mit ihrer Seite auf attack.mitre.org.
• Playbook-Ausführungen: was jedes Playbook am Fall getan hat, Schritt für Schritt, und die Schritte, die auf Genehmigung warten.
• Notizen und Zeitachse: was das Team geschrieben hat, und alles, was geschehen ist, jeweils mit der Person, die es getan hat.

Um mehrere Fälle auf einmal zu bearbeiten, wählen Sie sie in der Warteschlange aus und nutzen Assign to Me, Change Status oder Change Priority.

Einen Fall schließen#

Close Case fragt nach einer Bewertung und einer optionalen Abschlussnotiz:

Die Bewertungen werden in der Übersicht gezählt. Eine Regel, deren Fälle immer wieder als False Positive geschlossen werden, sollte nachgeschärft werden.

Ein Fall, der aus Google SecOps-Warnungen eröffnet wurde, schließt sie auch in Google SecOps, mit dem Urteil und der Abschlussnotiz, wenn an seiner Verbindung Warnungen schließen, wenn ihr Fall geschlossen wird eingeschaltet ist: siehe Google SecOps.

Einen Vorfall melden#

Vorfall melden öffnet für den Fall einen Status200-Vorfall mit dem Schweregrad, den Sie wählen, und verknüpft beide in beide Richtungen: Die Beschreibung des Vorfalls nennt den Fall, und der Kopfbereich des Falls verlinkt auf den Vorfall. Ab dort übernehmen Bereitschaft, Statusseiten und das Postmortem. Dafür braucht es eine Rolle, die sowohl Fälle bearbeiten als auch Vorfälle erstellen darf.

Benachrichtigungen#

Status200 informiert Personen über drei Dinge an einem Fall. Niemand muss dafür etwas einrichten: Ein Projekt, das nur auf Empfohlenes aktivieren geklickt hat, erfährt von seinen Fällen mit Priorität Hoch und Kritisch per E-Mail und Push.

• Nur Personen, die den Fall sehen können, werden darüber informiert: Project Owner, Project Admin und die Rollen Security Admin, Security Member und Security Viewer. Eine Rolle, die auf bestimmte Labels beschränkt ist, wird nur über die Fälle mit diesen Labels informiert.
• Niemand wird über das informiert, was er selbst getan hat: Wer einen Fall per Hand eröffnet, ihn zuweist oder eine Ausführung startet, wird darüber nicht benachrichtigt.
• Jede Person erfährt nur einmal von einem Fall. Ein Fall, der mit Medium eröffnet wird und später auf Kritisch steigt, erreicht beim Anstieg die Personen, die Hoch und Kritisch oder Nur Kritisch gewählt haben, und nicht noch einmal die Personen, die Mittel und höher gewählt und schon bei der Eröffnung davon erfahren haben.
• Der Testangriff aus Testangriff senden eröffnet einen Fall, der niemanden benachrichtigt.
• Ein Fall mit Priorität Kritisch und ein Schritt, der auf Genehmigung wartet, werden sofort gesendet und nie in einer E-Mail-Zusammenfassung zurückgehalten.
• Die Zeitachse des Falls zeigt, wer wann informiert wurde.

Wählen, worüber Sie informiert werden#

Jede Person wählt selbst, unter Benutzereinstellungen → Benachrichtigungseinstellungen → Sicherheit: die Kanäle für jede Benachrichtigung (E-Mail, SMS, Anruf, Push, Telegram, Slack, Microsoft Teams oder Webhook) und unter Neuer Sicherheitsfall die Priorität, ab der sie benachrichtigt wird:

Für Sicherheitsfälle werden keine WhatsApp-Nachrichten gesendet. Eine Push-Benachrichtigung öffnet die Status200-App, und ihr Link öffnet den Fall im Browser.

In Kanäle von Slack und Microsoft Teams posten#

Um in einem Kanal zu posten, fügen Sie unter Produkte → Sicherheitsereignisse → Arbeitsbereich → Slack (oder Microsoft Teams) eine Regel hinzu. Ist keines von beiden verbunden, ist der einzige Eintrag des Bereichs Slack oder Teams verbinden. Eine Regel nennt die Kanäle, in die gepostet wird (und in Microsoft Teams die Chats), und auf Wunsch die Fälle, für die sie gilt:

Die drei Benachrichtigungen werden jeweils in die Kanäle jeder Regel gepostet, auf die der Fall in diesem Moment passt. Eine Regel, deren Priorität des Sicherheitsfalls eines von Kritisch und Hoch enthält, postet Fälle mit Priorität Hoch und Kritisch, sobald sie eröffnet werden, und einen Fall mit Medium, wenn er auf Hoch steigt. Ein Sicherheitsfall bekommt nie einen eigenen Kanal.

Playbooks#

Ein Playbook ist eine Liste von Schritten, die auf einem Fall laufen. Erstellen Sie eines unter Produkte → Sicherheitsereignisse → Playbooks, aus einer Vorlage oder leer, und fügen Sie seine Schritte auf seiner Seite hinzu.

Wann ein Playbook läuft#

Jedes aktivierte Playbook lässt sich auch per Hand ausführen, mit Run Playbook an einem Fall. Ein Playbook, das von selbst läuft, lässt sich eingrenzen:

• For Cases At Least: nur Fälle dieser Priorität oder höher.
• Only For Detections From: nur, wenn die Erkennung hinter dem Fall aus dieser Quelle stammt.
• Only For These Detection Rules: nur, wenn sie aus einer dieser Regeln stammt.

Ein deaktiviertes Playbook läuft weder von selbst noch per Hand.

Schritte#

Ein Playbook hat höchstens 25 Schritte. Sie laufen der Reihe nach, jeder, sobald der vorige fertig ist. Jeder Schritt kann außerdem:

• Needs Approval: die Ausführung vor dem Schritt anhalten, bis jemand ihn am Fall genehmigt. Die vier Schritte, die jemanden aussperren, halten immer an, es sei denn, ein Security Admin schaltet das ab.
• Only If Threat Intel Matched: den Schritt überspringen, sofern nicht ein früherer Schritt Check entities against threat intel derselben Ausführung einen bekannten Indikator gefunden hat.
• Carry On If It Fails: den nächsten Schritt ausführen, auch wenn dieser fehlschlägt. Ist die Option aus, beendet ein fehlgeschlagener Schritt die Ausführung.

Eindämmung#

Die Eindämmungsschritte handeln über eine Verbindung für Sicherheitsereignisse zum Produkt, die dafür mehr als Lesezugriff braucht:

Ein Eindämmungsschritt wirkt nur auf die Benutzer oder Hosts, um die es im Fall geht, nie auf alle, die der Fall nennt:

• Der Wert, nach dem eine Erkennung des Falls gruppiert ist, etwa das Konto, nach dem eine Regel für unmögliche Ortswechsel gruppiert, oder der Host, den die Warnung eines verbundenen Produkts nennt.
• Ein Benutzer oder Host des Falls, den Ihre Threat Intelligence als Indikator kennt.

Bei einem Fall, der nach einer Adresse gruppiert ist, etwa einem Brute-Force-Angriff auf Ihr VPN, geht es um keines von beiden: Seine Eindämmungsschritte werden übersprungen, und das Konto, bei dem er es versucht hat, und das Gateway, das er getroffen hat, bleiben unangetastet. Ein Schritt wirkt auf höchstens 10 Benutzer oder Hosts. Er sucht jeden davon im Produkt nach seinem Namen und vermerkt an der Ausführung, was er mit jedem getan hat: erledigt, bereits erledigt, nicht gefunden, abgelehnt oder geschützt.

Geschützte Entitäten#

Protected Entities, im Menü unter Playbooks, listet die Benutzer und Hosts, die kein Playbook eindämmt, etwa Notfallzugriffskonten, Domänencontroller und VPN-Gateways. Ein Wert passt unabhängig von der Groß- und Kleinschreibung, und * steht für eine beliebige Folge von Zeichen: svc-* schützt jedes Dienstkonto. Ein Schritt meldet einen geschützten Benutzer oder Host als geschützt und lässt ihn unangetastet. Security Admins pflegen die Liste.

Genehmigung#

Die vier Schritte, die jemanden aussperren, warten auf Genehmigung. Nur ein Security Admin kann Needs Approval für einen von ihnen abschalten, und Status200 hält fest, wer das getan hat. Die Genehmigung listet unter Act On die Benutzer oder Hosts, auf die der Schritt wirken würde, alle angehakt: Entfernen Sie den Haken bei allen, die er unangetastet lassen soll. Geschützte werden nicht angeboten. Wer eine Ausführung gestartet hat, kann ihre Schritte nicht genehmigen: Das tut jemand anderes, ablehnen kann er sie aber weiterhin.

Rückgängig machen#

Die Schritte zum Rückgängigmachen wirken auf die Benutzer oder Hosts, um die es im Fall geht, wie die Schritte, die sie rückgängig machen. Sobald die Ausführung beendet ist, hat ein eingedämmter Benutzer oder Host an seinem Schritt außerdem eine eigene Schaltfläche: Unsuspend, Lift Containment oder Freigeben. Das Beenden einer Okta-Sitzung lässt sich nicht rückgängig machen. Jedes Rückgängigmachen wird in der Zeitachse des Falls und im Audit-Protokoll des Projekts festgehalten.

Nachrichten#

Eine Notiz, eine E-Mail, ein Slack-Beitrag und ein Teams-Beitrag können die Werte des Falls nutzen:

Eine E-Mail oder ein Beitrag ohne eigene Nachricht sendet eine Zusammenfassung des Falls.

Ausführungen und Genehmigungen#

Jede Ausführung wird an ihrem Fall und unter Produkte → Sicherheitsereignisse → Playbooks → Playbook-Ausführungen aufgelistet, Schritt für Schritt:

Ein Schritt, der auf Genehmigung wartet, zeigt an der Ausführung Approve und Ablehnen, mit einem optionalen Kommentar. Eine Genehmigung setzt die Ausführung ab diesem Schritt fort; eine Ablehnung beendet sie. Die Entscheidung, wer sie getroffen hat, und der Kommentar werden am Schritt, in der Zeitachse des Falls und im Audit-Protokoll des Projekts festgehalten. Wartet auf Genehmigung, im Menü unter Playbooks, listet die Ausführungen, die auf eine Entscheidung warten, und zählt sie; Playbook-Ausführungen listet jede Ausführung.

Eine Ausführung, von deren Worker nichts mehr kommt, etwa nach einem Neustart, wird wieder aufgegriffen: Eine Ausführung in der Warteschlange wird nach 2 Minuten erneut eingereiht, und eine Ausführung, die sich 30 Minuten lang nicht gemeldet hat, gilt als fehlgeschlagen.

Die Übersicht#

Produkte → Sicherheitsereignisse → Übersicht ist die Seite, mit der das Produkt öffnet:

• Die offenen Fälle, die Ihnen zugewiesen sind, die offenen Fälle, die noch niemand übernommen hat, und die Playbook-Schritte, die auf Genehmigung warten; jede Zahl öffnet die Seite, die sie auflistet.
• Mittlere Zeit bis zur Bestätigung, Mittlere Zeit bis zur Eindämmung und Mittlere Zeit bis zum Schließen, über die in den letzten 30 Tagen eröffneten Fälle: von der Eröffnung eines Falls, bis jemand ihn übernimmt (eine Person zuweist oder ihn aus „Neu“ herausholt), bis „Contained“ und bis „Geschlossen“. Ein Fall, der noch wartet, geht in keinen Mittelwert ein.
• Die pro Tag eröffneten Fälle über 30 Tage, nach Priorität, und die pro Tag ausgelösten Erkennungen über 14 Tage, nach Quelle.
• Die offenen Fälle nach Priorität und nach Status, die Bewertungen der letzten 30 Tage, die ATT&CK-Taktiken hinter den Fällen, die am häufigsten ausgelösten Erkennungen und die Entitäten, die in den meisten Befunden vorkommen.

Darüber zeigt ein Streifen, wie Sicherheit eingerichtet ist: ihre Quellen, Erkennungen, Fälle und Playbooks, jeweils mit ihren Zahlen. Ein Projekt, das sie noch nicht eingerichtet hat, sieht dort Empfohlenes aktivieren und Testangriff senden; siehe Erste Schritte mit Sicherheit. Braucht nichts jemanden, sagt die Seite Alles ruhig, und die Diagramme erscheinen, sobald es etwas darzustellen gibt.

Bedrohungen finden#

• Entitäten ordnet die Benutzer, Hosts, Adressen und Hashes, die Ihre Befunde am häufigsten nennen, über den letzten Tag, die letzte Woche oder den letzten Monat, und schlägt jeden Wert in den Ereignissen von 30 Tagen nach.
• Rule Library enthält fertige Erkennungsregeln für Bedrohungen rund um Identität, Endpunkte, Cloud, Netzwerk, Web und Kubernetes. Jede ist eine Sigma-Regel, geschrieben für die Felder, auf die jede verbundene Quelle normalisiert wird. Regel hinzufügen legt sie als Ihre eigene Erkennungsregel an, eingeschaltet und so eingestellt, dass sie Fälle statt Warnungen eröffnet; ändern Sie sie unter Erkennungsregeln wie jede andere. Die mit Empfohlen markierten Regeln finden Bedrohungen in Daten, die Status200 bereits hat, und eine Schaltfläche fügt die hinzu, die Ihnen noch fehlen.
• ATT&CK Coverage zeichnet die Matrix von MITRE ATT&CK, hebt die Techniken hervor, die Ihre aktivierten Regeln abdecken, und umrandet die, die eine Regel aus der Bibliothek abdecken würde.

Automatisieren#

• Arbeitsabläufe: Ein Fall oder eine Notiz kann einen Workflow starten, wenn er oder sie erstellt, aktualisiert oder gelöscht wird. Ein Schritt Run a workflow startet einen Workflow, dessen Trigger ein Webhook ist.
• API: Fälle, Notizen, Erkennungen, Playbooks, Ausführungen und geschützte Entitäten haben dieselbe REST-API wie der Rest von Status200, unter /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run und /security-protected-entity. Siehe API-Referenz.
• KI-Agenten: Der MCP-Server hat Werkzeuge für Fälle, Notizen, Erkennungen und Playbooks. Siehe MCP-Server.

Fehlerbehebung#

Nächste Schritte#