Séparation de domaine et Réponse aux incidents de sécurité

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 9 minutes de lecture

    • L'application Séparation de domaine est prise en charge dans Réponse aux incidents de sécurité. Séparation de domaine vous permet de séparer les données, les processus et les tâches administratives en groupes logiques appelés domaines. Vous pouvez contrôler plusieurs aspects de cette séparation, notamment les utilisateurs qui peuvent voir les données et y accéder.

    Niveau de prise en charge : Standard

    • Inclut tous les aspects du support de niveau basique .
    • Les propriétés d'application sont sensibles au domaine selon les besoins.
    • Logique métier : le fournisseur de service (SP) crée ou modifie des processus par client. Les cas d'utilisation reflètent l'utilisation appropriée de l'application par plusieurs clients SP dans une seule instance.
    • Le propriétaire de l'instance doit configurer la logique métier et les paramètres de données du produit minimum viable (MVP) par locataire comme prévu pour l'application spécifique.

    Exemple de cas d’utilisation : un administrateur doit être en mesure de donner les commentaires appropriés lorsqu’un enregistrement se ferme pour un locataire, mais pas pour un autre.

    Pour en savoir plus sur les niveaux de prise en charge, consultez la rubrique Prise en charge de Séparation de domaine par les applications.

    Vue d'ensemble

    Dans l’application, Séparation Réponse aux incidents de sécurité de domaine permet aux fournisseurs de services (SP) de standardiser les procédures SOC (Security Operations Center) et Security Incident Response (SIR) sur l’ensemble de la base de clients qu’ils servent, avec des coûts opérationnels réduits et une meilleure qualité de service. Séparer les espaces de travail des clients pour les workflows, les tableaux de bord, les rapports, etc., garantit que les données client sont séparées et ne sont jamais exposées à d’autres clients.

    Tableau 1. Prise en charge de Domain Separation dans Security Incident Response par version et versions
    Mise en production Niveau de prise en charge Notes
    Genève, Helsinki Aucune prise en charge Lancement de la séparation de domaine au niveau des données
    Istanbul Les données uniquement
    Jakarta Niveau 2 (données, demandeur, prestataire) Nouvelles fonctionnalités : prise en charge des intégrations tierces avec séparation de domaine de niveau 2 dans une instance unique d’intégration, y compris les intégrations Threat Intelligence
    Kingston Niveau 2 (données, demandeur, prestataire) Nouvelles fonctionnalités : l’intégration de la recherche de perceptions pour SIR est activée avec plusieurs instances, mais toutes les instances sont toujours hébergées sous un seul domaine. Exemple : si deux instances d’une intégration Splunk sont configurées (SplunkCLOUD et SplunkCORP), les deux sont toujours exploitées pour les activités de réponse aux incidents dans un seul domaine, où l’implémentation a été configurée à l’origine.
    Londres Niveau 2 (données, demandeur, prestataire) Nouvelles fonctionnalités : toutes les intégrations résident dans plusieurs domaines
    Madrid Niveau 2 (données, demandeur, prestataire) Toutes les intégrations peuvent désormais résider dans plusieurs domaines. Dans l’exemple ci-dessus, SplunkCloud peut être domaine1 et SplunkCORP domaine2.
    New York Niveau 2 (données, demandeur, prestataire) Toutes les intégrations résident dans plusieurs domaines.
    Orlando Standard Toutes les intégrations résident dans plusieurs domaines.
    Paris Standard Toutes les intégrations résident dans plusieurs domaines.

    Séparation de domaine pour l’application Réponse aux incidents de sécurité couvre les fonctionnalités de produit suivantes :

    • Les alertes de sécurité sont dirigées vers le domaine approprié de l’utilisateur dont l’ID/les informations d’identification ou le champ d’application génère l’incident et qui est enregistré comme incident de sécurité.
    • Les alertes génèrent des « observables », qui représentent des propriétés avec état ou des événements mesurables : les workflows de sécurité dans le domaine de l’incident de sécurité sont utilisés pour orchestrer la réponse.
    • Les intégrations sont configurées dans le domaine de l’incident de sécurité pour l’automatisation des réponses.
    • Les options sont configurées dans le domaine de l’incident de sécurité pour l’automatisation des réponses. Ces fonctionnalités (à partir de la version Kingston) comprennent :
      • Recherche de menace
      • Enrichir l'observable
      • Enrichir l’élément de configuration
      • Obtenir les processus d'exécution
      • Obtenir les statistiques réseau
      • Bloquer la demande
      • Isoler l'hôte
      • Recherche de perception
      • Recherche et suppression d'e-mails
      • Publier dans la liste de surveillance
    • Les résultats de l’automatisation des réponses (telles que la recherche de menaces ou la recherche de perception) sont stockés dans le domaine de l’incident de sécurité.
    • D’autres incidents de sécurité sont recoupés dans le même domaine de l’incident de sécurité en fonction d’un ensemble partagé d’observables.
    • Les autres utilisateurs sont référencés dans le domaine de l’incident de sécurité.
    • Les éléments de configuration sont référencés dans le même domaine que l’incident de sécurité.
    • Des tâches de réponse manuelle sont ajoutées au domaine de l’incident de sécurité.
    • Les articles de la base de connaissances et les guides d’exploitation sont référencés dans le domaine de l’incident de sécurité.
    • Les mesures de Réponse aux incidents de sécurité pertinentes pour les incidents dans le domaine sont affichées sur les tableaux de bord ainsi que dans les rapports.
    Remarque :
    Dans les cas précédents, les principes généraux de la visibilité dans des domaines séparés dans la NOW Platform s’appliquent. Comme toujours, un incident dans le domaine parent peut faire référence à des artefacts dans le domaine enfant, mais pas l’inverse.

    Fonctionnement de Séparation de domaine dans Security Incident Response

    L’application Réponse aux incidents de sécurité gère le cycle de vie d’un incident de sécurité de bout en bout. Les cas d’utilisation suivants sont sensibles à la séparation de domaine :

    • Ingestion d’événements et d’alertes pour créer des incidents de sécurité auxquels l’analyste du SOC client ou le MSP doit répondre :
      • Analyseurs d’e-mails (basés sur la plateforme, hameçonnage signalé par un utilisateur, personnalisés)
      • Événements/alertes de déduplication avant la création de l’incident
      • Extraction automatique des observables
      • Applications dans le magasin SIEM tiers
    • Enrichissement des artefacts impliqués dans les incidents (IP, URL, domaines, hachages de fichiers) :
      • Enrichissement des actifs (CMDB)
      • Utilisateurs (plateforme)
      • Automatisation : enrichissement des observables (p. ex. : WhoIs)
    • Enquêter sur les incidents à l’aide des artefacts et sur leur réputation ou leur association avec des menaces connues
      • Orchestrer : Playbooks et articles de la base de connaissances
      • Automatisation : recherche de menaces (ex : VirusTotal), recherche de perception (ex : Splunk), obtenir les processus en cours d’exécution (ex : Carbon Black)
    • Éradiquez les artefacts liés aux menaces impliqués dans l’incident sur la base de l’enquête effectuée
      • Orchestrer : Playbooks et articles de la base de connaissances
      • Automatisation : recherche et suppression d’e-mails (ex : Microsoft Exchange), bloquer IP (ex : pare-feu Palo Alto)
    • Mesurer l’efficacité des opérations de réponse aux incidents
      • Tableaux de bord Performance Analytics : productivité et tendances des incidents
      • Reconstitution des étapes d’enquête sur les incidents à partir des notes de travail
      • Examen post-incident

    Configuration de Domain Separation

    La configuration de Séparation de domaine pour Réponse aux incidents de sécurité ne nécessite aucune étape supplémentaire. Toutes les Réponse aux incidents de sécurité tables acquièrent la colonne Domaine une fois que l’instance est séparée par domaine.

    Données séparées par domaine

    Les données peuvent être séparées par domaine, ce qui signifie :

    • Les incidents de sécurité dans un domaine ne peuvent pas être visualisés à partir d’autres domaines.
    • Les observables extraits de l’incident de sécurité sont placés dans le même domaine et ne peuvent pas être visualisés à partir d’autres domaines.
    • Jusqu’à la version Kingston, des intégrations tierces configurées existent dans le domaine global et sont accessibles à tous les autres domaines de l’instance.
    • Dans la version Madrid, les intégrations tierces peuvent être configurées et activées pour chaque domaine. Cela signifie que l’intégration activée et configurée dans un domaine ne peut pas être exploitée dans un autre domaine.
    • Les automatisations qui s’exécutent sur les observables à l’aide d’intégrations tierces (pour l’examen, l’action de maîtrise ou l’éradication des menaces), placent leurs résultats dans le domaine de l’incident de sécurité et les résultats ne peuvent pas être consultés à partir d’un autre domaine.
    • Les workflows Orchestration créés dans un domaine ne sont pas visibles dans un autre domaine.
    • Les options (telles que délimitées dans la liste des fonctions d’options de préparation) qui sont invoquées restent génériques dans tous les domaines avec une implémentation spécifique au domaine de l’option appelée. Par exemple, une recherche de perception sur une adresse IP peut invoquer une implémentation Splunk dans un domaine et une implémentation QRadar dans un autre.

    Configuration

    Tous les aspects de la configuration du produit sont autonomes dans un environnement séparé par domaine. La configuration peut être adaptée à chaque domaine.
    Remarque :
    La logique métier et les processus dans #2-5 ci-dessous peuvent être administrés dans le domaine du locataire.

    Les tâches suivantes doivent être configurées :

    1. Administration système
    2. Administration du Réponse aux incidents de sécurité
    3. Paramètres d’e-mail de l’incident de sécurité
    4. Paramètres du Playbook pour les incidents de sécurité
    5. Configurations d’aptitudes

    Comment les domaines des locataires gèrent leurs propres données d’application

    • Les propriétaires de domaines du locataire créent leurs propres règles d’analyse des e-mails pour l’ingestion des incidents de sécurité.
    • Les propriétaires de domaines locataires peuvent configurer des intégrations spécifiques exclusivement destinées à être utilisées dans le domaine.
    • Les propriétaires de domaines du locataire peuvent créer leurs propres workflows de réponse aux incidents.
    • Les propriétaires de domaines du locataire peuvent créer leurs propres catégories d’incidents, articles de la base de connaissances de réponse aux incidents et runbooks à associer aux workflows de réponse aux incidents.
    • Les utilisateurs du domaine locataire créent et ferment leurs propres incidents de sécurité.

    Logique métier et processus pouvant être séparés par domaine par le propriétaire de l’instance

    • Réponse aux incidents de sécurité Utilisateurs et groupes
    • Réponse aux incidents de sécurité intégrations (à partir de la version Madrid)
    • Règles d’analyse des e-mails pour la création d’incidents
    • Règles métier pour consolider plusieurs événements ou alertes dans un incident de sécurité
    • Workflows pour l’orchestration de la réponse aux incidents
    • Calculateurs de score de risque d’incidents de sécurité
    • Chemin d’escalade des incidents de sécurité
    • SLA d’incidents de sécurité
    • Définitions de processus d’incidents de sécurité
    • Processus de revue post-incident de l’incident de sécurité