cti-stix — archive

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

From: Mark Davidson <[email protected]>
To: [email protected]
Date: Thu, 30 Jul 2015 12:46:00 -0000

I posted this to the CTI STIX list, but I’m also sharing it here because it has some context and history of TAXII in it. -Mark From: [email protected] [mailto:[email protected]] On Behalf Of Davidson II, Mark S Sent: Thursday, July 30, 2015 8:43 AM To: Wunder, John A. <[email protected]>; Thompson, Dean <[email protected]>; 'Jordan, Bret' <[email protected]> Cc: 'Patrick Maroney' <[email protected]>; 'Terry MacDonald' <[email protected]>; 'Jason Keirstead' <[email protected]>; '[email protected]' <[email protected]>; 'Chris O'Brien' <[email protected]>; 'JG on CTI-TC' <[email protected]>; Baker, Jon <[email protected]>; 'Aharon Chernin' <[email protected]> Subject: RE: [cti-stix] Proposal - Top Level Relationship Object In TAXII 1.0/1.1, we defined messages at an abstract level (similar level to the summary John provides below). Here is an example from the TAXII 1.1 Services Spec: We then, in the XML Binding Spec, mapped these names and meanings into XML (note: the field order doesn’t align 100%): This worked relatively well for TAXII 1.1/1.0, and it may be worth taking the same path for this group’s discussion (Note: I am intentionally not mentioning specification organization). Start by defining the structure in a concrete but serialization-independent way (TAXII 1.x used tables; my understanding is that RDF/OWL is also an option) and then move to the serialization, which should end up being a very straightforward task by the time you get there and pick a format. I would also like to note a some mistakes we made and deficiencies in the TAXII 1.x approach: 1. Mistake: We didn’t have 100% naming alignment between the Services Spec and Binding Spec – this caused some confusion for implementers (See: Delivery Parameters / Push Parameters) 2. Deficiency: This approach spread the definition for a field across two documents. The “meaning” was in the TAXII Services Spec and the “serialization” was in the TAXII XML Message Binding. Implementers had to continually flip back and forth between documents. 3. Mistake or Deficiency (not sure): In some instances, a field was “required” in the Services Spec and “optional” in the XML binding. The rational was that the “meaning” of the field was retained in the XML because the XML field had a default value. This was counter-intuitive for implementers – they saw something marked as “required” in the Services Spec and were seeing TAXII Messages without that field. 4. Note: We had some rules in the TAXII Services Spec that couldn’t easily be expressed in XML (e.g., one field’s allowable values depending on the value of another field. See: Subscription Request/Subscription ID). In those cases, we chose not to attempt to express them. This is kind of a long way of saying: Let’s hold off on the format wars for now. Let’s focus on what we want to solve. Thank you. -Mark From: [email protected] [ mailto:[email protected] ] On Behalf Of Wunder, John A. Sent: Thursday, July 30, 2015 8:04 AM To: Thompson, Dean < [email protected] >; 'Jordan, Bret' < [email protected] > Cc: 'Patrick Maroney' < [email protected] >; 'Terry MacDonald' < [email protected] >; 'Jason Keirstead' < [email protected] >; '[email protected]' < [email protected] >; 'Chris O'Brien' < [email protected] >; 'JG on CTI-TC' < [email protected] >; Baker, Jon < [email protected] >; 'Aharon Chernin' < [email protected] > 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."