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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] STIX 2.0 Status Update & Discussion Topics - Please Read!


John et al – were there examples of both approaches provided on the identity discussion?

 

Would like to see examples of both approaches to help understand the pros/cons.

 

allan

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Tuesday, August 16, 2016 at 12:56 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] STIX 2.0 Status Update & Discussion Topics - Please Read!

 

Hey everyone,

 

Here are my notes from the STIX Working Call held today, August 16. We had good consensus on most of these topics on the call and will be moving forward with the changes, so please speak up if you don’t like the direction.

 

Infrastructure Deferral to 2.1

No objections on the call, so we’ve pulled it from the 2.0 draft and will revisit then.

 

Incident Deferral to 2.1

There were some concerns, in particular from USG, but still fairly good consensus that it should be deferred for the time being to make sure we get it right. Thus, we’ve pulled it from the 2.0 draft and will revisit.

 

Malware & COA as Stubs in 2.0

There were no objections to retaining malware and COA and marking them as stubs. Both will be included with a note saying that they’re incomplete and we plan to expand them in 2.1+

 

Relationship Name Changes from Gary/DC3

No immediate concerns, we still need to identify exactly what changes that need to be made to the current objects and send to the list.

 

IEP (New Topic)

I identified a couple problem areas when I took the action to include IEP. Some fields were under-defined and other than an example there was no structured format defined by IEP. I’ve provided this feedback to the FIRST IEP SIG and, in line with our other actions to not define stuff that’s already defined externally, pulled the IEP definition. It will be replaced with a reference to IEP saying it will be defined by that group. There were no objections on the call to this approach.

 

Relationships limited to SDOs

We had very strong consensus that relationships should be limited to STIX domain objects…nobody had use cases for relationships from or to relationships. We updated the language to address this as a definitional item (as suggested on the call by Greg).

 

Identity Approach

There was a good discussion about the two different approaches (see attached). If you recall, we had previously discussed this and had landed on an “inheritance” based approach where identity fields are included across the different objects that have identity info (currently Threat Actor, Victim Target, and Source). After spending more time modeling and looking at it, several people had suggested that maybe we made that decision before we understood it enough and we should re-evaluate the relationship-based approach. In that approach, Identity is its own top-level object and other objects have relationships to Identity to capture identity info. More concretely: Source and Victim Target would be merged into Identity, which would have a superset of the relationships of those objects. Threat Actor would remain to capture things like Sophistication, Movitation, etc. and would also include a relationship to Identity to capture its identity info.

 

The people supporting the relationship-based approach (Rich S, Bret, Pat, others) felt pretty strongly that it was the right approach. Other people (Gary, Sarah) felt inheritance might be better but were OK with the relationship-based approach and in general seemed to feel less strongly about it. So given that I would call it consensus, though not particularly strong, that the relationship-based approach is the way to go.

 

This is an important decision: we have to live with it for the rest of the 2.x series. Please think it through and let us know if you have any strong objections to the relationship-based approach.

 

 

Near-Term Plans

Near-term, we’re hoping to release the STIX 2.0 Release Candidate tomorrow, August 17. As such, all comments should be made on the drafts by COB (eastern time) tomorrow. After COB tomorrow we’ll turn off comment access in Google Docs and require all comments be made on the mailing list…that way everyone can see what’s changing.

 

At the TC call this Thursday we’ll go through the release candidate, where it is, etc. We’ll also spend some time thinking about a roadmap for 2.1+.

 

As a reminder, here are the STIX 2.0 documents. Expect some churn over the next day as we implement the changes identified above.

 

1.      STIX Core: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit

2.      STIX Objects: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit

 

Thanks everyone,

John



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