cti-stix — archive

Re: [cti-stix] Proposal - Top Level Relationship Object

From: John Wunder <[email protected]>
To: [email protected]
Date: Thu, 30 Jul 2015 17:54:00 -0000

FWIW I was mostly using that as a stand-in for some kind of producer construct. I feel like we're running into a lot of fundamental issues here (versioning, producer, IDs, serialization, etc.) and was hoping to somewhat limit our topic of discussion in this thread to just the relationship object. Obviously that failed :) John From: < [email protected] > on behalf of Jason Keirstead Date: Thursday, July 30, 2015 at 1:27 PM To: "Jordan, Bret" Cc: Aharon Chernin, " [email protected] " Subject: Re: [cti-stix] Proposal - Top Level Relationship Object I'd like to go into more detail on the producer field because I still don't feel the proposal John has solves my use case - maybe it does and he was just using MITRE as an example that could be expanded upon - and if so, please correct me. IE - I would like the producer to in the end be able to be tied all the way back to my TAXII authentication- the authority discussed on the list yesterday. This is more granular than just for example "IBM" - I would like to see a producer field than can be in the end be traced all the way back to "Jason [email protected] " inside the organization. Note, I am not saying that we should be sticking emails or user names in the producer field, but the producer should be able to have an ID that can be affiliated with a user, not restricted to simply an organization. This gets very important as soon as you move outside the simple "Corp to ISAO" bubble where everyone has trust, and get into "ISAO to ISAO" or, "ISAO to public to ISAO" and vice-versa... these various entities will have various trust levels, and they won't all have access to some kind of internal audit trail to be able to say "who at IBM did this bogus annotation?" These makings have to be able to be tied to an identity... - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---2015/07/30 02:15:34 PM---The reason why I like a top level Marking object is, I believe, and PLEASE correct me if my assumpti From: "Jordan, Bret" < [email protected] > To: Aharon Chernin < [email protected] > Cc: " [email protected] " < [email protected] > Date: 2015/07/30 02:15 PM Subject: Re: [cti-stix] Proposal - Top Level Relationship Object Sent by: < [email protected] > The reason why I like a top level Marking object is, I believe, and PLEASE correct me if my assumptions are wrong, that we could build a small repository of simple markings that will work for say 70% to 80% of the market. Then people just need to use those ID values. They become well known markings and it makes it easier to understand and process.. Then for those groups that need really super elaborate markings, they can do that as well. The other reason for having a top level marking object, is that I think people will end up using them over and over in side of an trust-group or eco-system, or in other parts of a STIX document. If I am wrong, please correct me.... Updated based on John's comments... I think we are getting close to the point of being able to pull this out of email and make it an official proposal in a wiki document... Things outstanding from my view: 1) Start and End times, 2) What does Reliability/Confidence actually look like inside, 3) Marking, 4) Type. Anyone want to take a stab at those? ID [1]: The ID of the relationship, a simple random GUID Marking [0..n]: The ID of the marking object that you should reference Version [1]: The version of the relationship; a simple number to be used with the ID for version control Type [1]: The “type” of relationship being expressed. (Not sure of how this works yet) Description [1]: A single simple and short description Source [1] : The ID of one or more source entities in the relationship as a URI (not QName) Targets [1..N]: The ID of one or more targets in the relationship as a URI (not QName) Start [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'. End [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'. Reliability / Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale. Producer [1]: A simple producer object like what John calls out Timestamp [1]: A timestamp in UTC stating when the relationship object was created. Thanks, Bret 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." [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]