[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap
|
Hi Nathan, Thanks for the comment. I can agree with this model and thinking further, as per this, would OpenC2 be an action_language? The initial proposal had action_type=”openc2” followed by the action but there were
some comments on the validity and STIX best practices after which openc2 was promoted as a property. I see this in similar light. Bret, Allan, remember that discussion? Thanks, Jyoti Technical Leader, CTO office Security Business Group, Cisco Systems Inc. From: Bret Jordan <Bret_Jordan@symantec.com> I can go along with that... So the feature request is: Allow STIX COAs to document and record COAs that are written in various languages and include the language and its version as meta-data Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> 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,
CTO,
Lookingglass Cyber Solutions 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 From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Reller, Nathan S." <Nathan.Reller@jhuapl.edu> 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 From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> CTI TC, The COA mini group has been meeting on a weekly basis since a couple of weeks and we’ve put together a roadmap for the goals/features that we would like to address across 3 STIX releases. The mini group gave
a readout on the Sept 19th working call and the slides we presented are here –
https://docs.google.com/presentation/d/1be_i8zcIlsmo_sStB8jeAp33sah-z7SgVGw_eRm1omc/edit?usp=sharing In the first release, we would be solving the following 5 features for manual/automated COAs. For automated COAs, the group discussed using OpenC2 if the timelines align. More details on the complete roadmap
and use cases can be found in the working draft here -
https://docs.google.com/document/d/1zXV5WEmyLUbKiSpuHgywu5-LLrJVd91d7OP3nQBB7qM/edit#.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]