New OpenDXL Clients released! Integrations Improve Endpoint Detection and Response, Intelligence Sharing, and Action Across Applications

Finding new ways to extract more value from security operations is a hot priority for most CISOs and security architects as they progress toward the goal of a proactive and optimized security operation. But according to our research, 26% of security operations centers (SOCs) still operate in reactive mode, with ad hoc approaches to security operations, threat hunting, and incident response. A fair amount of time is spent on scripting, log collection, and data manipulation, followed by propagating their assessment to the operational teams that need to act.

Often, the same sequence happens the next day with another endpoint or event and another analyst. The untold story is that analysts don’t have an easy way to integrate data and processes across tools, and then to make these tasks repeatable.

For example, how much time would you budget to integrate six products from 4 vendors to link countermeasures (firewall), investigation tools (endpoint detection and response), and remediation tools (vulnerability management and network access control)? Months? That’s if you can get access to the APIs.

At our user conference in November, our CTO, Steve Grobman, showed OpenDXL scripts linking products from different vendors to seamlessly identify and mitigate an attack. The demo, is both short and powerful, and the coolest part is that OpenDXL makes it easier to create similar successes. The engineering team pulled this demo together in a few weeks in their spare time. And now our engineering team is sharing some of the building blocks of that demo.

New OpenDXL Clients Expedite Integration

With the release on github of OpenDXL clients for McAfee Active Response (MAR) and McAfee Threat Intelligence Exchange (TIE), we have added more software to work with the open source OpenDXL Python client to orchestrate security. For any of you not familiar with OpenDXL, it provides an open, simple way to integrate technologies from different vendors with each other and with in-house developed applications. Enterprises get new, timely access to incredibly critical security intelligence and context and can connect apps and processes into consistent and automated workflows. Learn more here.

The two new Python clients simplify accessing the existing MAR and TIE DXL services. This approach insulates developers from needing to know MAR- or TIE-specific DXL topics and message formats. Digging into the MAR example, the engineering team illustrates the value of creating easy to use DXL services. For the demo I mentioned, they wanted to connect Intel Security products with Check Point, Rapid 7, and HP Aruba products. Rather than creating one-off native OpenDXL integrations for each of these three apps, the engineers did two things; they created service wrappers for the non-DXL integrated products, and new, easy-to-use Python clients for Active Response and MAR.

The service wrappers enable non-DXL integrated APIs of Rapid 7 and HP Aruba functionality to be called via DXL. Service wrappers are the means for integrating data and processes across tools. [I will go into this more in a future blog, or you can learn more now at]

The new Python clients simplify the process of querying endpoints in your environment, reducing the effort from 120 lines of code (with pure OpenDXL) to 20 lines of code (with the MAR Python client).

The next new application that wants to search an endpoint—perhaps yours?—will also require just 20 lines of code.  See for yourself how simple the integration is. Two sample search code files are here on Github:

There’s untapped potential for efficiency and better ideas as companies start using these capabilities with the OpenDXL SDK. Please learn more at and join the conversation on our community site.

Leave a Comment

13 − 1 =