Re: [openc2] RE: [Non-DoD Source] [openc2] OpenC2 document structure

[Dave Lemire <dave.lemire@g2-inc.com>]

In response to questions 1 & 2: I concur that Duncan's examples nicely illustrate the scope of what needs to be defined.  I think we can craft some language and a picture or two that can either be included as a standard appendix or placed on the TC's wiki page and pointed to from each document (maybe an item in the informative references section?). As is usual with me for these sorts of questions, I always wonder if there are other worked examples within OASIS that we could / should emulate.

I submit this layering diagram as a starting point for such a picture.

https://docs.google.com/drawings/d/1wRDOF2mZPgIKqVjvF3S76XTfCADTh_OtDMjGD1KAtAA/edit

I think Question 3 requires more thought and time.

3) does concept of 'device profile' make sense? If so, do we (ie Implementation SC) need to make a document on what an implementer needs to include (ie how to make a device profile)? Should we write a spec on 'formatting' a device profile (eg it's a json data structure ...)

My basic question is whether there's a meaningful difference in the types of content needed between an actuator profile (which we've agreed to organize around functions) and a device profile that a vendor might create for one of their products (or perhaps a function(s) within one of their products). It seems to me that informing a producer what APs and transport specs a device conforms to is a configuration activity that's outside the scope of OpenC2. And if the device vendor is really bringing a new function to the table, isn't that a request for a change to the L-Spec to incorporate a new action(s)?

Dave

David P. Lemire, CISSP
  OpenC2 Technical Committee Executive Secretary
  OpenC2 Implementation Considerations SC Co-chair
  Contractor support to NSA
Email: dave.lemire@g2-inc.com
Office: 301-575-5190 / Mobile: 240-938-9350

On Thu, May 10, 2018 at 12:15 PM, Brule, Joseph M <jmbrule@radium.ncsc.mil> wrote:

Duncan,

 

You are stone cold correct and I like your examples.  Openc2 is in fact a suite of documents but that has not been clearly articulated, most likely for the simple reason that the elements of the ‘suite’ are in progress. 

 

The best way to do this?  The approach that makes sense to me is your third option (or included in each document.)  or perhaps a concise summary in each document and point to a reference (which is your first option.)  

 

Now is a good time to bring this up.  The Language spec is moving nicely, we almost have a profile and we reactivated the IC-SC.

 

Thank you

 

VR

 

Joe Brule

 

From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> On Behalf Of duncan@sfractal.com
Sent: Thursday, May 10, 2018 10:36 AM
To: TC OpenC2 <openc2@lists.oasis-open.org>
Subject: [Non-DoD Source] [openc2] OpenC2 document structure

 

I have been involved in several discussions about OpenC2 and this is an attempt to organize some thoughts, document them, and solicit feedback from the wider community.

 

One issue we need to address is documenting the overall structure of the documentation for OpenC2. I don't know if this is a separate document, a webpage, or included in each document.

 

I'm not sure of the correct words to propose so I'm going to explain by giving examples as background and then I'll discuss the document structure issue.

 

Example 1:

Let's say I would like to develop some open source software (which I do) for the first use case I submitted (https://github.com/oasis-tcs/openc2-usecases/blob/master/sFractalConsulting/01.another_user.md) and I would like to send an openc2 command from SO3 to FW5. For my example I would like FW5 to be an AWS NACL stateless packet filter and I would like SO3 to interface using a HTTPS API. I would like to write the software that would terminate on the Amazon side of the interface. It would start out 'just mine' but would be submitted to be part of the AWS opensource projects to provide an 'official' OpenC2 interface to AWS NACL's should Amazon agree to the pull request.

 

I believe there are 3 different specifications we are drafting that are applicable.

- the OpenC2 Language Specification

- the OpenC2 HTTPS API Transport Specification

- the OpenC2 stateless packet filter Actuator Profile Specification.

 

Example 2:

As further background to point I'll eventually make, let's assume AT&T wants to do similar with the second use case they submitted (https://github.com/oasis-tcs/openc2-usecases/blob/master/ATT/02.allow.md) also for AWS NACL's, but in their case using OpenDxl pub/sub transport and assume we were to create a OpenDxl transport specification (I'll cover the case where we don't later). For their example the 3 specifications would be:

- the Language Specification

- the OpenC2 OpenDxl Transport Specification

- the stateless packet filter Actuator Profile Specification.

 

Example 3:

Example 3 is just Example 2 where AT&T uses OpenDxl but the OpenC2 TC decides that there can only be one OpenC2 pubsub transport (I hope they don't, but this is for illustrative purposes) and TC chose OpenDDS over OpenDxl because McAfee hasn't actually made OpenDxl 'open'. In this case the software could be compatible with:

- the Language Specification

- the stateless packet filter Actuator Profile Specification

but would not be compatible with a transport specification.
 

Examples 4 & 5:

I apologize but I have not filled in https://github.com/oasis-tcs/openc2-usecases/blob/master/sFractalConsulting/11.deception.md but I will. In this case several security functions are involved and the technology (either cymmetria or attivo) has one OpenC2 Consumer that integrates several OpenC2 Actuator Profiles. Assume for illustrative purposes that we'd standardized all the actuator profiles for Attivo (example 4) and some, but not all, of the actuator profiles for Cymmetria (example 5).

The example 4 specifications are:

- the OpenC2 Language Specification

- the OpenC2 HTTPS API Transport Specification

- the OpenC2 deception1 (assume we have real functions) Actuator Profile Specification

- the OpenC2 deception2 Actuator Profile Specification

- the OpenC2 deception3 Actuator Profile Specification

 

The example 5 specifications are:

- the OpenC2 Language Specification

- the OpenC2 HTTPS API Transport Specification

- the OpenC2 deception1 Actuator Profile Specification

- the OpenC2 deception4 Actuator Profile Specification

- an Cymmetria-provided deception5 Actuator Profile Specification that "extends" a new security function

 

 

If I put myself in the shoes of someone not as involved as I've been, I do not think we do a good job of explaining how the documents interact and that all these examples are valid. It's also not clear to me whether we need another document that is provided by the implementer of the device in each example (an device profile?) that specifies what transport and actuator profiles (including extensions) a given device (using term to mean either physical or virtual device) supports. I think this is a very important issue because (1) there are more security professionals that are NOT intimately involved in OpenC2 and (2) for the foreseeable future there will be more 'extensions' than there are 'standard' actuator profiles.

 

The questions for discussion are:

1) does the above make sense as valid examples of how the specifications go together?

2) should there be something explaining the overall structure? If so, webpage or separate document or in each document?

3) does concept of 'device profile' make sense? If so, do we (ie Implementation SC) need to make a document on what an implementer needs to include (ie how to make a device profile)? Should we write a spec on 'formatting' a device profile (eg it's a json data structure ...)

 

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php