Agree with Brett, there is no way that we can or should dictate to consumers how they should process or store STIX, even hubs. In fact I foresee many products that will have TLp-type anonymization and filtering type capabilities that alter objects in-flight as a matter of course; saying these products have to maintain custom fields during that process could be burdensome and possibly make it so they can't interoperate properly at a public /private boundary (though some may choose to maintain the fields, it shouldn't be forced). As to the digital signature question, since we haven't yet broached how digital signatures will work, I feel it is too early to use this as part of the argument. Maybe digital signatures should not include custom fields as a matter of course. Or maybe the producer should have the optional ability to specify what fields are included in the signature. Or maybe we allow signing chains so that the entity that altered the object resigns it, maintaining the original signer as part of the authority chain. We don't know yet but there are several options here that do not require everyone to store fields they don't care about for all posterity. Sent from IBM Verse Jordan, Bret --- Re: [cti-stix] Custom properties --- From: "Jordan, Bret" <
bret.jordan@bluecoat.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: Sun, May 15, 2016 11:11 PM Subject: Re: [cti-stix] Custom properties The way I see the problem, vendors or commercial sources of CTI will probably be the only ones that will use Custom Properties (thus the reason why I originally called it Vendor Defined Fields). The average SOC that is using a tool will probably not edit said source of the tool to add a custom property.. And I can not imagine many tools in the early days giving an interface to the end user to create a new Custom Property on their own. Vendors and commercial sources will want to control the flow of their data and will probably only authorize it to be sent between certain tools and vendor-friendly products. Thus there will not be a problem. The problem you bring up has lots of potential problem. Think about mapping unknown content to a struct.. How are you to unmarshal the data so you can store it...? About all you could do is store the raw JSON and maybe index some of the fields you know about. But that becomes an implementation detail and about the only enforcement you can do is via out-of-band legal contracts. So while I agree this is an issue, I do not believe it is a specification level issue. I could see this being part of a Best Practices or Known Potential Issues document. I do believe that this is for sure a process level issue. 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 May 15, 2016, at 17:03, Terry MacDonald <
terry.macdonald@cosive.com > wrote: Hi Bret, > I disagree with requiring a consumer to store and process things that it can not understand or things that it does not know about.. That would be a near impossible order. I wasn't requesting that a consumer processes things it doesn't understand. I was however requesting that consumers do store what they don't understand. The consumers i was thinking of was community hubs, and the reason for this is sharing across multiple nodes within a community. As an example: If the producer supports a custom field x_thing, and it tries to send or some data to all of the members of the community, it is likely to do that through one or more community hubs. If the community hubs that receive the data do not support storing data that they don't understand, then they will effectively filter out the custom field x_thing, so that the final consuming org won't get the custom field at all. This also causes a problem when we move to digital signatures of content. If the digital signature was generated with the custom field included in the object, then when the custom field is filleted out at the hub, the digital signature will become invalid. If the custom field was allowed to be stored and ignored, then this problem wouldn't occur. Cheers Terry MacDonald > >> On May 14, 2016, at 17:39, Terry MacDonald <
terry.macdonald@cosive.com > wrote: >> >> 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], VND.ExampleInc.foo ) or primary domain name (e.g., com.example.foo or a Uniform Resource Identifier [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. >> >> 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. >> >> 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. >> >> Cheers >> Terry MacDonald >> >> On 14/05/2016 05:39, Allan Thomson <
athomson@lookingglasscyber.com > wrote: >>> >>> Hi Eric – with respect, there are many things that vendors will do with this standard that are legitimately private and will not be shared with the broader industry. In those cases, there will be no desire or need to have a single registry for those vendor extensions. >>> >>> >>> >>> There are also many use cases that will leverage STIX 2.0 *without* requiring a registry of vendor specific attributes. >>> >>> >>> >>> I think your suggestion on providing a registry is something the TC should consider as a separate item than the STIX2.0 specification and schema being defined right now. >>> >>> >>> >>> Regards >>> >>> >>> >>> Allan >>> >>> >>> >>> From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org >, Eric Burger <
ewb25@georgetown.edu > on behalf of Eric Burger <
Eric.Burger@georgetown.edu > >>> Date: Friday, May 13, 2016 at 12:20 PM >>> To:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Custom properties >>> >>> >>> >>> Also, the comment on the ballot that STIX is fluid and as such does not need a registry is tantamount to saying to the industry and developers, “PLEASE do not implement STIX. We have no idea what it is or what it will be, so you might as well go home now, wait a year or two, and look again when things get stable. >>> >>> >>>> >>>> On May 13, 2016, at 3:17 PM, Eric Burger <
Eric.Burger@georgetown.edu > wrote: >>>> >>>> >>>> >>>> The historic reason for X- is it used to take IANA months to register a protocol parameter. The more recent (early 2000’s) reason for X- is the IETF in its infinite wisdom required an Act of G-d to register something. The IETF has learned from its mistakes and allows for first-come, first-served parameter registration. See RFC 6648. >>>> >>>> >>>> >>>> We have neither problem. >>>> >>>> >>>> >>>> Stand up either a Wiki, GitHub repository, or, believe it or not, just ask IANA nicely for a FCFS registry, and we can have one. >>>> >>>> >>>> >>>> I would humorously offer we say, “Custom properties SHOULD NOT start with X-, unless those characters are meaningful, as in ‘X-Reference’ for Cross Reference or ‘X-factor’ for an unknown factor. >>>> >>>> >>>>> >>>>> On May 12, 2016, at 1:11 PM, John Anderson <
janderson@soltra.com > wrote: >>>>> >>>>> >>>>> >>>>> That RFC is pretty clear. X- is so 1990s. >>>>> >>>>> >>>>> >>>>> Why can't we have a registry? It could be as simple as a shared GitHub repository, which would have the advantage of version control. Official properties would probably be voted in, but it's easy enough to show the status of a property. Also, rather than spamming the list, someone could submit a Pull Request, which is much more developer-friendly and traceable. >>>>> >>>>> >>>>> >>>>> </end 2cents> >>>>> >>>>> JSA >>>>> >>>>> ________________________________ >>>>> >>>>> From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. <
jwunder@mitre.org > >>>>> Sent: Thursday, May 12, 2016 12:37 PM >>>>> To:
cti-stix@lists.oasis-open.org >>>>> Subject: [cti-stix] Custom properties >>>>> >>>>> >>>>> >>>>> Hey everyone, >>>>> >>>>> >>>>> >>>>> As you know, custom properties is currently moving the approval process (text:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.8072zpptza86 ). We’ve had a couple objections, from Mark Davidson and Eric Burger, to the use of the x_ prefix. Mark pointed us to
https://tools.ietf.org/html/rfc6648 >>>>> >>>>> >>>>> >>>>> My questions are: >>>>> >>>>> >>>>> >>>>> - Should we proceed as is and have a ballot on the current approach? >>>>> >>>>> - Should we just remove the SHOULD statement that recommends the x_ prefix? >>>>> >>>>> - Should we take things back to the drawing board and talk about running a property registry as indicated by RFC 6648? >>>>> >>>>> >>>>> >>>>> My opinion: at this point in our lifecycle as a community, we probably aren’t ready for a registry. We can use the informal process we talked about on the working call, where people can e-mail the cti-users list if there’s a property they want to make heavy use of. When we release a new version, if we want to move that to a standard we can have non-normative text deprecating the previous custom property and indicating that the new standards-based property should be used. I could go either way on keeping the SHOULD requirement for the x_ prefix, but given we’ve had strong agreement to keep it over previous calls I’m feeling like we should keep it as is. >>>>> >>>>> >>>>> >>>>> Given that, I would like to proceed with the ballot either today or later tomorrow. Just wanted to call out this important topic though. >>>>> >>>>> >>>>> >>>>> John >>>> >>>> >>> >>> > >