| We will for sure need additional relationships to solve this. I am not sure I understand how you would have a Victim that is not tied to something. At the very minimum I think it would be tied to an Incident. Are you thinking you would have just a pile of Victims in your database that are not tied to anything?
I kind of see a UI working like:
1) Add Malware a) Describe malware b) Who was affected by this malware? (systems build identities and relationships behind the scenes)
2) Start Incident a) Describe incident b) Identity people working on incident (system does stuff behind the scenes) c) Identify people that were affected by this incident (system does stuff behind the scenes)
Thanks,
Bret Bret Jordan CISSPDirector 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."
The other thing I can see is that not identifying the identity directly as a victim (or a source, etc) could create an increase in the number of relationships required, as relationships are now the only way to identify the identity as a victim (or a source, or a first responder, etc). For example, if I want to identify in a victim, I create an identity, and then I am obligated to find something else to create a relationship to that identity that has the relationship type “targets”? So threat actor ‘targets’ identity makes a victim. Or malware ‘targets’ identity makes a victim. Or Campaign ‘targets’ identity makes a victim. Do we already have enough defined relationships to do this? Or will new relationships be required? Sarah Kelley Senior CERT Analyst Center for Internet Security (CIS) Integrated Intelligence Center (IIC) Multi-State Information Sharing and Analysis Center (MS-ISAC) 1-866-787-4722 (7×24 SOC) Follow us @CISecurity This really only effects a Threat Actor... With the inheritance model say you want to say that a Threat Targets is targeting a Victim Target. To do that you would have: Relationship Object that links Threat Actor with Victim Target With the single Identity model you would have: Identity Object for Threat Actor Relationship that links Identity Object for Threat Actor and the Threat Actor Object Identity Object for the Victim Target Relationship that links the Threat Actor Object to the Identity Object of the Victim Target If we choose to not do the single Identity model, then we need to create a separate TLO for every type of Identity that may exist. Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO 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." OK – so only where someone would like to have potential of having multiple related identities to a ‘thing’ would relationship be used. 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. Director of Security Architecture and Standards | Office of the CTO 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." 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? 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”. 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. 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. 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. 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). 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, 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.
|