Vasileios,
Email might be a clumsy way of doing this (non-zero probability that we will be talking past each other), we should set up a web conference or meeting however
this is an attempted reply for now:
IN your proof of concept, you are daisy chaining a series of commands to the actuator (did I capture that correctly) and you probably have some flag in the package
to indicate that they must be done sequentially or they may be done in whatever order. The notion of leveraging the response so that the orchestrator can either cancel, pause or make some other decision (based on the response) sounds reasonable to me.
I see red flags when branching courses of action and different commands being taken (or skipped) based on what happens to the state of the actuator as a result
of one or more of the intermediate atomic steps. A paper written by Patterson et al does a great job of highlighting my concerns (Please consider reading the halting problem at
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwip7qOvitjkAhWGmlkKHf-OAHkQFjAAegQIABAB&url= > . I think they did a really nice job
on it).
So in the context of OpenC2 what do we do? I see no harm in starting with the HTTPS spec (or take something like MQTT and draft a spec) and add a section that
defines a message type that is an array of atomic commands. This has about zero impact on the language specification, zero impact on the actuator profiles (well OK, at this time actuator profile is singular, but that will changeâ.).
At some future time, the cyber stakeholder community may choose to use the HTTPS on steroids spec, or go with the strategy of leveraging BPML or go with the pending
CACOA spec. From my perspective, I am satisfied. These are all specifications and/or standards that I can spell out in acquisition language. That is my selfish perspective. I want to hear what others think.
Thoughts?
From:
openc2@lists.oasis-open.org <
openc2@lists.oasis-open.org>
On Behalf Of Vasileios Mavroeidis
Sent: Tuesday, September 17, 2019 9:08 AM
To:
openc2@lists.oasis-open.org Cc: Vasileios Mavroeidis <
vasileim@ifi.uio.no>
Subject: [Non-DoD Source] [openc2] OpenC2 Simple Playbook
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