Nathan – Generally agree with one suggestion that we treat the action_language as a open-vocab so that we have some common ones defined in the spec but extensibility is also possible without any change the standard.
I also suggest that the ov define the tool and the version. For example python and its version will matter not just stating python.
Allan Thomson,
This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited
I would also like to add support for different languages in the next release. This would add a new property to COA that is “action_language” and the “action” property would be a string. Depending upon the language selected then that would determine the content syntax of “action.”
I think this would allow existing languages to be used immediately while the STIX community develops its own language that is supported by numerous vendors, orchestrators, and devices. It would also allow us to have different versions of our COA language if we wanted and may help with concerns of backwards and forwards compatibility.
Below are two examples of STIX COAs using this property. The first is an example of a COA that uses Bash. I thought this was a good example because after Heartbleed there were blog posts and articles on how to detect if your system was vulnerable to Heartbleed and how to update the system. To me that is a simple kind of COA that we could encapsulate in a STIX COA.
The second example is for a vendor specific COA/playbook encoding. Today security automation and orchestration vendors have proprietary languages for representing playbooks/COAs. The action_language property would allow people with the same type of orchestrator to exchange COAs. This would be useful early on until a common playbook/COA language is adopted by the vendors.
{
“type”: “course-of-action”,
"id": "course-of-action--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
"created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
"created": "2016-04-06T20:03:48.000Z",
"modified": "2016-04-06T20:03:48.000Z",
"name": "Heartbleed Detection COA",
"description": "Bash command to detect if system is vulnerable to Heartbleed"
“action_language”: “bash”
“action”: “[simple bash script that prints true if system is vulnerable to Heartbleed]”
}
{
“type”: “course-of-action”,
"id": "course-of-action--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
"created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
"created": "2016-04-06T20:03:48.000Z",
"modified": "2016-04-06T20:03:48.000Z",
"name": "Patch Apache Struts",
"description": "Detects if Apache Struts is not updated and updates it if needed"
“action_language”: “FireEye Security Orchestrator v1.0”
“action”: “[COA encoded using FSO’s syntax]”
}
I also feel that adding action_language property could be accomplished in the 2.1 release and have immediate impact for the STIX community. Creating a new programming language and then developing software to interpret and run the new programming language will take a long time. I would think at least a year. This way we can have something quite soon and start to learn how people are sharing COAs and what are some of the challenges with sharing COAs.
-Nate
CTI TC,
| Feature | Description | Example |
| Preventative Static COAs | Literal COAs tied to indicator or other objects. No need to wait for anything to fire. | SANS Top 20 controls or blacklist domains |
| Mitigative or Remediative Static COAs | All information to take the action is statically configured and known a-priori. | Deny traffic to and from 10.0.0.1 Delete Registry key |
| Accommodating multiple actions | Single COA representing multiple steps | Cleaning up malware from Windows Desktop - safe mode, kill process, delete key, delete file, etc. |
| Basic Sequencing | The order in which COAs should be executed | 1->2->3->4 |
| Allow parallel processing | Allow the actions to define if they can be done in parallel or if they need to be done one at a time | 1->2 3->4 |
If there are objections to this list, please let us know within 14 days. You can send your comments by replying to this email or in the COA channel on Slack.
Thanks,
STIX COA mini group