[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Object ID format
I would disagree with you assertions of what the 90% and 10% are.
I would suggest that well over 90% of actual production indicators (and remember this is about more than just indicators) will have an actual domain name specified. This is the way it is being used today and so far it has pretty positive feedback.
I would suggest that well under 10% are likely to be the exception cases that do not include it.
sean
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, January 21, 2016 at 2:00 PM To: "Barnum, Sean D." <sbarnum@mitre.org> Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Object ID format I would again assert that this is an example of making life worse for the ~ 90% to solve a corner case requested by the ~ 10%. It is an idea that sounds good on paper but when you dig into the actual end to end flows of creating intel and doing sharing and
the data flows around it, it's hardly ever in reality going to be able to be used.
The problem with burying the URL inside the object is it does not really support many of the use cases being discussed. The point is that the ID for the content can be used in an unambiguous resolvable way without having to parse into the object which for many use cases (e.g. A relationship without both end objects) you won’t have that object to parse into. I agree with a fixed format codified into the spec. My opinion is that the fixed format should be [ID authority domain name]/[object type]/[UUID] in such a way to support URI/URL use. sean From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Thursday, January 21, 2016 at 1:36 PM To: "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, "Barnum, Sean D." <sbarnum@mitre.org>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Object ID format I would really prefer the ID be a fixed format codified in the spec, and any URL be moved to an optional "external_reference" property. Or utilize the "external_ID" property discussed previously.
So the real question is, do we want to use a URI/URL or a [namespace]:[object-type]:[UUID]? What if we did both? Like maybe this: All discreet objects in CTI MUST include an ID that defined as an object-type plus a version 4 UUID, example "indicator:104abc69-509e-4bf9-b64c-81255292c433". You MAY also include an optional URL at the end of the ID if you want to map this object back to an actual resource found on a TAXII server, example "indicator:104abc69-509e-4bf9-b64c-81255292c433:https://taxii.somecompany.com/taxii2/collections/neat-indicators/id/104abc69-509e-4bf9-b64c-81255292c433" OR even better.. We pull this ID UUID stuff in to TAXII land and make sure that objects can be found by their ID. Then you do not need to include a full URL, but just collection location, example "https://taxii.somecompany.com/taxii2/collections/neat-indicators/" 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."
I’m supportive of standardizing Object ID format to be based on the form [producer-namespace]:[object-type]:[UUID], especially if that doesn’t prevent the use of URI. I think Terry correct captured many of the concerns that I had with the F2F proposed solution and I definitely in agreement with John A. about the value of being able to use URLs. Paul Patrick iSIGHT Partners --------------------------------------------------------------------- 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 [attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM] |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]