Re: [openc2-imple] OCA OpenDXL-Ontology vs OpenC2 - topic for IC-SC

[Vasileios Mavroeidis <vasileim@ifi.uio.no>]

Examples can be found here https://opencybersecurityalliance.github.io/opendxl-ontology/

I donât think that they support compound commands. OpenDXL was created to use the DXL fabric, thus an atomic command can be register into a topic and then all the services subscribed can get the command (pub/sub).

What they need to do is maybe to come up with a report/addition to their spec showcasing and describing how you can enable openc2 over DXL but then as I actually described it becomes OpenC2 overDXL and is not related anymore to the OpenDXL vocabulary. Asking them to adopt our vocabulary will be like asking them to drop their ontology since the differences are not substantial. They do say though that â The goal of the OpenDXL Ontology is to incorporate many different common and open standards (OpenC2 being one of them) â, which again it seems that is not the case. The least they can do is incorporate OpenC2 examples.

A more compromising approach would be to create a table mapping OpenDXL commands to OpenC2 commands. In such case a new problem will arise. If they showcase OpenC2 over DXL that creates a transfer spec, that will probably come in opposition with how we Populate OpenC2 commands especially in the case that we want to include new fields in the payload such as the reference id of the command and possibly integrity and authentication-related fields (we are going to have a pub/sub spec if the different protocols have similarities and the case of conflict will become even worse if we need to create individual transfer specs such as for DXL).

Just to make an uneducated assumption an OpenC2 example for blocking an IPv4_connection would: /action/deny/ipv4_connection and the payload.

-Vasileios

On Mar 31, 2020, at 9:57 PM, Dave Lemire <dave.lemire@g2-inc.com> wrote:

Good discussion topic. I don't know if it's more urgent than the spec issues, but hopefully there's time to get to both. 

There's a placeholder for "relate to ... the OpenDXL ontology" in the new FAQ in the TC-Op repo.  https://github.com/oasis-tcs/openc2-tc-ops/blob/master/FAQ.md  But it's just a placeholder for now.

I don't really see anything I'd consider a "compound command" in their description; multiple services responding to one action doesn't a compound command make, IMO. I'd agree they are (currently) correct about notifications.

I think we need to deal with the new message structure DaveK proposed, post plug fest, before we can really crank out a pub/sub spec. It's currently captures as LS issue #353 

(https://github.com/oasis-tcs/openc2-oc2ls/issues/353)

Dave

David Lemire, CISSP

Systems Engineer

HII Mission Driven Innovative Solutions (HII-MDIS) â formerly G2, Inc.

Technical Solutions Division

302 Sentinel Drive | Annapolis Junction, MD 20701

Email: dave.lemire@g2-inc.com

Email (effective 1 April 2020): david.lemire@hii-tsd.com

Work: 301-575-5190 | Mobile: 240-938-9350

On Tue, Mar 31, 2020 at 3:17 PM duncan sfractal.com <duncan@sfractal.com> wrote:

Iâm sending this as sfractal, not OpenC2 chair. Iâd like to add another topic to IC-SC agenda.

 

The OCA OpenDXL-Ontology has a FAQ (https://github.com/opencybersecurityalliance/opendxl-ontology/wiki/FAQ#general) about OpenC2 as follows:

Q: How is the OpenDXL Ontology different from OpenC2?

A: The goal of the OpenDXL Ontology is to incorporate many different common and open standards (OpenC2 being one of them). The ontology supports "actions" which on the surface appear similar to OpenC2 "commands". However, the goal of the ontology is to take full advantage of the messaging fabric that it is based upon. Thus, it should be possible to send a single "action" message to the fabric and have multiple services respond (one to many). For example, a client might send a single "quarantine action" message to the fabric and have a diverse set of services take action (a firewall, endpoint, and ticketing system). Supporting one action to many responses requires that OpenDXL Ontology actions be more generic than their OpenC2 counterparts.

The OpenDXL Ontology also supports the concept of "notification" messages. These are messages that are used to notify clients currently connected to the fabric when significant events occur (a virus is detected, etc.). OpenC2 does not currently have an equivalent concept.

 

I have my own views on this statement; but before I open an issue with the OCA, I think this should be discussed in the IC-SC to make sure Iâm not offbase.

 

I do agree we do not have ânotificationsâ â although that is an open item for OC2 so maybe we will have at some point.

 

I also agree we do not have âcompoundâ actions as yet. This is another can we kicked down the road.

 

However I do think the OpenC2 over OpenDXL is a topic being worked in IC-SC and maybe we should work it harder (ie not wait for McAfee to submit something to OC2 since I imply from all this that they are choosing to submit to OCA â we can read them on OCA).

 

I donât personally think OpenDXL âactionsâ are different than OC2 âcommandsâ in cases other than mentioned above (compound/atomic, notifications). Eg I think OpenDXL âblacklistâ (see https://github.com/opencybersecurityalliance/opendxl-ontology/blob/master/schema/actions/blacklist_url_actions.json) is the same as OC2 âdenyâ and I see no value in using a different word.

 

Similarly, OpenDXL chose a different API structure than the OpenD2 HTTPS spec â ie they take some of the info out of the json and put it in the url, and their json also has some differences. https://github.com/opencybersecurityalliance/opendxl-ontology/blob/master/schema/actions/blacklist_url_actions.json is the json for one example. To see the url differences requires leaving opendxl-ontology and going into opendxl â which strictly speaking is not a OCA project (which Iâll confess I donât totally understand the distinction) and I canât find the example (hopefully someone can by meeting). I think you can infer it from https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/json/petstore-separate/spec/swagger.json (eg the âtargetâ, pet in this example, is in the url (lines 30, 65, 90, â) but I thought I had a more obvious example somewhere.

 

Rather than many people create potentially conflicting issues on the OCA system, Iâd prefer we discuss first so we could create present a coherent case for harmonization of OpenDXL and OpenC2.

 

Whatever we decide, we should also have a âHow is the OpenDXL Ontology different from OpenC2?â in the OpenC2 github

 

 

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/