Features

Location Unaware

Communication between clients on the DXL fabric is based on sending "messages" to a "topic". Clients are unaware of the location of the other DXL clients they are communicating with (its hostname, IP address, etc.).

For example, if a client wanted to determine the reputation for a file, it could send a request message to the topic /mcafee/service/tie/file/reputation. A service would receive the request and send a response with the appropriate reputation information. All of this communication occurs without either party knowing the location of the other (they could be in the same building or on the other side of the world).

Persistent Connection

Connections are established from a DXL client to a DXL broker. These connections are persistent and allow for bi-directional communication. The benefits to this style of connection include:

• Firewall Friendly

  Clients are responsible for establishing the connection to brokers (never from a broker to a client). Therefore, we can communicate with clients that were previously unreachable. For example, a mobile client can connect to a broker exposed in a demilitarized zone (DMZ). Since the communication is bi-directional, we can now communicate with the client from products also connected to the fabric (sending an agent wakeup for cloud ePO, etc.).

• Near Real-Time Communication

  Communication on the DXL fabric is extremely efficient because the expense of continually establishing connections is eliminated.

Multiple communication models

DXL Supports two different models of communication. A service-based model with point-to-point (request/response) communication and a publish/subscribe event-based model.

• Service-based

  The DXL fabric allows for "services" to be registered and exposed that respond to requests sent by invoking clients. This communication is point-to-point (one-to-one), meaning the communication is solely between an invoking client and the service that is being invoked. It is important to note that in this model the client actively invokes the service by sending it requests.

  For example, the Threat Intelligence Exchange service is exposed via DXL allowing for DXL clients to request reputations for files and certificates.

• Event-based

  The DXL fabric also allows for event-based communication. This model is typically referred to as "publish/subscribe" wherein clients register interest by subscribing to a particular topic and publishers periodically send events to that topic. The event is delivered by the DXL fabric to all of the currently subscribed clients for the topic. Therefore, a single event sent can reach multiple clients (one-to-many). It is important to note that in this model the client passively receives events when they are sent by a publisher.

  For example, Advanced Threat Defense (ATD) servers send events to the topic /mcafee/event/atd/file/report when they have successfully determined the reputation for a file. Any clients currently subscribed to this topic will receive the report (Threat Intelligence Exchange Server and the Enterprise Security Manager currently subscribe to this topic).

Secure Communication

Communication over the DXL fabric is secured via TLS version 1.2 and PKI mutual authentication.

The fabric also supports topic-level authorization wherein individual topics can be restricted in terms of which clients can publish messages to and which clients can receive messages on a particular topic.

For example, the DXL clients embedded in the Threat Intelligence Exchange servers are the only ones authorized to publish reputation change events to the topic /mcafee/event/tie/file/repchange.