cti-stix — archive

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

From: Jason Keirstead <[email protected]>
To: [email protected]
Date: Fri, 31 Jul 2015 14:36:00 -0000

For (1), that should be a required part of producer should it not? For (2), there will not be collisions if the UUID is not left open and is specified to be an actual UUID ( IE RFC 4122 compliant ) Just playing devil's advocate. - 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 Terry MacDonald ---2015/07/31 09:43:33 AM---I would like the GUID to relate to the domain name namespace of the producer in some way. I think we From: Terry MacDonald <[email protected]> To: "Jordan, Bret" <[email protected]> Cc: "[email protected]" <[email protected]> Date: 2015/07/31 09:43 AM Subject: Re: [cti-stix] Proposal - Top Level Relationship Object Sent by: <[email protected]> I would like the GUID to relate to the domain name namespace of the producer in some way. I think we lose a couple of VERY important features if we just make it a random GUID. 1. We lose the direct link to the producers TAXII server: With a domain name namespace we know exactly the domain name we need to contact. We could then mandate that there needs to be a TAXII server at a particular location at a particular port ready to service other TAXII servers. e.g. Producer A has a TAXII server at taxii.producera.com . All Objects produced by Producer A have a GUID that includes https://taxii.producera.com . Consumer B gets a relationship object that points to an Object that Producer A generated, but Consumer B doesn't have the object itself. No matter! It knows exactly who to ask for the object. So Consumer B's TAXII client contacts https://taxii.producera.com directly and automatically negotiates permission to retrieve the object it needs. By including the domain name, we effectively negate the need for a separate field for maintaining TAXII server addresses. It comes built in for free. 2. GUID conflicts: By including the the domain name in the GUID, we gain the nice benefit that we cannot possibly have namespace collisions, thanks to the fact that domain names have to be unique. I really would be worried to move to a random GUID as we lose a ton of potential beneficial side effects that we wouldn't otherwise have. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E: [email protected] W: www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. Cheers Terry MacDonald STIX, TAXII, CybOX Consultant M: +61-407-203-026 E: [email protected] W: www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers. On 31 July 2015 at 02:38, Jordan, Bret < [email protected] > wrote: Okay so we have something like this so far. Need to flush out the Start and End Time stuff. ID [1]: The ID of the relationship, a simple random GUID Marking [1]: 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." On Jul 30, 2015, at 09:32, Wunder, John A. < [email protected] > wrote: Interesting thought. We could always move to raw GUIDs for the ID fields and add a "producer" field to all top-level constructs? How "machine-correlatable" does the producer name need to be? I.e. is it worthwhile to have a producer identifier and a pretty name, or is just the pretty name sufficient? You could do something like: { id: "123412totallyrandom13423", other_keys_go_here: true, producer: { name: "The MITRE Corporation", id: " mitre.org " } } Alternatively the producer can be a top-level object and you can reference it by ID, though that gets lengthy if you have a lot of small packages. John From: Aharon Chernin Date: Thursday, July 30, 2015 at 9:53 AM To: "Wunder, John A.", "Thompson, Dean", "'Jordan, Bret'" Cc: Patrick Maroney, 'Terry MacDonald', 'Jason Keirstead', " '[email protected] '", 'Chris O'Brien', 'JG on CTI-TC', Jon Baker Subject: Re: [cti-stix] Proposal - Top Level Relationship Object I am starting to not be a fan of using the ID Namespace for identifying producer. Based on my experience with community usage of STIX today, most organizations are using a shortname in the namespace and using their full properly stated name "pretty print name" in producer fields. Aharon Chernin CTO SOLTRA An FS-ISAC & DTCC Company 18301 Bermuda green Dr Tampa, fl 33647 813.470.2173 [email protected] www.soltra.com From: Wunder, John A. < [email protected] > Sent: Thursday, July 30, 2015 9:14 AM To: Aharon Chernin; Thompson, Dean; 'Jordan, Bret' Cc: 'Patrick Maroney'; 'Terry MacDonald'; 'Jason Keirstead'; '[email protected] '; 'Chris O'Brien'; 'JG on CTI-TC'; Baker, Jon Subject: Re: [cti-stix] Proposal - Top Level Relationship Object Yeah I completely agree, object-level markings are the way to go. I had mocked this up as something like: marking_ids: ["us-cert:TLP-GREEN", "mitre.org:marking-1234"] TLP would be some hardcoded marking IDs, no reason to redefine TLP:GREEN in every document. For things like copyright statements you could have a top-level marking object that defines the markings and reference by ID in the objects. This would not allow field-level markings. If you really need to do that you would publish multiple versions of the object, each with different data and different markings. That approach would work for multiple languages as well without requiring all description and title fields to be multiples. To address information source again (Jason's question), my opinion is that information source is contained in the ID and in the mechanism by which you get the document. TAXII can tell you who *actually* sent you the document, the ID namespace tells you who created it (assuming you trust the person that actually sent it to you). John From: Aharon Chernin Date: Thursday, July 30, 2015 at 8:42 AM To: "Wunder, John A.", "Thompson, Dean", "'Jordan, Bret'" Cc: Patrick Maroney, 'Terry MacDonald', 'Jason Keirstead', " '[email protected] '", 'Chris O'Brien', 'JG on CTI-TC', Jon Baker Subject: Re: [cti-stix] Proposal - Top Level Relationship Object I really like how this object is shaping up. I am going to throw another wrench in <OutlookEmoji-?.png> I would like us to move towards object level markings vs document level markings. One of the ways we can prepare for this is to ensure that all high level objects have the ability to be marked. How does the group feel about adding marking to the relationship object? Aharon Chernin CTO SOLTRA An FS-ISAC & DTCC Company 18301 Bermuda green Dr Tampa, fl 33647 813.470.2173 [email protected] www.soltra.com From: Wunder, John A. < [email protected] > Sent: Thursday, July 30, 2015 8:04 AM To: Thompson, Dean; 'Jordan, Bret' Cc: 'Patrick Maroney'; 'Terry MacDonald'; 'Jason Keirstead'; '[email protected] '; 'Chris O'Brien'; 'JG on CTI-TC'; Baker, Jon; Aharon Chernin Subject: Re: [cti-stix] Proposal - Top Level Relationship Object Thanks Bret, good points. Updated and removed the redundancy of both occurrence and optional/required statements. ID [1]: The ID of the relationship Version [ 1]: The version of the relationship; a simple number to be used with the ID for version control (instead of timestamp) Type [1]: The “type” of relationship being expressed. (Not sure of how this works yet) Descriptions [0..N]: Words about the relationship. Source_ID [1] : The ID of one or more source entities in the relationship as a URI (not QName) Target_IDs [1..N]: The ID of one or more targets in the relationship as a URI (not QName) Start_Time [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'. End_Time [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. Timestamp [1]: A timestamp in UTC stating when the relationship object was created. Also I apparently missed that Description is multiple elements. Is the intent behind that multiple languages? Multiple markings? Multiple paragraphs? If we do that, does that mean description needs to be something other than a plain array of strings? Keep in mind that STIX 1.2 is complicated for a reason. If we try to do everything that STIX 1.2 does we will end up with something just as complicated. Sometimes a simple 90% solution is better than a very complicated 99.9% solution. (If you can't tell, I would prefer to allow a single string description.) John From: "Thompson, Dean" Date: Thursday, July 30, 2015 at 3:33 AM To: "'Jordan, Bret'", "Wunder, John A." Cc: Patrick Maroney, 'Terry MacDonald', 'Jason Keirstead', " '[email protected] '", 'Chris O'Brien', 'JG on CTI-TC', Jon Baker, 'Aharon Chernin' Subject: RE: [cti-stix] Proposal - Top Level Relationship Object Hi, Whilst I agree that Start_Time should be made compulsory (although there could be reasons when you don’t know the exact start date), I am not sure that you can make End_Time [1] rather than [0..1]. There are times when you might not know the End_Time (for example a web site is still redirecting Angler malware), a security event of incident may be on-going. If we force End_Time to be compulsory, then that will either force producers to put in some fairy land End_Date, or for them to stamp the time that a STIX document was produced as the End_Time of the incident/indicator or relationship. This will cause issues later on or those that implement these repositories of data as well as consumers using the data because they may expire or dis-regard valid data primarily on the basis of the current time being greater than End_Time. Regards, Dean From: [email protected] [ mailto:[email protected] ] On Behalf Of Jordan, Bret Sent: Thursday, 30 July 2015 1:59 PM To: Wunder, John A. Cc: Patrick Maroney; Terry MacDonald; Jason Keirstead; [email protected] ; Chris O'Brien; JG on CTI-TC; Baker, Jon; Aharon Chernin Subject: Re: [cti-stix] Proposal - Top Level Relationship Object Timestamp is required so we need to change the value from [0..1] to just [1]. We should probably do the same for Start_Time and End_Time. I would also suggest that we maintain plurality rules so things that can have multiple we should make them plural. Target_IDs and Descriptions 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." <OutlookEmoji-?.png> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php