Actuator Profile Subcommittee meeting at 13:00 today

["Brule, Joseph M" <jmbrule@radium.ncsc.mil>]

Actuator Profile Subcommittee,

 

Recall that we will have an Actuator Profile SC meeting in approximately an hour.  (https://meet.lucidmeetings.com/meeting/193727 )

 

Some of the items that we would like to cover are: 

• Boilerplate

• At the face to face we reached general agreement that all OpenC2 Specifications would have introductory material up front so that the reader is aware of the different specifications.   Over the course of the next week or so, we will need to review and agreement on the so called 'boilerplate' material for the front.

• Document Overview

• The OASIS template has a document overview section.  I treated it as an extended table of contents.  It is only a couple of paragraphs so would be nice to get agreement.  (refer to the end of this email)

• Overload the Asset-ID specifier?       

• At the face to face we reached general agreement that specifiers for NFV would be a string, so the question becomes can we use the Asset-id to cover NFV as well as physical devices?

• Path for Profiles?
• 40 vice 250 characters?

 

IN the context of the conformance section, there are two approaches on the table. 

• Method One;  Systematically list out the conformance criteria or
• Method Two; create a matrix. 

As an FYI, KMIP uses Method two

We need to get ALL of the examples updated.

 

“Duncan will present a custom actuator he is building called HAHA – Https Api Helloworld Actuator which only responds to query-openc2 and query-helloworld. He’ll cover status, where the source code is, where the draft schema is, where the draft custom-actuator-profile is, and issues he’s uncovered in the process of doing this that need addressing in the specs”

 

=====PROPOSED DOCUMENT OVERVIEW SECTION=====

 

This specification is organized into three major sections.  

Section One (this section) provides a nonnormative overview of the suite of specifications that realize OpenC2.  This section provides references as well as defines the scope and purpose of this specification.

Section Two (normative) binds this particular profile to the OpenC2 Language Specification.  Section Two enumerates the components of the language specification that are meaningful in the context of  SLPF and defines components that are applicable to this distinct profile.  Section Two also defines the commands (i.e. the action target pairs) that are permitted in the context of SLPF.

Section Three (normative) presents definitive criteria for conformance so that cyber security stakeholders can be assured that their products, instances and/or integrations are compatible with OpenC2.  

This specification provides three non-normative Annexes.  OpenC2 is intended for machine to machine interactions, therefore a schema for SLPF and a the applicable portions of the OpenC2 Language schema are provided to facilitate development.  There is also an Annex that provides multiple examples of SLPF commands (JSON serialization).

 

VR

 

Joe Brule