OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [EXT] Re: [cti-stix] STIX COA Roadmap


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

 

 

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]