This is totally the same. A language (bash, python, js, whatever) has variables and control flow. The variables can be read from a STIX object:
ip_addrs = GetIndicator(indicator_uuid, “IP field name”)
And fed to a command:
target = make_target(“ip”, ip_addrs)
execute_oc2(action, target, actuator)
Provide your mechanism/syntax for referencing IP addresses, process names, file names and registry keys contained in a STIX indicators. That mechanism is what
the COA document and the COA interpreter use to generate commands.
From: openc2-imple@lists.oasis-open.org [mailto:openc2-imple@lists.oasis-open.org]
On Behalf Of Bret Jordan
Sent: Thursday, September 21, 2017 12:33 PM
To: duncan@sfractal.com; openc2-imple@lists.oasis-open.org
Subject: [Non-DoD Source] [openc2-imple] Re: [EXT] [openc2-imple] STIX COA 'Language'
This does not solve the STIX need of variables. That is totally different... STIX needs to do two things in future releases that require variables in the COAs.
1) I have a STIX Indicator that has 2000 IPs address in that are known to be bad. I want to block them. However, I do not want to copy all of the IPs in to the COA as that means they will just
get out of sync and it is terribly in efficient on the wire. We need the ability for the STIX COA to say, go get the list of things to block from this STIX Indicator property.
2) Some COAs will have things like stop process name A, delete file name B, and remove registry key C. However, you do not know the names of A, B, or C, until the malware actually runs and the STIX
Indicator fires. When the STIX Indicator fires it can feed the names of the process, filename, and registry key back in to the STIX COA to be sent to the SOC for either human or automated processing.
Bret
From: openc2-imple@lists.oasis-open.org <openc2-imple@lists.oasis-open.org>
on behalf of duncan@sfractal.com <duncan@sfractal.com>
Sent: Thursday, September 21, 2017 10:04:48 AM
To: openc2-imple@lists.oasis-open.org
Subject: [EXT] [openc2-imple] STIX COA 'Language'
The Implementation Committee might consider this for STIX COA interaction. If I understand correclty, the proponents below are suggesting sending actual code as
the COA. That solves the 'variables' and 'triggers' issues that OpenC2 does not support, yet still lets you send actual OpenC2 commands. I believe Dave Kemp has suggested similar at some point in our discussions. But that would mean we would need to define
the implementations of this - eg the python openc2 sdk.
Overall message is we need to get going on how to use OpenC2 in STIX COA (or we should just remove STIX COA from our use cases).
I'm sending this as email since the CTI input came as email. But discussion can/should occur via slack/googledocs/wiki to reduce spam.
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: Re: [cti-stix] STIX COA Roadmap
From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Thu, September 21, 2017 10:48 am
To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Jyoti Verma
(jyoverma)" <jyoverma@cisco.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
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.
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.
|
|
|
|
|
|
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
|
Accommodating multiple actions
|
Single COA representing multiple steps
|
Cleaning up malware from Windows Desktop - safe mode, kill process, delete key, delete file, etc.
|
|
|
The order in which COAs should be executed
|
|
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
|
|
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.
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://clicktime.symantec.com/a/1/YuPgiT0XMC2NM-KaGsBG5FKNejqvOkKqn7trBaXYJnc=?d=Dvg-PBt5ySUQSD5cj6vIZU8ioqmMXnm-8sawD-ubK3s6mYQ8P2-EooeM83P_KYz_fBge3Y1yQ0Exm3nSCeoERKdmZISD1u3S-TgM6HfUZKhnVttvJF7VHWxNB3ozDZuLo05xZEcU3u6tMxWfX_bUt6ldoBpJtVuNx7t_k-5GwHU54pjxLf6nzxQyMnc6dnp6xBKQrVSE3UXNvsiI6PM9I1sfbJB8YdJ0jj3duYXPGLdDG_X_LONfdVQKeMOHZ-H8qnTcJUudvP9u1y9QHIKa5e2gd2fI8IjH4bg3eMxkChwNTppBi21mkn7EQFBF7d5WLrvHhTrPkq-gv9jAumSjp5B_m7m78ypgJkMI0fLUHzia2oJ1iWB1aENdbaNMj2fENe1ITyWQBFauyctKY0ztRXcqFBKaMhpV-T_-vtkovze6J0unx5r4cKM5FI95Tzqtma0uADIS9WU6vEbTaZa__2e8t6MK_pqvV0shgpl0&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php
|