Types d'intégration à Data Exchange Layer

Les interactions avec la structure DXL reposent sur deux rôles principaux : les consommateurs d'informations et les fournisseurs d'informations.

Consommateurs d'informations

Les consommateurs reçoivent les informations transmises sur la structure DXL par le biais de ses divers modèles de communication.

Abonné aux événements

Un consommateur basé sur les événements s'abonne à des sujets et reçoit passivement les événements envoyés par les diffuseurs (mode de communication un à plusieurs). Scénarios d'utilisation courants qui tirent parti des intégrations reposant sur un abonnement aux événements :

  • Orchestration — Un client écoute un ensemble spécifique d'événements. Lors de la réception d'un événement, un workflow d'orchestration est initié. Par exemple, un produit de sécurité détecte qu'un terminal particulier envoie des données à une cible de commande et de contrôle connue et envoie en réaction un événement à la structure DXL. Un client qui écoute cet événement particulier initie un workflow d'orchestration qui déclenche un processus de correction faisant appel à d'autres produits connectés à la structure.

Invocateur de services

Il s'agit d'un client qui invoque des méthodes sur les services enregistrés sur la structure DXL, et demande activement des informations au service (mode de communication un à un). Scénarios d'utilisation courants qui tirent parti des intégrations reposant sur l'invocation de services :

  • Collecte de données — Les services de sécurité sont invoqués sur la structure DXL pour les demandes d'informations en temps réel (p. ex. les processus en cours d'exécution, etc.) ou les analyses basées sur l'investigation numérique.
  • Orchestration — Dans le cadre d'un workflow d'orchestration, divers services de sécurité sont invoqués à des fins de collecte de données, d'analyse et de correction.

Fournisseur d'informations

Ces fournisseurs distribuent des informations à la structure DXL par le biais de ses divers modèles de communication.

Diffuseurs d'événements

Il s'agit d'un client qui publie régulièrement des événements sur des sujets spécifiques enregistrés sur la structure DXL (mode de communication un à plusieurs). Ces événements sont communiqués aux consommateurs actuellement abonnés à ces sujets. Scénarios d'utilisation courants qui tirent parti des intégrations reposant sur la publication d'événements :

  • Événements de menace — Les événements sont envoyés à la structure pour indiquer la présence d'une menace (p. ex. un logiciel malveillant détecté sur un terminal particulier).
  • Événements informationnels — Les événements sont envoyés à la structure pour annoncer une information spécifique (p. ex. une nouvelle vulnérabilité a été publiée, un utilisateur s'est connecté à un système, etc.).

Fournisseurs de services

Il s'agit d'un client qui enregistre un service sur la structure DXL. Un service est composé d'une ou plusieurs méthodes exposées via les sujets correspondants. Ces méthodes de service sont invoquées par les clients en envoyant un message de requête à un sujet associé à une méthode de service. Une fois le message reçu, le service répond en envoyant un message de réponse au client invocateur par le biais de la structure (mode de communication un à un). Modèles d'intégration de services courants :

  • Service natif — Service développé avec une intégration native à la structure DXL. Par exemple, McAfee Threat Intelligence Exchange prend en charge les communications avec la structure DXL de façon native.
  • Service enveloppé — Un enveloppeur de services DXL est créé pour déléguer les invocations à l'API/au SDK d'un service existant. Par exemple, un service de sécurité qui expose une API REST peut facilement être enveloppé par un enveloppeur de services DXL pour fournir ses fonctionnalités sur la structure DXL.