Posts by marcelosz

Would be great to have OpenDXL Python Libs on the docker image, so that we can use Python-based Nodes too.

marcelosz added a new solution:

Quote

OpenDXL-Anomali-STAXX is a Python client that exports observables (IOCs) from Anomali STAXX and publishes them into a McAfee DXL messaging fabric.

Right now the best way to use OpenDXL-Anomali-STAXX is through this Docker image.

Quote from chrissmith:

Great question!

DXL intentionally does not dictate the format of the payload. This allows for a wide variety of integrations to be published on the fabric.

Currently, the vast majority of solutions utilize JSON, but there are some that use XML, and others that use raw binary.

With that said, for a particular sets of topics, it absolutely make sense to standardize the payloads. As you mention standardizing on the topics that utilize STIX and CEF makes sense. We have discussed adding a new section to this site that documents the "catalog" of topics and related formats that are available on DXL. I think something like this will be necessary as the number of integrations available on DXL continues to grow.

Hope this helps,

Chris

Display More

Hi chrissmith

Any roadmap on the creation of that catalog?

HI menyhar .

Is there a way we can download Siemplify as an ISO or OVA, just like Phantom and Demisto?

I'd like to see this integration running.

Quote from chrissmith:

...We have discussed adding a new section to this site that documents the "catalog" of topics and related formats that are available on DXL. I think something like this will be necessary as the number of integrations available on DXL continues to grow.

Thanks Chris. I'm looking forward to this. Please advise if there's anything I can help you guys on this.

Quote from Vadim:

We need general naming conventions as well. No matter which message format (json, xml, stix etc) or topic is used. Otherwise It can cause that potentially compatible solutions will not be able to talk with each over because the names are hardcoded.

E.g. IPv4 address field can be named: ipv4, ipv4address, IPv4, ip4addr, etc.

Vadim

Agreed, vadim.

Isn’t it an issue not having a “payload standard”? AFAIK, OpenDXL came to avoid things like “full mesh, one-to-one, messy security integrations”. But then, imagine this situation where a message publisher is created. All other clients subscribed to the topics will have to know how to “parse” the payload and get important info. And that for each one of the publishers. Otherwise, if we had some sort of spec we wouldn’t have that issue. What do you think?

It would be good to have some “protocol” in order to cover all (or most) situations. Like:

• Use STIX 2.0 if sending IoCs (and all other things STIX can be used for https://oasis-open.github.io/cti-documentation/stix/intro). Already in JSON BTW, which is great.
• Use CEF when transferring event (log) related messages
• Use XYZ for ABC, …

I understand the need for “openness” of the protocol, but maybe it comes with some caveats. Do you guys agree? Or am I not seeing the bigger picture here?

I'm glad to announce that I've created a Anomali STAXX OpenDXL client.

The client is not "STIX compliant", but it can export observables from STAXX and publish them into the DXL fabric as messages. It's available here: https://github.com/marcelosz/OpenDXL-Anomali-STAXX (gonna submit it as a Solution here soon - need to finish the docs though...)

Are you aware of any?