< Return to Ballot details

Vote Details

Ballot: Approve Custom Properties (STIX 2.0-1, Section 5.1) text as working draft
Company:
Soltra
Vote:
No
Comment:
This will lead to chaos. We have the same problem now in 1.x and proposing this WITHOUT defining implementation requirements will cause the same result. Every custom roll your own extension will break interoperability. Maybe the system doesn't blow up when it gets STIX with "X_Because_IWantedTo" custom properties, but automation will not cascade between operators or different implementations so we #fail on the objective of a standard.

I would be in favor of a "registry process" perhaps with some review/approval /coordination of/with the CTI, but that just seems to me to be a short cut way to do a revision of the standard. Maybe that is more timely approach and a compromise, but we have to recognize that is inherently a compromise too albeit a better one than roll your own changes like the proposed would inevitably lead too.

An alternate I have considered is doing "de facto" stuff like this using marking syntax WITHIN an defined/existing payload field like say Descriptions. So any UI or automated processing that wants to use it has to look in the payload for the instruction/property, but if a system did not do this it would just see text. If it is something we want in the structure of the message then we revise STIX.

!@#Custom.acmeinc.scoring,Impact:high,Probability:low#@!

This of course is also problematic, but at least people who don't play (implement the extended property) can still see the extension somewhere in their solution they already handle things.