OpenC2 Simple Playbook

[Vasileios Mavroeidis <vasileim@ifi.uio.no>]

Hi all,

In the light of OpenC2, a language for the command and control of cyber defense components; CACAO, an orchestrated way (language) for sharing course of action playbooks (today is the second committee meeting); and security playbooks that are a combination of knowledge and potentially machine readable actions where we can potentially integrate OpenC2, I have some thoughts to share.

OpenC2 are atomic commands/actions - How can we make these commands coordinated if needed in a simple way? How do we bring this capability without touching the language itself?

For example, my proof of concept can take arrays of OpenC2 commands; a json file that includes multiple openc2 commands [{openc2.1}, {openc2.2}, {openc2.3}]. These commands are in sequential order like a course of action playbook. We donât include any kind of logic when filling the playbooks. But the orchestrator can make use of the response codes to decide if the next action should be issued OR if the execution should be stopped because of an error, where in this case we store at which openc2 command the execution was halted.

So if the first OpenC2 action was successful - response code 200 - we parse the second action and so on. This idea does not provide a very flexible solution, such as tree structure of executing openc2 commands, but proves that OpenC2 can be integrated in Security Playbooks and that it can provide us with coordinated defense actions in a simple form without adding nothing to the language, something that most of the people âdenyâ and advertise as limitation (including myself in the past).

The response codes and messages can be used to make the orchestration quite feasible (and if we need extensive capability, we can include nested response codes). For example:

Check if a hash is available in the endpoints  (.exe)

If we get a negative response code - the execution of the playbook âcanâ stop

If the hash is detected, we continue with the response actions of the playbook. These can be:

Check if there is a running instance/process - If the response brings a result that âyes there isâ  - stop the process

Delete the executable

Delete registry key

Etc. etc. etc

Restart the system(s)

How do we check if the system is restarted? Maybe after we issue the respective OpenC2 command we can send periodically openc2 commands that check if the consumer is alive (empty array - Query: features) or we can get the running time of the system.

So we donât have a really flexible playbook in terms of logic, but a basic one that OpenC2 can utilise. We move from command to command based on the response code of the previous command.

Everybody can share such playbooks for Incident Response with courses of action. When I detect something (IoC) we launch the playbook. Organisations can share OpenC2 playbooks.

This is just food for thought in case we want to bring some extra capability and use cases to OpenC2 formally through the working groups or informally into our solutions.

Best,

Vasileios Mavroeidis â Security Researcher and Ph.D. Research Fellow 
Research Group of Information and Cyber Security (SECURITY)
SecurityLab
University of Oslo  
+47 40347666