Integrationstypen des Data Exchange Layer

Die Interaktion mit der DXL-Struktur beinhaltet zwei primäre Rollen: Informationskonsumenten und Informationsanbieter.

Informationskonsumenten

Konsumenten empfangen Informationen über die zahlreichen Kommunikationsmodelle der DXL-Struktur.

Ereignisabonnent

Ein ereignisbasierter Konsument abonniert Themen und erhält passiv Ereignisse von Anbietern (1-zu-viele-Kommunikation). In folgenden üblichen Anwendungsszenarien werden Ereignisabonnent-Integrationen genutzt:

  • Koordination: Ein Client abonniert Meldungen zu einer bestimmten Art von Ereignissen. Sobald ein solches Ereignis empfangen wurde, wird ein Koordinations-Workflow gestartet. Dies ist zum Beispiel der Fall, wenn ein Sicherheitsprodukt erkennt, dass ein bestimmtes Endgerät Daten an ein bekanntes Befehls- und Steuerungsziel sendet und als Reaktion darauf ein Ereignis an die DXL-Struktur meldet. Ein Client, der die Information zu diesem bestimmten Ereignis erhält, startet einen Koordinations-Workflow und löst damit einen Problembehebungsprozess aus, bei dem andere in der Struktur verfügbare Produkte verwendet werden.

Service-aufrufende Instanz

Hierbei handelt es um einen Client, der Methoden bei Services abruft, die in der DXL-Struktur registriert sind. Dabei fragt er aktiv Informationen bei den Services an (1-zu-1-Kommunikation). In folgenden üblichen Anwendungsszenarien werden Service-Aufruf-Integrationen genutzt:

  • Datenerfassung: Sicherheits-Services werden über die DXL-Struktur abgerufen, um Informationen in Echtzeit (z. B. über laufende Prozesse) oder für Forensik-basierte Analysen abzufragen.
  • Koordination: Als Teil eines Koordinations-Workflows werden verschiedene Sicherheits-Services zum Zweck der Datenerfassung, Analyse und Problembehebung abgerufen.

Informationsanbieter

Diese Anbieter verteilen über die zahlreichen Kommunikationsmodelle Informationen an die DXL-Struktur.

Ereignisanbieter

Hierbei handelt es sich um einen Client, der in regelmäßigen Abständen Ereignisse zu bestimmten Themen in der DXL-Struktur veröffentlicht (1-zu-viele-Kommunikation). Diese Ereignisse werden an die Konsumenten übermittelt, die diese Themen derzeit abonniert haben. In folgenden üblichen Anwendungsszenarien werden Ereignisanbieter-Integrationen genutzt:

  • Bedrohungsereignisse: Ereignisse werden an die Struktur gemeldet, um so das Vorhandensein einer Bedrohung anzuzeigen (z. B. Malware auf einem bestimmten Endgerät).
  • Informative Ereignisse: Ereignisse werden an die Struktur gemeldet, um eine bestimmte Information anzukündigen (z. B. eine neu veröffentlichte Schwachstelle oder ein bei einem System angemeldeter Benutzer).

Service-Anbieter

Hierbei handelt es sich um einen Client, der einen Service in der DXL-Struktur registriert. Ein Service besteht aus einer oder mehreren Methoden, die über entsprechende Themen zur Verfügung gestellt werden. Diese Service-Methoden werden durch Clients abgerufen, indem diese eine Anfragemeldung zu einem Thema senden, das einer Service-Methode zugeordnet ist. Nach dem Empfang dieser Meldung antwortet der Service, indem er über die Struktur eine Antwortmeldung zurück an den aufrufenden Client sendet (1-zu-1-Kommunikation). Zu den üblichen Service-Integrationsmodellen gehören Folgende:

  • Systemeigener Service: Ein Service, der mit einer systemeigenen DXL-Strukturintegration entwickelt wurde. So unterstützt McAfee Threat Intelligence Exchange beispielsweise nativ die Kommunikation über DXL-Strukturen.
  • Eingebundener Service: Ein DXL-Service-Wrapper wird erstellt, der Aufrufe an die API bzw. das SDK eines vorhandenen Service delegiert. Zum Beispiel kann ein Sicherheits-Service, der eine REST-basierte API nutzt, problemlos in einen DXL-Service-Wrapper eingebunden werden, um seine Funktionen in der DXL-Struktur bereitzustellen.