Title: Re: [cti-stix] Custom properties Great point... Forgive my distrust, I've been out in the left field of "schema on demand" for a while. I certainly empathize with having to look up one field in an object to process another. Alex -----Original Message----- From: John-Mark Gurney [
jmg@newcontext.com ] Sent: Wednesday, May 18, 2016 01:48 PM Central Standard Time To: Foley, Alexander - GIS Cc: 'Jason Keirstead'; 'Terry MacDonald'; 'Allan Thomson'; '
cti-stix@lists.oasis-open.org'; 'Eric Burger' Subject: Re: [cti-stix] Custom properties Foley, Alexander - GIS wrote this message on Wed, May 18, 2016 at 02:10 +0000: > Is namespacing properties really a good idea? > > How many different MTA security providers need to put their name in front of _score or _action for it to mean the same thing? If once _score is an integer from 1 through 100, and another is a string, and a third is an object, and a fourth is 1 through 10, then yes, having a name space will help prevent colissions and misunderstanding.. Having to check the created_by_ref field to decide how to decide how to understand a field isn't IMO a good method... > -----Original Message----- > From: John-Mark Gurney [
jmg@newcontext.com< mailto:
jmg@newcontext.com >] > Sent: Tuesday, May 17, 2016 04:11 PM Central Standard Time > To: Jason Keirstead > Cc: Terry MacDonald; Allan Thomson;
cti-stix@lists.oasis-open.org; Eric Burger > Subject: Re: [cti-stix] Custom properties > > > Jason Keirstead wrote this message on Tue, May 17, 2016 at 16:17 -0300: > > I am still not sure of this "domain name" syntax. Say IBM and Newcontext > > I think that's partly why it's a SHOULD now, and not a must... > > > and LookingGlass all get in a room and decide in our secret-squirrel-club > > that we will all support the "uber" property for indicators. Whose domain > > name do we prefix it with? Is it a fight to the death? IMO this is a very > > Part of having one domain is that you'd at least (hopefully) know who to > talk to if you received a document w/ it in it and want to try to use it... > > It was also added as a way to try to prevent duplication, where two different > companies w/o talking to each other added x_decay, and now you have a > conflict... > > > important question because in reality, this is how custom properties will > > very often be used. A couple of vendors will want to inter-operate on some > > level that is not yet part of the standard, and won't want or have the > > ability to wait for it to be standardized. > > If they can't agree on which domain name, (or register a new one for > branding), I doubt that the collaboration will last that long.. :) > > > I don't really see how this RFC proposes this problem be solved. The RFC > > seems to presume it is always some single entity in isolation coming up > > with a new HTTP header or whatnot; this is rarely the case because why > > would a vendor care about registering something that they only use > > internally? If I am only using a parameter internally then this whole train > > The RFC is a first come, first serve... If I'm the first one to register > decay, then I get to define it my way.. and if someone else wants decay, > they'll have to pick another name, like decay1, or decay_rate, etc. > > This also means that if a registry is used, that if we want to be forwards > compatible (2.0 docs work w/o modification on 2.1), that we won't be able > to repurpose any fields that are registered, which restricts what the TC > can do in the future... > > > of thought is irrelevant because at the end of the day I wouldn't even > > care about standards compliance at all (IE if I am only talking to myself, > > I would not care if I was using "compliant STIX" over that channel. > > Compliance only matters when you're talking to others). > > Exactly... If you're using it internally, you probably aren't using STIX > to pass the information around... STIX in an inter-product or > inter-organization exchange format... > > > From: John-Mark Gurney <
jmg@newcontext.com> > > To: Terry MacDonald <
terry.macdonald@cosive.com> > > Cc: Allan Thomson <
athomson@lookingglasscyber.com>, > >
cti-stix@lists.oasis-open.org, Eric Burger > > <
Eric.Burger@georgetown.edu> > > Date: 05/16/2016 09:46 PM > > Subject: Re: [cti-stix] Custom properties > > Sent by: <
cti-stix@lists.oasis-open.org> > > > > > > > > Terry MacDonald wrote this message on Sun, May 15, 2016 at 09:39 +1000: > > > The rfc states in appendix b that : > > > > > > When it is extremely unlikely that some parameters will ever be > > > standardized. In this case, implementation-specific and private- use > > > parameters could at least incorporate the organization's name (e.g., > > > "ExampleInc-foo" or, consistent with [RFC4288 > > > <
https://tools.ietf.org/html/rfc4288 >], "VND.ExampleInc.foo") or primary > > > domain name (e.g., "com.example.foo" or a Uniform Resource Identifier [ > > > RFC3986 <
https://tools.ietf.org/html/rfc3986 >] such as " > > >
http://example.com/foo "). > > > > > In my mind I would accept replacing the x_ should with a must, and saying > > > that the custom properties must contain the domain name of the > > organisation > > > that invented it. > > > > Even as much as I don't like the reverse order domain name, IMO, for > > things like this, it should be used... > > > > I too would prefer a MUST too, but others disagreed. > > > > > I also would like it defined that an unknown field within an object means > > > that the unknown fields are ignored, but as much of the object data that > > is > > > known is processed. At the moment it appears to be up to the implementer > > to > > > decide what to do. We should mandate one way.. And my vote is that only > > the > > > unknown field are ignored during processing, but are not discarded. My > > > reasoning is that of you are a recipient of an object with an unknown > > field > > > you want to extract as much information out of it that you understand as > > > possible, and if you don't understand a little bit of it then that should > > > be ok. > > > > I have a feeling that this is what most implementations will do, as if you > > can't import someone's STIX, even though it's standards compliant, you'll > > get customer complains... > > > > > The problem with this stance is that the implementers need to ensure that > > > the whole object is retained to keep the validity of the object > > (especially > > > with future cryptographic validation of authenticity) even though they > > may > > > not understand some of the data they are storing. In my mind this is > > still > > > OK, because of someone is acting as a community hub, you want the data to > > > pass through them undisturbed. > > > > I'd think it's up to the implementation to decide if they want to be > > able to validate an object's signature after import. If you aren't > > passing the data on, there may not be a need to do any signature > > validation after importing into your DB. -- John-Mark This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.