Domain Separation und Security Incident Response

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 7 Minuten Lesedauer

    • Die Domänentrennung wird in Security Incident Response unterstützt. Mit der Domain Separation können Sie Daten, Prozesse und Verwaltungsaufgaben in logische Gruppierungen, sogenannte Domänen, aufteilen. Sie können verschiedene Aspekte dieser Trennung steuern, einschließlich der Benutzer, die Daten sehen und darauf zugreifen können.

    Support-Stufe: Standard

    • Enthält alle Aspekte von Standard Level-Support.
    • Anwendungseigenschaften sind bei Bedarf domänenfähig.
    • Geschäftslogik: Der Service Provider (SP) erstellt oder ändert Prozesse für einzelne Kunden. Die Anwendungsfälle spiegeln die ordnungsgemäße Verwendung der Anwendung durch mehrere SP-Kunden in einer einzigen Instanz wider.
    • Der Besitzer der Instanz muss die MVP-Geschäftslogik (Minimum des lebensfähigen Produkts) und die Datenparameter pro Mandant wie erwartet für die spezifische Anwendung konfigurieren.

    Beispielanwendungsfall: Ein Administrator muss in der Lage sein, erforderliche Kommentare abzugeben, wenn ein Datensatz für einen Mandanten geschlossen wird, aber nicht für einen anderen.

    Weitere Informationen zu den Supportstufen finden Sie unter Anwendungssupport für Domänentrennung.

    Übersicht

    In Security Incident Response Anwendungs- und Domänentrennung ermöglicht Service Providern (SPS) die Standardisierung von SOC-Verfahren (Security Operations Center) und Security Incident Response (SIR) im gesamten Kundenstamm, für den sie arbeiten, mit geringeren Betriebskosten und einer höheren Servicequalität. Separate Kundenarbeitsbereiche für Workflows, Dashboards, Berichte usw. stellen sicher, dass Kundendaten getrennt werden und niemals anderen Clients zugänglich gemacht werden.

    Tabelle : 1. Unterstützung der Domänentrennung in Security Incident Response nach Versionsveröffentlichungen
    Release Supportstufe Notizen
    Genf, Helsinki Kein Support Initiierung der Domänentrennung auf Datenebene
    Istanbul Nur Daten
    Jakarta Ebene 2 (Daten, Anfordernde Person, Erfüller) Neue Funktionen : Unterstützung von Drittanbieterintegrationen mit Domänentrennung der Ebene 2 unter einer einzigen Integrationsinstanz, einschließlich Threat Intelligence-Integrationen
    Kingston Ebene 2 (Daten, Anfordernde Person, Erfüller) Neue Funktionen : Die Integration der Sichtungssuche für SIR ist mit mehreren Instanzen aktiviert, aber alle Instanzen befinden sich weiterhin in einer einzigen Domäne. Beispiel: Wenn zwei Instanzen einer Splunk-Integration konfiguriert sind (SplunkCLOUD und SplunkCORP), werden beide noch für Incident-Antwortaktivitäten in einer einzigen Domäne genutzt, in der die Implementierung ursprünglich konfiguriert wurde.
    London Ebene 2 (Daten, Anfordernde Person, Erfüller) Neue Funktionen : Alle Integrationen befinden sich über mehrere Domänen hinweg
    Madrid Ebene 2 (Daten, Anfordernde Person, Erfüller) Alle Integrationen können sich jetzt über mehrere Domänen hinweg befinden. Im obigen Beispiel kann SplunkCloud domain1 und SplunkCORP domain2 sein.
    New York Ebene 2 (Daten, Anfordernde Person, Erfüller) Alle Integrationen befinden sich über mehrere Domänen hinweg.
    Orlando Standard Alle Integrationen befinden sich über mehrere Domänen hinweg.
    Paris Standard Alle Integrationen befinden sich über mehrere Domänen hinweg.

    Domänentrennung für Security Incident Response Die Anwendung deckt die folgenden Produktfunktionen ab:

    • Sicherheitswarnungen werden an die entsprechende Domäne des Anwenders weitergeleitet, dessen ID/Anmeldeinformationen/Umfang den Incident generiert und als Security Incident registriert ist.
    • Warnungen generieren „erkennbare Elemente“, die statusbehaftete Eigenschaften oder messbare Ereignisse darstellen: Sicherheits-Workflows in der Domäne des Security Incidents werden verwendet, um die Antwort zu orchestrieren.
    • Integrationen werden in der Domäne des Security Incidents für die Antwortautomatisierung konfiguriert.
    • Fähigkeiten werden in der Domäne des Security Incidents für die Antwortautomatisierung konfiguriert. Diese Fähigkeiten (ab Kingston-Release) umfassen:
      • Bedrohungssuche
      • Erkennbares Element ergänzen
      • Bereichern Sie das Konfigurationselement
      • Laufenden Prozess abrufen
      • Netzwerkstatistiken abrufen
      • Sperranforderung
      • Host isolieren
      • Sichtungssuche
      • E-Mails suchen und löschen
      • In Beobachtungsliste veröffentlichen
    • Ergebnisse aus der Antwortautomatisierung (z. B. Bedrohungssuche oder Sichtungssuche) werden in der Domäne des Security Incidents gespeichert.
    • Andere Security Incidents werden basierend auf einem gemeinsam genutzten Satz erkennbarer Elemente in derselben Domäne des Security Incidents referenziert.
    • Andere Anwender werden in der Domäne des Security Incident mit Querverweisen versehen.
    • Konfigurationselemente werden in derselben Domäne wie der Security Incident querreferenziert.
    • Manuelle Antwortaufgaben werden der Domäne des Security Incidents hinzugefügt.
    • In der Domäne des Security Incident wird auf Knowledge Base-Artikel und Ausführungsbücher verwiesen.
    • Security Incident Response-Metriken, die für Incidents in der Domäne relevant sind, werden in Dashboards sowie im Reporting angezeigt.
    Hinweis:
    In den vorherigen Fällen gelten die übergreifenden Prinzipien der Sichtbarkeit in getrennten Domänen in der NOW Platform. Wie immer kann ein Incident in der übergeordneten Domäne auf Artefakte in der untergeordneten Domäne verweisen, aber nicht umgekehrt.

    Funktionsweise der Domänentrennung in Security Incident Response

    Die Security Incident Response Die Anwendung verwaltet den Lebenszyklus eines Security Incidents von Ende bis Ende Die folgenden Anwendungsfälle sind auf Domänentrennung ausgerichtet:

    • Erfassung von Ereignissen und Warnungen So erstellen Sie Security Incidents für den Analysten im SOC des Kunden oder im MSP, um zu reagieren:
      • E-Mail-Parser (plattformbasiert, von Anwendern gemeldetes Phishing, anwenderdefiniert)
      • Deduplizierungsereignisse/Warnungen vor der Incident-Erstellung
      • Automatische Extraktion von erkennbaren Elementen
      • Anwendungen im SIEM-Store einer Drittpartei
    • Ergänzung Von Artefakten, die an den Incidents beteiligt sind (IP, URLs, Domänen, Datei-Hashes):
      • Asset-Ergänzung (CMDB)
      • Anwender (Plattform)
      • Automatisierung: Ergänzung erkennbarer Elemente (z. B. WHOIS)
    • Untersuchen Die Incidents mit Hilfe der Artefakte und ihre Reputation oder Zuordnung zu bekannten Bedrohungen
      • Orchestrieren: Playbooks und Knowledge Base-Artikel
      • Automatisierung: Bedrohungssuche (z. B. Virustotal), Sichtungssuche (z. B. Splunk), laufende Prozesse abrufen (z. B. Carbon Black)
    • Beseitigen Die bedrohungsbezogenen Artefakte, die an dem Incident beteiligt sind, basierend auf der durchgeführten Untersuchung
      • Orchestrieren: Playbooks und Knowledge Base-Artikel
      • Automatisierung: E-Mail-Suche und -Löschung (z. B. Microsoft Exchange), IP blockieren (z. B. Palo Alto Firewall)
    • Messen Die Vorgänge „Effizienz“ oder „Reaktion auf Incidents“
      • Performance Analytics-Dashboards: Produktivitäts- und Incident-Trends
      • Rekonstruktion von Incident-Untersuchungsschritten aus Arbeitsnotizen
      • Überprüfung nach Incident

    Domänentrennung – Einrichtung

    Domänentrennung für wird eingerichtet Security Incident Response Erfordert keine zusätzlichen Schritte. Alle Security Incident Response Tabellen beziehen die Domänenspalte, nachdem die Instanz domänengetrennt ist.

    Domänengetrennte Daten

    Daten können domänengetrennt sein, was bedeutet:

    • Security Incidents in einer Domäne können nicht in anderen Domänen angezeigt werden.
    • Aus dem Security Incident extrahierte erkennbare Elemente werden in derselben Domäne platziert und können nicht in anderen Domänen angezeigt werden.
    • Bis zum Kingston-Release sind konfigurierte Drittanbieterintegrationen in der globalen Domäne vorhanden und für alle anderen Domänen in der Instanz zugänglich.
    • Im Madrid-Release können Integrationen von Drittparteien pro Domäne konfiguriert und aktiviert werden. Dies bedeutet, dass die in einer Domäne aktivierte und konfigurierte Integration nicht in einer anderen Domäne genutzt werden kann.
    • Automatisierungen, die für die erkennbaren Elemente mithilfe von Drittanbieterintegrationen ausgeführt werden (für Bedrohungsuntersuchung, Eindämmung oder Beseitigung), platzieren ihre Ergebnisse in der Domäne des Security Incidents, und die Ergebnisse können nicht aus einer anderen Domäne angezeigt werden.
    • Orchestration-Workflows, die in einer Domäne erstellt wurden, sind in einer anderen Domäne nicht sichtbar.
    • Fähigkeiten (wie in der Liste der Preeding-Funktionen beschrieben), die aufgerufen werden, bleiben domänenübergreifend generisch, wobei die aufgerufene Fähigkeit domänenspezifisch implementiert wird. Beispielsweise kann eine Sichtungssuche auf einer IP eine Splunk-Implementierung in einer Domäne und eine QRadar-Implementierung in einer anderen Domäne aufrufen.

    Konfiguration

    Alle Aspekte der Produktkonfiguration sind in einer domänengetrennten Umgebung enthalten. Das Setup kann auf einzelne Domänen zugeschnitten werden.
    Hinweis:
    Die Geschäftslogik und die Prozesse in #2-5 unten können innerhalb der Mandantendomäne verwaltet werden.

    Die folgenden Aufgaben müssen konfiguriert werden:

    1. Systemverwaltung
    2. Security Incident Response -Administration
    3. E-Mail-Einstellungen für Security Incidents
    4. Playbook-Einstellungen für Security Incidents
    5. Fähigkeitskonfigurationen

    Wie Mandantendomänen ihre eigenen Anwendungsdaten verwalten

    • Mandantendomänenbesitzer erstellen eigene E-Mail-Analyseregeln für die Erfassung von Security Incidents.
    • Mandantendomänenbesitzer können bestimmte Integrationen ausschließlich für die Verwendung innerhalb der Domäne konfigurieren.
    • Mandantendomänenbesitzer können eigene Workflows für die Reaktion auf Incidents erstellen.
    • Mandantendomänenbesitzer können eigene Incident-Kategorien, Knowledge Base-Artikel und Runbooks für Incident-Antworten erstellen, die mit Incident-Response-Workflows verknüpft werden.
    • Mandantendomänenanwender erstellen und schließen ihre eigenen Security Incidents.

    Geschäftslogik und Prozesse, die nach Instanzbesitzern domänengetrennt werden können

    • Security Incident Response Anwender und Gruppen
    • Security Incident Response Integrationen (ab Madrid-Release)
    • E-Mail-Analyseregeln für die Incident-Erstellung
    • Geschäftsregeln zum Konsolidieren mehrerer Ereignisse oder Warnungen zu einem Security Incident
    • Workflows für die Orchestration der Reaktion auf Incidents
    • Security Incident-Risikopunktzahlrechner
    • Eskalationspfad für Security Incidents
    • Security Incident-SLAs
    • Security Incident-Prozessdefinitionen
    • Prozesse zur Überprüfung von Security Incidents nach Incidents