Re: [cti] Re: [EXT] [cti] Roadmap discussion and update

As Sarah outlined, Malware is mostly done and barring unforeseen problems it will be in STIX 2.1. So, what that means is that we are talking about the following three objects: Infrastructure, Event and COA. Let’s look at each in turn.

Infrastructure:

While a bunch of work has been done on Infrastructure by a number of us, there remain fundamental questions as to what use-cases Infrastructure is meant to address and how it is best structured to address them. There are also concerns about the potential for the introduction of Infrastructure to be perceived as adding another way of doing something (i.e. Indicators) – violating a key design principle of STIX 2.

Event/Incident:

I was of the opinion that we were relatively close to having a good solid foundation for an event object a couple of weeks ago. However, subsequent discussions haven’t converged into specific recommendations as to the structure of the object – we’re moving in the opposite direction as people enumerate all of the workflows that they want to support with this object. I’m not saying that this is wrong – it is what it is – but it does indicate that there are fundamental questions about what we want/need this object to do.

COA:

We have a stub COA object in STIX 2.0 that allows us to represent a human-readable description of a Course of Action. As we explored how we might add support for OpenC2 actions in STIX 2.1 COAs, it became clear that there is a gap between what STIX users would likely need in terms of the ability to express abstract courses of action associated with an indicator (i.e. block traffic to/from the specific IP that triggered an indicator) and what OpenC2 currently supports. Until we have closed this gap in some way, adding complex decision trees feels like overdesign for where we are at.

In short, there are big design questions surrounding each of these proposed objects and if we try to rush these we’re likely to get them wrong. Furthermore, it is hard to predict exactly when these will be done – meaning that STIX 2.1 wouldn’t be released until well into next year. That is too long to wait for the things that we already have done and ready to ship.

We are very close to a STIX 2.1 release that would add the following significant capabilities:

Confidence support
Opinion object
Intel Note object
Internationalization support
Location object
Malware object
IEP marking object
DNS Request/Response observables

Taken together this represents, in my opinion, more than enough functionality to justify a STIX 2.1 release this fall. Rather than this turning into a back and forth between Bret and myself, I encourage others to weigh in on this important question.

Thanks,

Rich

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Tuesday, August 8, 2017 at 2:30 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Re: [EXT] [cti] Roadmap discussion and update

All,

Given that STIX 2.0 was a MVP release, I am hoping that STIX 2.1 is a more widely useable release that has the majority of features that are needed to gain broader adoption. Given the three options that were outlined, I can not vote in favor of a version of STIX 2.1 that does not have Malware, Infrastructure, Event/Incident, and possibly COA. I think the first two are absolutely critical for taking STIX beyond just IOC sharing. Second, I think a lot of the market (think MISP) needs Event/Incident before they can even consider adopting STIX 2 in mass. Third, a lot of vendors are looking for COA to help them. While I do not think COA needs to get to the playbook level for this release, it does need to be able to document basic multi-action COAs (whether they be human or machine oriented).

I personally do not think going to market with short iterative releases is going to help with adoption. In fact, I think it will actually hurt adoption. If we do this what we will find is a fractured market of support for various versions of STIX 2. What we need is the market to converge to a very strong and stable version of STIX.

Proposal:

1) I would propose that we keep doing two official working calls a week

2) We encourage the mini-groups to come back with solid proposals in the next 2-4 months

3) We dedicate the Fall F2F to Event/Incident & COA

4) We dedicate the Winter F2F to Infrastructure

5) We look to release STIX 2.1 in the early spring.

Bret

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Sent: Tuesday, August 8, 2017 11:04:29 AM
To: cti@lists.oasis-open.org
Subject: [EXT] [cti] Roadmap discussion and update

CTI-TC,

We wanted to send a follow-up email regarding the roadmap conversation that was started on the last monthly call. From our original list of items we wanted to have in STIX 2.1, this is where we stand:

Finished:

Confidence, Intel Note, Opinion, Internationalization

Mostly done:

Location (review), Malware (finishing development, Friday call)

In Progress:

IEP, DNS Request/Response (Tuesday working call)

Still to come (or in mini-group):

COA, Infrastructure, Event/Incident

As mentioned during the meeting(s), we aren’t making fast enough progress through our roadmap in order to get all of these objects into a fall release. We have three choices:

Schedule more meetings, move faster

Instead of having 2 working calls per week, we could increase to 3 or 4.
In the opinion of the co-chairs, this is not really reasonable given our past experience trying to move faster.

Which really leaves us with two choices:

Accept it and delay the release

Trying to finish all these topics would probably push our release date for STIX 2.1 into spring or summer of 2018.
We would have to be cognizant of scope creep, not allowing new items to become “necessary” for 2.1 or the release date will be continually pushed.

Remove items from the release in order to get the things that are done or nearly done out sooner (deadline for new material would be Sept 30 so editorial work can begin in October) while giving us time to work on the things that need the time

Would keep things that are basically done: Internationalization, Confidence, Intel Note, Opinion, Location and Malware
Probably keep proposals that are fairly polished and just need to be reviewed: IEP, DNS Request/Response
Likely defer items that still have a lot of work: Infrastructure, COA, and Event

The general consensus of the co-chairs (without unanimity) is that that the third option is the most logical at the moment. Setting a hard deadline of Sept 30 would allow us to get a 2.1 update out with important new objects, but also allow us to give certain large topics (like COA, Infrastructure and Event) the full time and attention they need to get them right by pushing them to a later release. This would also allow our October F2F to focus on kick starting STIX 2.2.

Given that this committee works via consensus and that the co-chairs do not decide anything unilaterally, we would like to open this conversation up for wider discussion. Please chime in and let everyone know your preference.

Thanks,

Sarah Kelley

Senior Cyber Threat Analyst

Multi-State Information Sharing and Analysis Center (MS-ISAC)

31 Tech Valley Drive

East Greenbush, NY 12061

sarah.kelley@cisecurity.org

518-266-3493

24x7 Security Operations Center

SOC@cisecurity.org - 1-866-787-4722

This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .
.....

cti message