OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions


Jason, 

I am a little confused. Hopefully you can clarify for me.

Your use case describes a state where you have to deal with “user-generated” values that you have no control over. I would certainly agree that neither the default vocab or a custom vocab defined by you would work here. This sort of case is exactly why the third option of free-form string is there.
I am not understanding what is missing in this option that you need. It looks like you are proposing adding an “Other” option to the default vocab and then adding some extra way to specify a free-form string.
Can you help me understand what this approach of “Other” plus free-form string gains us over just the free-form string for the value?
If the value can be any free-form string then value constraint checking on the default controlled vocabulary values seems meaningless anyway so why add the complexity of “Other” plus free-form string. 
If no vocab is specified then it is implicitly always “Other”. Your consumption of content could simply use a controlled vocab such the default one if it is specified and if it is not specified by the user/producer then it means “Other”.

When you say “user-generated” do you mean stuff coming from a particular user where they may consistently use the same values but that those values are different than the default vocab or do you mean completely random values coming from a wide range of unconstrained users?
If the former is the case then there is the option of having that user define their personal vocab as a custom vocab such that you can use that controlled vocabulary to validate content coming from them. You don’t have to be the one defining the vocab.
If the latter is the case then we are back to free-form field.

On the first question on whether thought had been given to extending the vocabulary, the answer is absolutely YES. None of the controlled vocabularies are cast in stone. They are open to community requests for addition/revision just like anything else in the language. The current default vocabs are the result of previous community inputs. For them to change and fill in any perceived gaps they require someone in the community to raise the issue and propose the appropriate changes so that they can be discussed and decided on. Such changes have occurred to vocabs in pretty much every minor or major release of STIX since it started.
Similarly, the “Other” option was proposed and discussed way back in the beginning and the current mechanism of free-form string without explicit vocab constraint was decided to be the most appropriate and least complicated solution.

sean

From: <cti-users@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, October 22, 2015 at 11:18 AM
To: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Subject: [cti-users] Indicator Type / Vocabulary Implementation Questions

HI all, I am producing some new STIX content in an automated fashion, and am looking for feedback on my planned usage of indicator types:

As with many things STIX, the way you do this is so wide open, it makes implementation decisions difficult


@see http://stixproject.github.io/data-model/1.2/stixVocabs/IndicatorTypeVocab-1.1/

So essentially, I can stick to the default vocabulary, *OR* I can define my own vocabulary, *OR* I can use it as a free-form string.

The problem i have with the default vocabulary, is this list is very restrictive, and there is no "Other" type.

First question - Has there ever been thought to extending this vocabulary, or adding an "Other" type that one could then annotate in some way? I haven't seen this question come up on the STIX list.

Second question - My other problem is, I can't define a new fixed vocabulary because this is user-generated stuff. I pretty much am stuck with either using the fixed vocabulary, or letting the user type in whatever they want. How many people are sticking to the controlled vocabulary here? If I use this as a free-form string, will it cause some tools to blow up? Anyone have experience here?



-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]