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!

For Sightings and the use of the created_by_ref, you would only have 10K Sighting objects and 1 Identity Object.  The Sighting object has this "embedded" relationship that use the ID reference of the Identity to make the relationship linkage. 



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Aug 17, 2016, at 07:31, Allan Thomson <athomson@lookingglasscyber.com> wrote:

Thanks John.
So to be clear that I understand how the JSON would look in STIX.
If I have 10K sightings that were created_by the same entity (i.e. my product/entity) then with the relationship approach I will create 10K sightings and 10K relationships to the identity that represents my identity. Or is there a short-hand to creating a relationship that allows me to just point to my identity within a sighting as a relationship without having to construct a separate relationship object for each sighting?
So I now I have 20K objects in the STIX content with the relationship style vs 10K objects with a data attribute that points to the identity with inheritance?
Is that a correct understanding of the path?
From: "Wunder, John" <jwunder@mitre.org>
Date: Wednesday, August 17, 2016 at 6:08 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX 2.0 Status Update & Discussion Topics - Please Read!
Hey Allan,
We talked through some examples via that powerpoint. To give a few more in text:
Representing a Target of Malware
Via Inheritance: A malware object representing the malware would be related to a Victim Target representing the target. Victim Target would represent the identity information via fields like sector, nationality, name, etc.
Via Relationships: A malware object representing the malware would be related to an Identity object representing the target. Identity would represent the identity information via fields like sector, nationality, name, etc.
Representing Information Source
Via Inheritance: Any STIX object could contain an ID of a Source object in the created_by_ref field to indicate the identity of the source.
Via Relationships: Any STIX object could contain an ID of an Identity object in the created_by_ref field to indicate the identity of the source.
Representing Threat Actors
Via Inheritance: A STIX Threat Actor object would directly contain identity information about the actor (e.g. nationalities, name, etc.) as well as information about sophistication, resource level, goals, etc.
Via Relationships: A STIX Threat Actor object would contain only information about sophistication, resource level, goals, etc. A relationship of “attributed-to” (or something) would then relate that actor to an Identity representing the identity characteristics.
Representing Generic Identities
Via Inheritance: Modelers would have to determine whether an identity was a threat actor, source, or victim target before modeling the identity. Representing generic identities isn’t really doable.
Via Relationships: Modelers can use Identity directly without saying whether they’re an actor, source, victim target, or even multiple of those. This is particularly helpful when we get to Incidents to describe people reporting an incident, responding to an incident, etc. They don’t really fit into any of the existing buckets.
As I’m typing up these examples I’m realizing that “Via Relationships” is probably a confusing name. A better name for that approach might be “Single Identity SDO” vs. “Multiple Identity SDOs”.
Does that help?
From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Tuesday, August 16, 2016 at 9:25 PM
To: "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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.
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.
Thanks everyone,

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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