Schritt 5. Entwickeln und Testen von Anwendungsfällen

Gilt für:

• Microsoft Defender XDR

Die empfohlenen Methoden zum Bereitstellen Microsoft Defender XDR in Ihrem Security Operations Center (SOC) hängen von den aktuellen Tools, Prozessen und Fähigkeiten des SOC-Teams ab. Die Aufrechterhaltung von Cyber-Hygiene auf verschiedenen Plattformen kann aufgrund der großen Menge an Daten aus Dutzenden, wenn nicht gar Hunderten von Sicherheitsquellen eine Herausforderung darstellen.

Sicherheitstools sind miteinander verbunden. Das Aktivieren eines Features in einer Sicherheitstechnologie oder das Ändern eines Prozesses kann wiederum eine andere beeinträchtigen. Aus diesem Grund empfiehlt Microsoft, dass Ihr SOC-Team eine Methode zum Definieren und Priorisieren von Anwendungsfällen formalisiert. Anwendungsfälle helfen beim Definieren von Anforderungen und Testprozessen für SOC-Vorgänge in verschiedenen Teams. Es wird eine Methodik zum Erfassen von Metriken erstellt, um zu bestimmen, ob die richtigen Rollen und Aufgabenkombinationen am richtigen Team mit den richtigen Fähigkeiten ausgerichtet sind.

Entwickeln und Formalisieren eines Anwendungsfallprozesses

Das SOC sollte einen allgemeinen Standard und Prozess für die Entwicklung von Anwendungsfällen definieren, die vom SOC-Aufsichtsteam reguliert werden. Das SOC-Aufsichtsteam sollte mit Ihrem Unternehmen, ihrer IT, Ihrem Recht, Ihrer Personalabteilung und anderen Gruppen zusammenarbeiten, um Anwendungsfälle für das SOC zu priorisieren, die schließlich in die Runbooks und Playbooks des SOC-Teams gelangen. Die Priorität von Anwendungsfällen basiert auf Zielen wie Compliance oder Datenschutz.

Zu den SOC-Aufsichtsaktivitäten im Zusammenhang mit der Entwicklung von Anwendungsfällen gehören:

• Anforderungen
• Personal- oder Schulungsbedarf
• Softwarelizenzen
• Kreditorenvertrag
• Verwalten eines Plans
• Verwalten der Anwendungsfallregistrierung
• Verwalten/Aktualisieren von Vorlagen

Um die Erstellungsprozesse für Runbooks und Playbooks zu vereinfachen, erstellen Sie eine Entscheidungsstruktur für Anwendungsfälle. Diese Abbildung zeigt ein Beispiel.

Nachdem ein allgemeiner Anwendungsfallstandard definiert und genehmigt wurde, besteht der nächste Schritt darin, einen tatsächlichen Anwendungsfall zu erstellen und zu testen. In den folgenden Abschnitten werden Antiphishing- und Bedrohungs- und Sicherheitsrisikoüberprüfungsszenarien als Beispiele verwendet.

Anwendungsfallbeispiel 1: Neue Phishing-Variante

Der erste Schritt beim Erstellen eines Anwendungsfalls besteht darin, den Workflow mithilfe eines Storyboards zu beschreiben. Hier ist ein Beispiel für ein allgemeines Storyboard für eine neue Phishing-Exploit-Benachrichtigung an ein Threat Intelligence-Team.

Aufrufen des Anwendungsfallworkflows für Beispiel 1

Nachdem das Storyboard genehmigt wurde, besteht der nächste Schritt darin, den Anwendungsfallworkflow aufzurufen. Hier ist ein Beispielprozess für eine Anti-Phishing-Kampagne.

Anwendungsfallbeispiel 2: Bedrohungs- und Sicherheitsrisikoüberprüfung

Ein weiteres Szenario, in dem ein Anwendungsfall verwendet werden könnte, ist die Überprüfung auf Bedrohungen und Sicherheitsrisiken. In diesem Beispiel erfordert das SOC, dass Bedrohungen und Sicherheitsrisiken für Ressourcen über genehmigte Prozesse behoben werden, die das Scannen von Ressourcen umfassen.

Hier ist ein Beispiel für ein Storyboard auf hoher Ebene für die Microsoft Defender Vulnerability Management von Ressourcen.

Aufrufen des Anwendungsfallworkflows für Beispiel 2

Hier ist ein Beispielprozess für die Überprüfung von Bedrohungen und Sicherheitsrisiken.

Analysieren der Anwendungsfallausgabe und der gewonnenen Erkenntnisse

Nachdem ein Anwendungsfall genehmigt und getestet wurde, sollten Lücken zwischen Ihren Sicherheitsteams sowie Personen, Prozessen und den beteiligten Microsoft Defender XDR Technologien identifiziert werden. Microsoft Defender XDR Technologien sollten analysiert werden, um festzustellen, ob sie in der Lage sind, die gewünschten Ergebnisse zu erzielen. Diese können über eine Checkliste oder eine Matrix nachverfolgt werden.

Im Beispiel für das Antiphishingszenario hätten die SOC-Teams beispielsweise die Ermittlungen in dieser Tabelle vorgenommen.

SOC-Team	Anforderung	Personen, um die Anforderung zu erfüllen	Prozess zur Erfüllung der Anforderung	Relevante Technologie	Lücke identifiziert	Änderungsprotokoll für Den Anwendungsfall	Ausgenommen (Y/N)
Threat Intelligence- und Analyseteam	Datenquellen versorgen die Threat Intelligence-Engines ordnungsgemäß.	Threat Intelligence Analyst/Engineer	Festgelegte Datenfeedanforderungen, Threat Intelligence-Trigger aus genehmigten Quellen	Microsoft Defender for Identity, Microsoft Defender for Endpoint	Das Threat Intelligence-Team hat kein Automatisierungsskript verwendet, um Microsoft Defender XDR API mit Bedrohungs-Intel-Engines zu verknüpfen.	Hinzufügen von Microsoft Defender XDR als Datenquellen zu Bedrohungs-Engines Aktualisieren des Anwendungsfall-Ausführungsbuchs	N
Überwachungsteam	Datenquellen stellen die Überwachungsdashboards ordnungsgemäß bereit.	Tier 1,2 SOC Analyst–Monitoring & Alerts	Workflow zum Melden der Sicherheitsbewertung & Compliance Center	Untersuchen von Warnungen in Microsoft Defender XDR Überwachung der Sicherheitsbewertung	Kein Mechanismus für SOC-Analysten, um eine erfolgreiche Erkennung neuer Phishingvarianten zu melden, um die Sicherheitsbewertung zu verbessern Anzeigen von E-Mail-Sicherheitsberichten im Microsoft Defender-Portal	Hinzufügen eines Prozesses zum Nachverfolgen der Verbesserung der Sicherheitsbewertung zu Berichtsworkflows	N
Engineering- und SecOps-Team	Änderungssteuerungsupdates werden in den SOC-Team-Runbooks vorgenommen.	Tier 2 SOC Engineer	Änderungssteuerungsbenachrichtigungsverfahren für SOC-Teamrunbooks	Genehmigte Änderungen an Sicherheitsgeräten	Änderungen an Microsoft Defender XDR Konnektivität mit SOC-Sicherheitstechnologie erfordern eine Genehmigung	Hinzufügen von Microsoft Defender for Cloud Apps, Defender for Identity, Defender für Endpunkt, Security & Compliance Center zu SOC-Runbooks	J

Darüber hinaus hätten die SOC-Teams die in der folgenden Tabelle beschriebenen Ermittlungen im Zusammenhang mit dem oben beschriebenen Defender-Sicherheitsrisikomanagement-Szenario machen können:

SOC-Team	Anforderung	Personen, um die Anforderung zu erfüllen	Prozess zur Erfüllung der Anforderung	Relevante Technologie	Lücke identifiziert	Änderungsprotokoll für Den Anwendungsfall	Ausgenommen (Y/N)
SOC-Aufsicht	Alle Ressourcen, die mit genehmigten Netzwerken verbunden sind, werden identifiziert und kategorisiert.	SOC-Aufsicht, BU-Besitzer, Anwendungsbesitzer, BESITZER VON IT-Ressourcen usw.	Zentralisiertes Asset Management-System zum Ermitteln und Auflisten von Ressourcenkategorien und -attributen basierend auf dem Risiko.	ServiceNow oder andere Ressourcen. Microsoft 365-Gerätebestand	Nur 70 % der Ressourcen wurden ermittelt. Microsoft Defender XDR Wartungsnachverfolgung nur für bekannte Ressourcen wirksam	Ausgereifte Ressourcenlebenszyklusverwaltungsdienste, um sicherzustellen, dass Microsoft Defender XDR eine 100%ige Abdeckung hat	N
Engineering & SecOps Teams	Hohe Auswirkungen und kritische Sicherheitsrisiken in Ressourcen werden gemäß der Richtlinie behoben.	SecOps-Techniker, SOC-Analysten: Sicherheitsrisiken & Compliance, Sicherheitstechnik	Definierter Prozess zum Kategorisieren von Sicherheitsrisiken mit hohem Risiko und kritischen Sicherheitsrisiken	Microsoft Defender Vulnerability Management Dashboards	Defender für Endpunkt hat geräte mit hoher Warnung mit hohen Auswirkungen ohne Wartungsplan oder Implementierung der von Microsoft empfohlenen Aktivität identifiziert.	Fügen Sie einen Workflow zum Benachrichtigen von Ressourcenbesitzern hinzu, wenn eine Wartungsaktivität innerhalb von 30 Tagen pro Richtlinie erforderlich ist. Implementieren Sie ein Ticketsystem, um Besitzer von Ressourcen über Korrekturschritte zu benachrichtigen.	N
Überwachen von Teams	Bedrohungs- und Sicherheitsrisiko-status werden über das Intranetportal des Unternehmens gemeldet.	SOC-Analyst der Ebene 2	Automatisch generierte Berichte aus Microsoft Defender XDR mit dem Fortschritt der Wiederherstellung von Ressourcen	Untersuchen von Warnungen in Microsoft Defender XDR Überwachung der Sicherheitsbewertung	Den Besitzern von Ressourcen werden keine Ansichten oder Dashboard Berichte über Bedrohungen und Sicherheitsrisiken status von Ressourcen mitgeteilt.	Create Automatisierungsskript, um status der Behebung von Sicherheitsrisiken mit hohem Risiko und kritischen Ressourcen auf dem organization aufzufüllen.	N

In diesen Beispielanwendungsfällen ergaben die Tests mehrere Lücken in den Anforderungen des SOC-Teams, die als Baselines für die Zuständigkeiten der einzelnen Teams festgelegt wurden. Die Checkliste für Anwendungsfälle kann so umfassend wie nötig sein, um sicherzustellen, dass das SOC-Team auf die Microsoft Defender XDR Integration mit neuen oder vorhandenen SOC-Anforderungen vorbereitet ist. Da es sich hierbei um einen iterativen Prozess handelt, dienen der Entwicklungsprozess für Anwendungsfälle und der Inhalt der Anwendungsfallausgabe natürlich dazu, die Runbooks des SOC mit den gewonnenen Erkenntnissen zu aktualisieren und weiterzuentwickelten.

Aktualisieren von Produktionsrunbooks und Playbooks

Nachdem die Anwendungsfalltests für alle Lücken behoben wurden, können die daraus gewonnenen Erkenntnisse und metriken in die Produktionsrunbooks (Betriebsprozesse) und Playbooks (Reaktion auf Vorfälle und Eskalationsverfahren) Ihres SOC-Teams integriert werden.

Die Wartung der SOC-Teamrunbooks und Playbooks kann auf vielfältige Weise organisiert werden. Jedes SOC-Team ist möglicherweise für sein eigenes Team verantwortlich, oder es gibt eine einzige zentralisierte Version, die alle Teams in einem zentralen Repository freigeben können. Die Runbook- und Playbookverwaltung für einzelne Organisationen basiert auf Größe, Qualifikation, Rollen und Aufgabentrennung. Nachdem ein Runbook aktualisiert wurde, sollte der Playbook-Updateprozess folgen.

Verwenden eines Standardframeworks für die Eskalation

Playbooks sind die Schritte, die die SOC-Teams befolgen müssen, wenn ein echtes Ereignis eintritt, basierend auf der erfolgreichen Integration und dem Test des Anwendungsfalls. Daher ist es unerlässlich, dass der SOC einen formalisierten Ansatz für die Reaktion auf Vorfälle verfolgt, z. B. den NIST Incident Response Standard , der zu einem der führenden Branchenstandards für die Reaktion auf Vorfälle geworden ist.

Der NIST-Prozess zur Reaktion auf Vorfälle in vier Schritten umfasst vier Phasen:

1. Vorbereitung
2. Erkennung und Analyse
3. Eindämmung, Auflösung und Wiederherstellung
4. Aktivitäten nach dem Vorfall

Beispiel: Aktivität der Nachverfolgung der Vorbereitungsphase

Eine der Wichtigsten Grundlagen eines Eskalationsplaybooks besteht darin, sicherzustellen, dass es wenig Mehrdeutigkeit darüber gibt, was jedes SOC-Team vor, während und nach einem Ereignis oder Incident tun soll. Daher empfiehlt es sich, schritt-für-Schritt-Anweisungen aufzulisten.

Beispielsweise könnte die Vorbereitungsphase eine if/then- oder XoR-Matrix von Aufgaben enthalten. Im Fall des neuen Beispielanwendungsfalls für Phishingvarianten könnte eine solche Matrix wie folgt aussehen:

Warum ist eine Eskalation gerechtfertigt?	Nächster Schritt
Warnung in DER SOC-Überwachung als kritisch eingestuft >500/Stunde	Wechseln Sie zu Playbook A, Abschnitt 2, Aktivität 5 (mit einem Link zum Playbookabschnitt)
eCommerce hat einen potenziellen DDoS-Angriff gemeldet.	Aufrufen von Playbook B-Abschnitt C, Aktivität 19 (mit einem Link zum Playbookabschnitt)
Executive meldete eine verdächtige E-Mail als Spear-Phishing-Versuch	Wechseln Sie zu Playbook 5, Abschnitt 2, Aktivität 5 (mit einem Link zum Playbook-Abschnitt)

Nach dem Ausführen der Vorbereitungsphase sollten Organisationen die verbleibenden Phasen aufrufen, wie in NIST beschrieben:

• Erkennung und Analyse
• Eindämmung, Auflösung und Wiederherstellung
• Aktivitäten nach dem Vorfall

Nächster Schritt

Schritt 6: Identifizieren von SOC-Wartungstasks

Tipp

Möchten Sie mehr erfahren? Engage mit der Microsoft-Sicherheitscommunity in unserer Tech Community: Microsoft Defender XDR Tech Community.