CTI STIX Subcommittee

I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.
 
First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important
tied to the STIX ecosystem.
 
Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which
mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so
I think scope-wise it’s broader than STIX.
 
For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull
in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think
it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)
 
John
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com>
Date: Thursday, September 21, 2017 at 2:18 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] STIX COA Roadmap


 

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 19 th 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# .

 
 




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.


Block evildomain.com
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
 
 

I think there might be a few options here.  But I do agree that STIX Patterning is in the same boat and we should solve both of them at the same time. Option 1: Keep COA and Patterning under the STIX umbrella Option 2: Split COA and Patterning out to their own Sub-Committees      a: The work products can be either their own specifications or extensions to STIX      b: While they might be able to have a bit more focus with dedicates new Chairs and Editors they would still be limited by the CTI TC's ability to focus on so many SCs Option 3:  Split COA and Patterning out to their own Technical Committees      a: The work product would be a specification      b: This would give the groups the ability to focus without the restrictions on load from the CTI TC Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, September 21, 2017 10:54:20 AM To: cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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    

John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     Attachment: smime.p7s Description: S/MIME cryptographic signature

I would concur. I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus a full operational cyber investigation characterization object in something like CASE. If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such externally defined representations. Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 3:23:05 PM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX COA Roadmap   John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

I was picturing the dividing line being here is a string that is my actions to execute and here are the input parameters to make it run. I keep trying to think if anything else is needed.   Bret, I also thought option four might be for COA language to be under the OpenC2 TC. Their mission statement is “Creating a standardized language for the command and control of technologies that provide or support cyber defenses.” I think I could see COA language fitting under that.   -Nate   From: Sean Barnum <sean.barnum@FireEye.com> Date: Thursday, September 21, 2017 at 3:36 PM To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I would concur. I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus a full operational cyber investigation characterization object in something like CASE. If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such externally defined representations.   Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 3:23:05 PM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX COA Roadmap   John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. Attachment: smime.p7s Description: S/MIME cryptographic signature

OpenC2 might be an option.  However, to date, the OpenC2 work has had a very narrow focus.   Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 2:22:20 PM To: Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] STIX COA Roadmap   I was picturing the dividing line being here is a string that is my actions to execute and here are the input parameters to make it run. I keep trying to think if anything else is needed.   Bret, I also thought option four might be for COA language to be under the OpenC2 TC. Their mission statement is “Creating a standardized language for the command and control of technologies that provide or support cyber defenses.” I think I could see COA language fitting under that.   -Nate   From: Sean Barnum <sean.barnum@FireEye.com> Date: Thursday, September 21, 2017 at 3:36 PM To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I would concur. I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus a full operational cyber investigation characterization object in something like CASE. If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such externally defined representations.   Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 3:23:05 PM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX COA Roadmap   John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

I don’t really have an opinion on which other TC, but I do agree that shifting to another TC is a reasonable option…I almost suggested it in my original e-mail but felt it would be coming off a bit strong.
 
When thinking about which TC, you can also look at the communities that are involved. If it’s a lot of the same people/orgs as who are already working on OpenC2 it might be a natural fit. If not, maybe that’s
a sign it belongs elsewhere.
 
John
 

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Thursday, September 21, 2017 at 4:29 PM
To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, Sean Barnum <sean.barnum@FireEye.com>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap


 


OpenC2 might be an option.  However, to date, the OpenC2 work has had a very narrow focus.  
Bret





From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu>
Sent: Thursday, September 21, 2017 2:22:20 PM
To: Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: [EXT] Re: [cti-stix] STIX COA Roadmap


 



I was picturing the dividing line being here is a string that is my actions to execute and here are the input parameters to make it run. I keep trying to think if anything else is needed.
 
Bret, I also thought option four might be for COA language to be under the OpenC2 TC. Their mission statement is “Creating a standardized language for the command and control of technologies that provide or
support cyber defenses.” I think I could see COA language fitting under that.
 
-Nate
 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Thursday, September 21, 2017 at 3:36 PM
To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] STIX COA Roadmap


 





I would concur.


I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA
Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus
a full operational cyber investigation characterization object in something like CASE.


If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of
automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such
externally defined representations.



 


Get
Outlook for iOS







From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu>
Sent: Thursday, September 21, 2017 3:23:05 PM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX COA Roadmap


 




John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree
that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and
versioning system. That was part of my decision to propose the action_language property to help separate the two items.
 
-Nate
 
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Thursday, September 21, 2017 at 12:54 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] STIX COA Roadmap


 

I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.
 
First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important
tied to the STIX ecosystem.
 
Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which
mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so
I think scope-wise it’s broader than STIX.
 
For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull
in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think
it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)
 
John
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com>
Date: Thursday, September 21, 2017 at 2:18 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] STIX COA Roadmap


 

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 19 th 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# .

 
 




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.


Block evildomain.com
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
 
 


This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

I agree with Nate that the OpenC2 TC makes a much more logical starting point than us trying to spin off a completely new TC with heavy overlap of OpenC2 but also agree with Bret that what is needed is broader than the current scope of OpenC2. I also don’t really think that a string property will be adequate to represent most externally defined actions. Some could be done that way but others would likely require more structure and detail. I think making a structured extension point for action makes more sense. One implementation might only use a string there but another could use a more complex structure. Get Outlook for iOS From: Bret Jordan <Bret_Jordan@symantec.com> Sent: Thursday, September 21, 2017 4:28:32 PM To: Reller, Nathan S.; Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap   OpenC2 might be an option.  However, to date, the OpenC2 work has had a very narrow focus.   Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 2:22:20 PM To: Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] STIX COA Roadmap   I was picturing the dividing line being here is a string that is my actions to execute and here are the input parameters to make it run. I keep trying to think if anything else is needed.   Bret, I also thought option four might be for COA language to be under the OpenC2 TC. Their mission statement is “Creating a standardized language for the command and control of technologies that provide or support cyber defenses.” I think I could see COA language fitting under that.   -Nate   From: Sean Barnum <sean.barnum@FireEye.com> Date: Thursday, September 21, 2017 at 3:36 PM To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I would concur. I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus a full operational cyber investigation characterization object in something like CASE. If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such externally defined representations.   Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 3:23:05 PM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX COA Roadmap   John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

As a CTI TC we should consider these things carefully and figure out how best to solve them as a whole.  For example, we have talked a lot over the past year that Patterning might be best on its own as well.  Are there other parts that fit in to that bucket?   Bret From: Sean Barnum <sean.barnum@FireEye.com> Sent: Thursday, September 21, 2017 2:35:39 PM To: Bret Jordan; Reller, Nathan S.; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap   I agree with Nate that the OpenC2 TC makes a much more logical starting point than us trying to spin off a completely new TC with heavy overlap of OpenC2 but also agree with Bret that what is needed is broader than the current scope of OpenC2. I also don’t really think that a string property will be adequate to represent most externally defined actions. Some could be done that way but others would likely require more structure and detail. I think making a structured extension point for action makes more sense. One implementation might only use a string there but another could use a more complex structure. Get Outlook for iOS From: Bret Jordan <Bret_Jordan@symantec.com> Sent: Thursday, September 21, 2017 4:28:32 PM To: Reller, Nathan S.; Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap   OpenC2 might be an option.  However, to date, the OpenC2 work has had a very narrow focus.   Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 2:22:20 PM To: Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] STIX COA Roadmap   I was picturing the dividing line being here is a string that is my actions to execute and here are the input parameters to make it run. I keep trying to think if anything else is needed.   Bret, I also thought option four might be for COA language to be under the OpenC2 TC. Their mission statement is “Creating a standardized language for the command and control of technologies that provide or support cyber defenses.” I think I could see COA language fitting under that.   -Nate   From: Sean Barnum <sean.barnum@FireEye.com> Date: Thursday, September 21, 2017 at 3:36 PM To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I would concur. I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus a full operational cyber investigation characterization object in something like CASE. If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such externally defined representations.   Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 3:23:05 PM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX COA Roadmap   John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

As a TC we should develop some guiding principles in this area just like we have for what's an SDO, etc. However, we need to be careful to not disrupt patterning unless there is a real problem to solve. Right now the TC is doing fine with the patterning spec and I would suggest that we don't mess with success. Sent with BlackBerry Work (www.blackberry.com) From: Bret Jordan < Bret_Jordan@symantec.com > Date: Friday, Sep 22, 2017, 4:39 AM To: Sean Barnum < sean.barnum@FireEye.com >, Reller, Nathan S. < nathan.reller@jhuapl.edu >, Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Re: [EXT] Re: [cti-stix] STIX COA Roadmap As a CTI TC we should consider these things carefully and figure out how best to solve them as a whole.  For example, we have talked a lot over the past year that Patterning might be best on its own as well.  Are there other parts that fit in to that bucket?   Bret From: Sean Barnum <sean.barnum@FireEye.com> Sent: Thursday, September 21, 2017 2:35:39 PM To: Bret Jordan; Reller, Nathan S.; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap   I agree with Nate that the OpenC2 TC makes a much more logical starting point than us trying to spin off a completely new TC with heavy overlap of OpenC2 but also agree with Bret that what is needed is broader than the current scope of OpenC2. I also don’t really think that a string property will be adequate to represent most externally defined actions. Some could be done that way but others would likely require more structure and detail. I think making a structured extension point for action makes more sense. One implementation might only use a string there but another could use a more complex structure. Get Outlook for iOS From: Bret Jordan <Bret_Jordan@symantec.com> Sent: Thursday, September 21, 2017 4:28:32 PM To: Reller, Nathan S.; Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap   OpenC2 might be an option.  However, to date, the OpenC2 work has had a very narrow focus.   Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 2:22:20 PM To: Sean Barnum; Wunder, John A.; cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] STIX COA Roadmap   I was picturing the dividing line being here is a string that is my actions to execute and here are the input parameters to make it run. I keep trying to think if anything else is needed.   Bret, I also thought option four might be for COA language to be under the OpenC2 TC. Their mission statement is “Creating a standardized language for the command and control of technologies that provide or support cyber defenses.” I think I could see COA language fitting under that.   -Nate   From: Sean Barnum <sean.barnum@FireEye.com> Date: Thursday, September 21, 2017 at 3:36 PM To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I would concur. I think there is definitely a place for a COA object within the STIX spec but it’s primary purpose is to associate a COA within the CTI context (e.g., if you have a sighting of Indicator X then suggest COA Y) but the details of the actions themselves and how they get deeply specified and carried out should be out of scope for STIX. I view this as very analogous to the STIX Malware object vs deep malware analysis with MAEC, and the STIX Investigation object versus a full operational cyber investigation characterization object in something like CASE. If we can clearly delineate this scope boundary it will help us more quickly focus on what is needed for STIX CTI exchange and not get tied up in the gory details (much of which is still very emergent) of automated COA specification and execution. This is especially true when you get to orchestration. STIX should remain flexible enough to reference and/or leverage detailed objects in other representations and should likely remain open to multiple possible such externally defined representations.   Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Reller, Nathan S. <Nathan.Reller@jhuapl.edu> Sent: Thursday, September 21, 2017 3:23:05 PM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX COA Roadmap   John, I have been having similar thoughts. The actions section of a COA object in my view is a new programming language (likely coupled with a display language for displaying the code as a graph). I agree that it seems like a different problem, and I also wondered if it was in scope for the CTI TC. It seems to be more geared toward automation and orchestration groups. I can also see the language taking on a life of its own with its own release schedule and versioning system. That was part of my decision to propose the action_language property to help separate the two items.   -Nate     From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Date: Thursday, September 21, 2017 at 12:54 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX COA Roadmap   I want to state my opinion carefully, because I feel like it would be easy to misinterpret it.   First, I think the direction these capabilities are going in makes sense. It provides a logical stepping stone from more basic stuff to more complicated stuff. I also think these capabilities are important tied to the STIX ecosystem.   Where I have concerns is that there is a lot of functionality described here. I can see it growing to be even longer than the Patterning document. It also is different in tone than the rest of STIX, which mostly describes a data model vs. functional capabilities (exception being patterning). Lastly, what’s described here for COA may be useful outside of the realm of threat intelligence (thinking vulnerability and configuration management in particular), so I think scope-wise it’s broader than STIX.   For all those reasons, I don’t think this should be treated as capabilities that are added directly to STIX. Instead, I think it should be published as a separate specification (work product) that we pull in to STIX and reference appropriately. We talked about at some point doing the same to Patterning, but because it was fairly lightweight we didn’t. If we were just talking Phase 1 here I would probably feel the same, but seeing where this is headed I think it’s better to preemptively assume that will be the case. If others agree w/ this approach we can figure out how organizationally to tackle it (assign editors, etc.)   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jyoti Verma (jyoverma)" <jyoverma@cisco.com> Date: Thursday, September 21, 2017 at 2:18 AM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] STIX COA Roadmap   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 19 th 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# .     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. Block evildomain.com 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     This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. This email an