OpenC2

Cyber attacks operate at machine speed. Effective responses to attacks must operate at machine speed. Security solutions must not only be faster and smarter, they must be able to work together to create a concerted automatic cyber defense. This coordinated defensive activity requires that there be a commonly understood way to express system actions. OpenC2 is an open standards approach to translating the operational and defensive intent of an organization into orchestrated and automated system control actions.

A command set and syntax, OpenC2, based on the actions, targets, actuators, and attributes required to encode desired effect and command decisions as machine-readable instructions to enable automated courses of action has been defined. The expressiveness of the language can be expanded in a context-specific way by adding attributes and objects to further specify the general activities. This strategy achieves broad interoperability while only standardizing and maintaining a small set of actions.

The definition of a language such as OpenC2 is necessary but insufficient to enable future cyber defenses. OpenC2 was designed to be flexible, agnostic of external protocols that provide services such as transport, authentication, key management and other services.

The OpenC2 design principles include the following:

• Support cyber relevant response time for coordination and response actions.
• Be infrastructure, architecture, and vendor agnostic.
• Support multiple levels of abstraction, necessary to permit the contextualization of commands for a wide variety of operating environments.
• Permit commands to be invoked that are either tasking/response actions or notifications
  • Tasking/response actions result in a state change.
  • Notifications require supporting analytics/decision processes.
• Provide an extensible syntax to accommodate different types of actions, targets, and actuators (e.g., sensor, endpoint, network device, human) and specific targets and actuators.
• Ensure the OpenC2 command is independent of a message construct that provides transport, includes identification of priority/ quality of service, and supports security attributes.

Conceptually, an OpenC2 command has the following form:

(
    ACTION (
        type = <ACTION_TYPE>
    ),
    TARGET (
        type = <TARGET_TYPE>,
        <target-specifier>
    ),
    ACTUATOR (
        type = <ACTUATOR_TYPE>,
        <actuator-specifier>
    ),
    MODIFIERS (
        <list-of-modifiers>
    )
)
						

Click here for more details.

All OpenC2 commands start with an ACTION which indicates the type of command to perform such as gather and convey information, control activities and devices, and control permissions and access. The range of options and potential impact on the information system associated with a particular ACTION is a function of the ACTUATOR. For cases that involve multiple options for an ACTION, modifiers are used.

Action Details

The TARGET is the object of the ACTION (or conversely, the ACTION is performed on the TARGET). OpenC2 will utilize pre-existing data models to provide the namespace for the TARGETs. Initially, OpenC2 will reference the applicable CybOX objects in the OpenC2 TARGET namespace. However, OpenC2 can be supported by custom or other data models.

Target Details

An ACTUATOR is the entity that puts command and control into motion or action. The ACTUATOR executes the ACTION on the TARGET. To the extent possible, OpenC2 will leverage existing standardized data models for ACTUATORs (e.g., IETF Security Automation and Continuous Monitoring, Information Security Continuous Monitoring (ISCM)).

Actuator Details

"Specifiers" further distinguish individual or groups of targets or actuators. Specifiers can be associated with the TARGET or ACTUATOR in an OpenC2 command. Commands are appended with specifiers as context specific details become available.

Modifiers provide additional information about the action such as time, periodicity, duration, and location. Modifiers can denote the when, where, and how aspects of an action. The modifier can also be used to convey the need for additional status information about the execution of an action. Modifiers can be used to indicate whether the actuator should explicitly acknowledge receipt of the command, respond upon completion of the execution of the command, or provide some other status information. The requested status/information will be carried in a RESPONSE.

Modifier Details

The expressiveness of the language can be expanded in a context-specific way by adding attributes and objects to further specify the general activities. This strategy achieves broad interoperability while only standardizing and maintaining a small set of actions.