Domain Separation und Security Incident Response

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 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.

    Supportstufe: Standard

    • Enthält alle Aspekte von Standard Level-Support.
    • Anwendungseigenschaften sind nach Bedarf domänenbasiert.
    • 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.

    Beispiel-Anwendungsfall: Ein Administrator muss in der Lage sein, Kommentare beim Schließen eines Datensatzes für einen Mandanten obligatorisch zu machen, für andere hingegen nicht.

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

    Übersicht

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

    Tabelle : 1. Unterstützung der Domänentrennung in Release „Reaktion auf Security Incidents nach Version“
    Freigeben Supportstufe Hinweise
    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 einzelnen 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 ResponseDie 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
      • Konfigurationselement anreichern
      • 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 Incidents 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.
    • Knowledge Base-Artikel und Ausführungsbücher werden in der Domäne des Security Incidents referenziert.
    • Metriken für die Reaktion auf Security Incidents, die für Incidents in der Domäne relevant sind, werden in Dashboards sowie in Berichten 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 der Reaktion auf Security Incidents

    Die Security Incident ResponseDie 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 Kunden-SOC oder im MSP zur Reaktion:
      • E-Mail-Parser (plattformbasiert, von Anwendern gemeldetes Phishing, anwenderdefiniert)
      • Deduplizierungsereignisse/Warnungen vor der Incident-Erstellung
      • Automatische Extraktion von erkennbaren Elementen
      • Anwendungen im SIEM-Store von Drittparteien
    • 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 ihrer 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 am 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

    Setup der Domänentrennung

    Domänentrennung für wird eingerichtet Security Incident ResponseErfordert keine zusätzlichen Schritte. Alle Security Incident ResponseTabellen beziehen die Domänenspalte, nachdem die Instanz durch Domänen getrennt wurde.

    Domänengetrennte Daten

    Daten können domänengetrennt werden, d. h.:

    • 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 Drittpartei-Integrationen 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 Funktionen für Vorstufen-Fähigkeiten beschrieben), die aufgerufen werden, bleiben domänenübergreifend generisch, wobei die domänenspezifische Implementierung der aufgerufenen Fähigkeit erfolgt. Beispielsweise kann eine Sichtungssuche für eine 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 ihre eigenen Incident-Kategorien, Knowledge Base-Artikel und Runbooks für die Reaktion auf Incidents erstellen, die den Workflows für die Reaktion auf Incidents zugeordnet werden sollen.
    • Mandantendomänenanwender erstellen und schließen ihre eigenen Security Incidents.

    Geschäftslogik und Prozesse, die vom Instanzbesitzer domänengetrennt werden können

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