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.

    Support-Stufe: Standard

    • Umfasst alle Aspekte des Basis -Supports.
    • 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.

    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 die Domänentrennung.

    Übersicht

    In der Anwendung Security Incident Response können Service Provider (SPs) durch Domänentrennung SOC- (Security Operations Center) und Security Incident Response-Verfahren (SIR) im gesamten Kundenstamm standardisieren, was zu niedrigeren Betriebskosten und höherer Servicequalität führt. Separate Kundenarbeitsbereiche für Workflows, Dashboards, Berichte usw. stellen sicher, dass Kundendaten getrennt und niemals für andere Clients verfügbar sind.

    Tabelle : 1. Unterstützung für Domänentrennung in Security Incident Response nach Versionsreleases
    Release Support-Stufe Notizen
    Genf, Helsinki Kein Support Initiierung der Domänentrennung auf Datenebene
    Istanbul Nur Daten
    Jakarta Ebene 2 (Daten, Anforderer, Erfüller) Neue Funktionen: Unterstützung für Integrationen von Drittparteien mit Domänentrennung der Ebene 2 unter einer einzigen Integrationsinstanz, einschließlich Threat Intelligence-Integrationen
    Kingston Ebene 2 (Daten, Anforderer, Erfüller) Neue Funktionen: Die Integration der Sichtungssuche für SIR ist mit mehreren Instanzen aktiviert, aber alle Instanzen befinden sich weiterhin unter einer einzigen Domäne. Beispiel: Wenn zwei Instanzen einer Splunk-Integration konfiguriert sind (SplunkCLOUD und SplunkCORP), werden beide weiterhin für Aktivitäten zur Reaktion auf Incidents in einer einzelnen Domäne genutzt, in der die Implementierung ursprünglich konfiguriert wurde.
    London Ebene 2 (Daten, Anforderer, Erfüller) Neue Funktionen: Alle Integrationen befinden sich in mehreren Domänen
    Madrid Ebene 2 (Daten, Anforderer, 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, Anforderer, Erfüller) Alle Integrationen befinden sich in mehreren Domänen.
    Orlando Standard Alle Integrationen befinden sich in mehreren Domänen.
    Paris Standard Alle Integrationen befinden sich in mehreren Domänen.

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

    • Sicherheitswarnungen werden an die entsprechende Domäne des Benutzers weitergeleitet, dessen ID/Anmeldeinformationen/Umfang den Incident generiert und als Security Incident registriert ist.
    • Warnungen generieren „observables“ – zustandsbehaftete Eigenschaften oder messbare Ereignisse: Sicherheits-Workflows in der Domäne des Security Incident werden verwendet, um die Reaktion zu orchestrieren.
    • Integrationen werden in der Domäne des Security Incident für die Reaktionsautomatisierung konfiguriert.
    • Fähigkeiten werden in der Domäne des Security Incident für die Reaktionsautomatisierung konfiguriert. Diese Fähigkeiten (ab dem Kingston-Release) umfassen:
      • Bedrohungssuche
      • Erkennbares Element ergänzen
      • Configuration Item ergänzen
      • Laufenden Prozess abrufen
      • Netzwerkstatistiken abrufen
      • Anforderung blockieren
      • Host isolieren
      • Sichtungssuche
      • E-Mails suchen und löschen
      • In Beobachtungsliste veröffentlichen
    • Ergebnisse aus der automatisierten Reaktion (z. B. Bedrohungssuche oder Sichtungssuche) werden in der Domäne des Security Incidents gespeichert.
    • Andere Security Incidents werden in derselben Domäne wie der Security Incident anhand eines gemeinsam genutzten Satzes von erkennbaren Elementen miteinander verknüpft.
    • Es wird auf andere Benutzer in der Domäne des Security Incident verwiesen.
    • Auf Konfigurationselemente wird in derselben Domäne wie der Security Incident verwiesen.
    • Der Domäne des Security Incident werden manuelle Antwortaufgaben hinzugefügt.
    • In der Domäne des Security Incident wird auf Knowledge Base-Artikel und Runbooks verwiesen.
    • Security Incident Response-Metriken, die für Incidents in der Domäne relevant sind, werden sowohl in Dashboards als auch in Berichten angezeigt.
    Hinweis:
    In den obigen Fällen gelten die übergeordneten Prinzipien der Transparenz 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.

    So funktioniert Domain Separation in Security Incident Response

    Die Anwendung Security Incident Response verwaltet den Lebenszyklus eines -Security Incidents durchgängig. Die folgenden Anwendungsfälle berücksichtigen die Domänentrennung:

    • Erfassung von Ereignissen und Warnungen, um Security Incidents zu erstellen, auf die der Analyst im SOC des Kunden oder im MSP reagieren kann:
      • 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 (Beispiel: WhoIs)
    • Untersuchen Sie die Incidents mithilfe der Artefakte und ihrer Reputation oder ihrer 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 Sie die am Incident beteiligten Bedrohungsartefakte basierend auf der durchgeführten Untersuchung
      • Orchestrieren: Playbooks und Knowledge Base-Artikel
      • Automatisierung: E-Mails suchen und löschen (Beispiel: Microsoft Exchange), IP blockieren (Beispiel: Palo Alto Firewall)
    • Effizienz von Vorgängen bei der Reaktion auf Incidentsmessen
      • Performance Analytics-Dashboards: Produktivitäts- und Incident-Trends
      • Rekonstruktion von Incident-Untersuchungsschritten aus Arbeitsnotizen
      • Überprüfung nach Incident

    Domänentrennung – Einrichtung

    Das Einrichten von Domain Separation für Security Incident Response erfordert keine zusätzlichen Schritte. Alle Security Incident Response -Tabellen erwerben die Spalte „Domäne“, nachdem die Instanz domänengetrennt wurde.

    Domänengetrennte Daten

    Daten können domänengetrennt sein. Das 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 sind für alle anderen Domänen in der Instanz zugänglich.
    • Im Madrid-Release können Drittanbieterintegrationen für einzelne Domänen einzeln 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 mithilfe von Drittanbieterintegrationen (für Bedrohungsuntersuchung, Eindämmung oder Beseitigung) für erkennbare Elemente ausgeführt werden, platzieren ihre Ergebnisse in der Domäne des Security Incidents, und die Ergebnisse können nicht in einer anderen Domäne angezeigt werden.
    • In einer Domäne erstellte Orchestration-Workflows sind in einer anderen Domäne nicht sichtbar.
    • Fähigkeiten (wie in der Funktionsliste der vorangegangenen Fähigkeiten beschrieben), die aufgerufen werden, bleiben domänenübergreifend generisch, mit einer domänenspezifischen Implementierung der aufgerufenen Fähigkeit. 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 eigenständig. Das Setup kann für einzelne Domänen angepasst werden.
    Hinweis:
    Geschäftslogik und die Prozesse in Nr. 2 bis 5 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

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

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

    • Security Incident Response Benutzer und Gruppen
    • Security Incident Response -Integrationen (ab Madrid-Release)
    • E-Mail-Analyseregeln für die Incident-Erstellung
    • Geschäftsregeln, um mehrere Ereignisse oder Warnungen in einem Security Incident zu konsolidieren
    • Workflows für die Orchestration der Reaktion auf Incidents
    • Rechner für Risikopunktzahl von Security Incidents
    • Eskalationspfad für Security Incidents
    • Security Incident-SLAs
    • Prozessdefinitionen für Security Incidents
    • Nachfolgeprüfungen von Security Incidents