OASIS Open Command and Control (OpenC2) TC

 View Only

OASIS-openc2@ConnectedCommunity.org

Contacts

Chair: Duncan Sparrell, sFractal Consulting LLC
duncan@sfractal.com

Chair: Michael Rosa, National Security Agency
mjrosa@cyber.nsa.gov

OASIS Staff Contact: Kelly Cullinane
kelly.cullinane@oasis-open.org

Charter

The OpenC2 TC charter is available at https://www.oasis-open.org/committees/openc2/charter.php

Description

Creating a standardized language for the command and control of technologies that provide or support cyber defenses.

Group Notes

Table of Contents







Announcements

Information Modeling with JADN Version 1.0 is now approved as a Committee Note. A link can be found in Technical Work Produced by the Committee. (26 April 2023)



OpenC2 Architecture Specification v1.0 is now approved as a Committee Specification. A link can be found in Technical Work Produced by the Committee. (30 September 2022)



Specification for Transfer of OpenC2 Messages via HTTPS v1.1 is now approved as a Committee Specification. See the details in the announcement. (30 November 2021)



Specification for Transfer of OpenC2 Messages via MQTT Version 1.0 is now approved as a Committee Specification. See the details in the announcement. (19 November 2021)



A high level overview of OpenC2 featuring insights from the Technical Director of NSA's Capabilities Directorate can be viewed at OpenC2 Overview (YouTube).



Specification for JSON Abstract Data Notation (JADN) Version 1.0 has been approved and released as Committee Specification 01. Information can be found in the announcement. (17 August 2021)



The TC's three specifications were approved as OASIS Committee Specifications in July 2019:



  • Open Command and Control (OpenC2) Language Specification Version 1.0,

  • Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0, and

  • Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0



For more information, see the announcement.



A minor update to the Language Specification was approved in November 2019, so its current version is v1.0 CS02. The announcement
for that update can be found here.



The OpenC2 TC and U.S. Cyber Command's
DreamPort facility sponsored
an interoperability Plug Fest / Hackathon on 27-28 January 2020. The event was conducted
at the UMBC Training facility nearby to Dreamport. The event was very
successful in demonstrating OpenC2 interoperability, as well as its implementation-agnostic characteristics.
A summary of results can be found on the
Plug Fest Outcomes
page on GitHub



See press release: "International Community Comes Together at OASIS to Advance OpenC2 Standard for Automated Defense Against Cyber-Attacks."



You may join the OASIS OpenC2 TC at any time. Contact join@oasis-open.org for more information.





Overview



The OpenC2 TC was chartered to draft documents, specifications, lexicons or other artifacts to fulfill the needs of cyber security command and control in a standardized manner. The Technical Committee will leverage pre-existing standards to the greatest extent practical, identifying gaps pertaining to the command and control of technologies that provide or support cyber defenses. The TC will base its initial efforts on artifacts generated by the OpenC2 Forum, a community of cyber-security stakeholders that was facilitated by the National Security Agency; the Forum has published a language description document (RC4), actuator profiles, and open source prototype implementations.



For more information on the OpenC2 TC, see the TC Charter.



OpenC2 TC standing rules can be found under Additional Information.



The TC uses GitHub for work product development and general operations.
The TC Operations repository contains documents
that outline the TC's operating conventions.





Subcommittees

As of March 2021, the TC charter has been revised and the subcommittees described below have ceased operation.

The OpenC2 TC originally established the following three subcommittees:










TC Liaisons

No TC Liaisons have been announced for this TC.




TC Tools and Approved Publications



  • Version Control (GitHub Repositories):

    • openc2-cn-apdev - Developing an OASIS Committee Note describing a process for developing OpenC2 Actuator Profiles (APs), including the use of the JSON Abstract Data Notation (JADN) information modeling language in the development of APs.

    • openc2-ap-hunt A GitHub to define an actuator profile to automate management of cyber threat hunting activities using OpenC2.

    • openc2-ap-pac - A GitHub to focus on developing an Actuator Profile for security Posture Attribute Collection.

    • openc2-ap-swup - A GitHub to focus on the use of OpenC2 to issue commands and parse responses to devices (virtual or physical) whose software can be updated.

    • openc2-ap-lc - A GitHub to focus on the use of OpenC2 to issue commands to and parse responses from systems that generate events such as system log, application log, or error log messages

    • openc2-ap-av - A GitHub to focus on the use of OpenC2 to issue commands and parse responses to hardware or software that can control an anti-virus engine.

    • openc2-ap-pf - A GitHub to focus on the use of OpenC2 to issue commands and parse responses to hardware or software that can control administrative policies regarding network packets.

    • openc2-ap-edr - Defining Actions, Targets, Specifiers and Options that are consistent with the version 1.0 of the OpenC2 Language Specification in the context of command and control of various endpoint detection and response technologies.

    • openc2-ap-honeypots - Develop an OpenC2 actuator profile (AP) for the management of HoneyPots.

    • openc2-ap-ids - Developing a concise and extensible language to enable the command and control of cyber defense components.

    • openc2-cloudpubsub - Supporting work on a Committee Note that provides an overview of members' experience using Google Cloud Platform (GCP) Pub/Sub messaging to transfer OpenC2 messages.

    • openc2-transf-http - Supporting TC members' work on a formal specification that describes the use of HTTP as a transfer mechanism for OpenC2 messages.

    • openc2-tc-ops - Documentation associated with TC operations and information sharing such as FAQs, lists of links to related work, and norms for developing and approving TC work products. Given the intent of the repo we are making all co-chairs maintainers

    • openc2-ap-sfpf - This repository is focused on the use of OpenC2 to issue commands and parse responses to a firewall.

    • openc2-jadn - Specifying a vocabulary to describe the meaning of structured data, to provide hints for user interfaces working with structured data, and to make assertions about what a valid instance must look like.

    • openc2-jadn-im - Describes the use of information models (IMs), explains how to construct IMs using JADN, and contrasts IMs with other modeling approaches, such as Entity-Relationship models for databases, and knowledge models / ontologies.

    • openc2-transf-odxl - This specification describes the use of the Open Data Exchange Layer (OpenDXL) as a transport mechanism for OpenC2 messages.

    • openc2-transf-mqtt — This GitHub repository supports development of content and change tracking for the OpenC2 MQTT transfer specification as new working draft level revisions are created and the associated CSDs mature.




    • openc2-impl-https - A repository used by TC members to propose and track changes to the OpenC2 HTTPS implementation specification.

    • openc2-cap - A repository for use by TC members to collaborate on development of OpenC2 "cap" profiles (custom actuator profiles).

    • openc2-glossary — A repository to support development of an OpenC2 Glossary as one of the TC's chartered deliverables




Technical Work Produced by the Committee

The TC is actively developing several related specifications (the links below point to the latest available version of each specification in HTML format):



  • OpenC2 Architecture Specification v1.0 — OpenC2 is a suite of specifications for Producers and Consumers to command and execute cyber defense functions. The OpenC2 Architecture Specification describes the fundamental structures of OpenC2 and provides a blueprint for developing Actuator Profiles and Transfer Specifications.



  • OpenC2 Language Specification v1.0 — The OpenC2 Language Specification provides the semantics for the essential elements of the language, the structure for commands and responses, and the schema that defines the proper syntax for the language elements that represents the command or response. OpenC2 Language Specification became a Committee Specification (CS01) 11 July 2019. CS02 of the Language Specification was approved on 24 November 2019 and is the current version.



  • Specification for Transfer of OpenC2 Messages via HTTPS Version 1.1 - OpenC2 transfer specifications utilize existing protocols and standards to implement OpenC2 in specific environments. This specification specifies the use of HTTP over TLS as a transfer mechanism for OpenC2 Messages. A Testing conformance target is provided to support interoperability testing without security mechanisms. Specification for Transfer of OpenC2 Messages via HTTPS Version 1.1 became a Committee Specification 30 November 2021.

  • Specification for Transfer of OpenC2 Messages via MQTT Version 1.0 - OpenC2 transfer specifications utilize existing protocols and standards to implement OpenC2 in specific environments. This specification describes the use of MQTT Version 5.0, a widely-used publish / subscribe (pub/sub) transfer protocol, as a transfer mechanism for OpenC2 messages. Specification for Transfer of OpenC2 Messages via MQTT became a Committee Specification 19 November 2021.

  • Open Command and Control (OpenC2) Profile for Stateless Packet Filtering v1.0
    — OpenC2 Actuator Profiles specify the subset of the OpenC2 language relevant in the context of specific actuator functions. This actuator profile specifies the set of actions, targets, specifiers, and command arguments that integrates Stateless Packet Filtering functionality with the Open Command and Control (OpenC2) command set. OpenC2 Profile for Stateless Packet Filtering v1.0 became a Committee Specification 11 July 2019.



  • Specification for Transfer of OpenC2 Messages via HTTPS v1.0 — OpenC2 transfer specifications utilize existing protocols and standards to implement OpenC2 in specific environments. This specification describes the use of HTTP over TLS as a transfer mechanism for OpenC2 messages. Specification for Transfer of OpenC2 Messages via HTTPS became a Committee Specification 11 July 2019.




In addition to the above OpenC2 specifications, JSON Abstract Data Notation Version 1.0. defines a UML-based information modeling language that defines data structure independently of data format. Information models are used to define and generate physical data models, validate information instances, and enable lossless translation across data formats. A JADN specification consists of two parts: type definitions that comprise the information model, and serialization rules that define how information instances are represented as data. The information model is itself an information instance that can be serialized and transferred between applications. The model is documented using a compact and expressive interface definition language, property tables, or entity relationship diagrams, easing integration with existing design processes and architecture tools. While developed by the OpenC2 TC, JADN is applicable to a broad range of information modeling applications.



The TC has published a Committee Note, Information Modeling with JADN Version 1.0, as a companion to the JADN Specification. This Committee Note describes the use of IMs, explains how to construct IMs using JADN, and contrasts IMs with other modeling approaches, such as Entity-Relationship models for databases, and knowledge models / ontologies.




OASIS TC Open Repositories Sponsored by the Committee

OASIS TC Open Repositories:



  • openc2-oif-obo - A GitHub repository to support implementing the the OIF Bridge Orchestrator (OBO), an OpenC2 Integration Framework (OIF) product that can be configured as an intermediate producer-consumer.

  • openc2-lycan-elixir - A GitHub for developing a collection of applications and libraries, coded in Elixir, a language that runs on the BEAM virtual machine, for the purpose of implementing OpenC2.

  • openc2-iosacl-adapter - A GitHub for a prototype implementation in R to transform between OpenC2 and Cisco IOS formats. The adapter supports access control list (ACL) management.

  • openc2-custom-aps - A GitHub public repository for collaboratively developing OpenC2 Custom Actuator Profiles

  • openc2-lycan-python — A GitHub public repository for development of a python library to transform between data-interchange formats (such as JSON) and python language objects

  • openc2-lycan-java — A GitHub public repository for development of a java library to transform between data-interchange formats (such as JSON) and java language objects

  • openc2-lycan-beam — Developing a collection of applications and libraries, coded in languages that run on the BEAM virtual machine (e.g., erlang, elixir), for the purpose of implementing OpenC2

  • openc2-compatibility — Supporting the capture of OpenC2 core design principles and development of implementation guidelines so that implementers can agree on language and protocols to build interoperable systems

  • openc2-ocas — OpenC2 API Simulator erlang/OTP application designed to demonstrate and exercise the OpenC2 specification

  • openc2-yuuki — Yuuki is a python package for building an OpenC2 proxy using multiple dispatch on type with updating of actuators without interrupting the operations of the orchestrator or other actuators

  • openc2-pub-sub-on-bsd — A prototype reference implementation that demonstrates OpenC2 working within a pub/sub environment

  • openc2-jadn — Supports Development and maintenance of JADN (JSON Abstract Data Notation), a JSON document format for defining abstract schemas

  • openc2-orchid — OpenC2 proxy built in Django to provide a simple, modular API accepting OpenC2 commands and converting them into Python actions

  • openc2-iacd — Supports development of a Java OpenC2 implementation which implements fifteen OpenC2 actions issued to nine actuators

  • openc2-reactor-master — A feedback-driven GUI master/actuator orchestration framework for the OpenC2 language, written in Python

  • openc2-reactor-relay — A simple, modular API for accepting OpenC2 commands and converting them into Python actions






Expository Work Produced by the Committee

There are no approved expository work products for this TC yet.




External Resources

Although not produced by the OASIS OpenC2 TC, the following information offers useful insights into its work.

External resources have not yet been identified.




Mailing Lists and Comments

openc2: the discussion list used by TC members to conduct Committee work. TC membership is required to post, and TC members are automatically subscribed. The public may view the OASIS list archives, also mirrored by MarkLogic at MarkMail.org.



openc2-comment: a public mailing list for providing feedback on the technical work of the OASIS OpenC2 TC. Send a comment or view the OASIS comment list archives, also mirrored by MarkLogic at MarkMail.org.




Press Coverage and Commentary








Additional Information



The OpenC2 Technical Committee has adopted six standing rules:

SR-1: Suspension Of Standing Rules For The Duration Of The Meeting



  1. The rules of OASIS or Roberts Rule of Order cannot be suspended as they are not standing rules and always apply.

  1. During the course of a meeting, a standing rule may be suspended for the duration of a meeting. A motion to suspend a standing rule is not debatable and must be called to question immediately.

  1. The rule will be suspended if any of the following criteria are met:



    • By a vote of 2/3 majority of the voting members present without prior notice

    • By a simple majority vote of the voting members present with prior notice





SR-2: Consideration Of Artifacts Presented By A Subcommittee To The Committee As A Whole



  1. All artifacts must be provided to the Secretary no later than seven business days prior to the meeting of the technical committee. The topic may be added to the agenda upon approval of the co-chairs or by proposal by members of the TC as described in Rule Three of these standing rules. If approved as an agenda item, the Secretary will provide the artifacts to the members of the TC no later than three business days prior to the meeting of the technical committee.

  1. Prior to consideration, the chair will call for objections.

  1. Any member present may object. An objection must include a brief reason for the objection.

  1. Any other member present may support one or more objections.

  1. If the artifact is called to question, then the voting members present may accept, reject or send the artifact back to the subcommittee for further deliberation.




SR-3: Consideration Of Agenda Items For Committee Meetings



  1. For items that are not artifacts as referenced in rule two, all members may propose agenda items to the technical committee by providing a summary of the item to the Secretary no later than five days prior to the meeting.

  1. All agenda items are subject to the approval of the co-chairs.




SR-4: Election and Term of OpenC2 Co-chairs



  1. The Technical Committee (TC) and each subcommittee shall elect two co-chairs for a 24 month term.

  1. The period of each co-chair shall be offset by 12 months.

  1. The TC shall hold open elections in the month of March during the during the regular business meeting.

  1. All TC members (to include the incumbent co-chairs whose terms are up) are eligible for nomination for an office.

  1. In the event of a vacancy (such as a co-chair stepping down prior to the conclusion of their term), a replacement will be elected to complete the term.




SR-5: Authority to Create CSD / PRD Ballots

The TC authorizes the TC co-chairs to submit a Working Draft
document that has the general consensus of the associated
subcommittee for electronic ballot to be a Committee
Specification Draft or a Committee Specification Public Review
Draft.



SR-6: Multiple Sessions for TC Meetings

When separate sessions of a TC business meeting are conducted
in a single day, those sessions shall be considered a single
meeting for purposes of determining quorum, approving
resolutions, maintaining voting rights, tracking actions,
publishing minutes, and other routine TC business functions.



Public Resources -will be hidden if you are logged in

Announcements

Log in to see this information

Either the content you're seeking doesn't exist or it requires proper authentication before viewing.

Latest Discussions