DESIGN PRINCIPLES

August 16, 2017

Joe Brule

Co-chair, OpenC2

OpenC2 Roster

• 111 Members in the OASIS OpenC2 TC
• 32 Members from the legacy OpenC2 Forum
• August 2015 through June 2017
• Produced Language Description Document, Schema, Codebase
• 79 Members added since OASIS Transition
• June 7 to date
• Tasks
• Design Choices
• Assumptions
• Modification of Documents IAW OASIS conventions

​

​

2

OpenC2 ‘Philosophy’

• Maintain Separation of Concerns
• Pre-existing standards will be leveraged to the greatest extent practical
• Minimize Complexity Of Command
• Minimize Overhead on Sensor/Actuator
• Infrastructure, architecture and vendor agnostic
• Extensible to support different levels of detail and future technologies

​

3

Interoperability is Paramount

​

OpenC2 Assumptions

• Basic Assumptions
• The analytics have been done
• The decision to respond has been made
• The Tx and Rx entities are authorized to do so
• Assured Transport
• Language Specific Assumptions
• Actions are stable
• Targets are stable
• Actuators are area of dynamic R & D

4

OpenC2 Design Principles

• Focus is on unambiguous Machine to Machine exchanges
• Lightweight
• Efficient Machine to Machine communications
• Abstract
• Focuses on ‘What’ to do vice ‘Device Specific’
• Permits different levels of abstraction
• Extensible
• Extensions enable additional precision and flexibility
• Agnostic
• Transport, Authentication, Integrity controls etc.
• Enables flexibility w.r.t. implementation

​

5

OpenC2 ‘Approach’

• Decouple ACTION, TARGET, ACTUATOR and MODIFIER
• ‘Specifiers’ and ‘Options’ provide additional precision
• 33 ‘Universal’ actions
• Target Data model largely derived from STIX Cyber Observables
• Actuator-specifiers and actuator-options defined as extensions

6

Conceptual Syntax

ACTION = <ACTION_TYPE>,

TARGET (

type = <datamodel:TARGET_TYPE>,

<target-specifier>

<target-options>

),

ACTUATOR (

type = <ACTUATOR_TYPE>,

<actuator-specifier>

<actuator-options>

),

MODIFIERS (

<list-of-modifiers>

)

7

Optional: Defined in separate specification (Actuator Profile)

Optional: Defined in Language Specification.

Required: Defined in Language Specification.

High Level Command (Block outgoing FTP)

• Supports inter-domain effects based commands

​

{"action": "deny",

"target": {

"type": “openc2:five-tuple",

"specifiers": {

"Layer4Protocol":

"ip-address-src”:

"ip-address-dst”:

"src-port": 21

“dst-port”:

}

}

​

8

More details �(Firewalls block at perimeter, send host unreachable and ack)

{"action": "deny",

"target": {

"type": “openc2:five-tuple",

"specifiers": {

"Layer4Protocol":

"ip-address-src”:

"ip-address-dst”:

"src-port": 21

“dst-port”:

}

"actuator": {

"type": "firewall",

"specifiers": {perimeter},

“options”:{reject},

"modifiers": {

{“id”:”UUID=123e4567-e89b-12d3-a456-426655440000”}

{response=TRUE}

}

9

Identifies functional actuator profile

Documented in the ‘firewall profile specification”

Documentation Approach

• Language Specification: (https://docs.google.com/document/d/1l7rIZl_I_zZb1FQOMYZkfUI04O7sNasZ-ozUvMn5SMU/edit)
• Documents ‘durable’ aspects of language
• Actions
• Default Target namespace
• ‘semantics’, syntax,
• Profile framework
• Minimum to implement
• Enables stable version and maintains backward compatibility
• Profiles
• Separate specifications that focus on adoption for a particular industry
• Profile Framework
• Scope and applicability
• Applicable Targets and Actions (required and optional)
• Specifiers and options for a class of actuators

​

​

10

Way Forward

• Language Subcommittee
• Transition current LDD into Language Specification
• Summary of Actions, Syntax, description
• Define Framework for Actuator Profiles
• Conformance clauses
• Actuator Profile Subcommittee
• Transition current documents into Actuator Profile Specifications
• Define and draft additional specifications
• Implementation Considerations Subcommittee
• Transition current documents into references (for Language specification)

11