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: [cti-stix] STIX COA Roadmap


I'm inclined to agree with Nathan here. We have to be really careful about expanding the STIX specification to his magnitude.


Sent with BlackBerry Work
(www.blackberry.com)

From: Reller, Nathan S. <Nathan.Reller@jhuapl.edu>
Date: Friday, Sep 22, 2017, 4:23 AM
To: Sean Barnum <sean.barnum@FireEye.com>, 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 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.

 


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

 

 

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.



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