Posts by chrissmith

    The OpenDXL Python Client does not currently provide a method to directly determine the identifier of the client. For "open" clients it is actually the DXL broker that assigns the identifier.


    With that said, it is pretty simple to determine what the identifier is. This information is included in the response message received for any request that is sent by the client. The client identifier is located in the client_ids property of the response message.


    The following code attempts to invoke a service that does not exist. The response from the broker will include the client's identifier (as it is set to route directly back to the client).


    Python: Determine Client Identifier
    1. req = Request("/service/does/not/exist")
    2. res = client.sync_request(req)
    3. client_id = res.client_ids[0]


    Hope this helps,

    Chris

    I am not aware of any OpenDXL integrations that directly support a STIX/TAXII feed. However, I have seen a couple of integrations that support threat feeds via aggregators (such a IntelMQ). I am not sure whether STIX/TAXII is a supported feed for any these. Hopefully those solutions will be submitted here in the near future.


    Threat Intelligence Exchange (commercial) does support a subset import (primarily hashes) of STIX files. The import results in file reputations that are available via OpenDXL (see TIE Python Client Library).


    It would be great to see an OpenDXL solution developed that supports the ability to define a set of TAXII feeds. As new threats are published, they could be sent over DXL as events. These events could then be consumed by a variety of security products (sandbox, SIEM, endpoint scanners, etc.). Having such a solution would eliminate the per-product configuration and maintenance of the TAXII feeds.


    Chris

    Great question.


    DXL is not a new protocol, it can be best thought of as a "standardized message format". This message format could be sent over any protocol that allows for sending a generic payload (bytes). DXL does not require any changes to the protocol itself.


    With that said, the only protocol that DXL is compatible with today is "MQTT". During the development of DXL we prototyped its use over a variety of protocols (STOMP, AMQP, OpenWire, etc.) but ultimately decided to limit its initial support to MQTT. One reason for this decision is that we made enhancements to the MQTT messaging brokers themselves so that they could intrinsically understand the DXL message format in support of advanced features such as services, request/response (point-to-point) messaging, service fail over, and service zones.


    Hope this helps,

    Chris

    This typically occurs when the client does not have permission to invoke a method exposed by a service (in this particular case, set reputation).


    This particular error is discussed in the FAQ for the TIE client:


    https://github.com/opendxl/ope…/FAQ#waittimeoutexception


    This typically occurs due to the Python client not having permission to send messages to the

    /mcafee/service/tie/file/reputation/settopic (for files) and the

    /mcafee/service/tie/cert/reputation/settopic (for certificates


    Hope this helps.


    Chris