Re: [cti-stix] Labels property

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

You have the same danger the other way.

If you try to mandate a vocabulary when you do not extremely clearly understand all of the values that people may want to put into it, then you have a different form of bad data, because people are selecting random, incorrect labels just to allow their tool to enter the information. This is where we are today actually, based on my understanding and feedback I have heard from analysts on STIX 1.X.

-
Jason Keirstead
STSM, 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


Terry MacDonald ---08/03/2016 05:10:21 PM---That path forward seems pragmatic. The danger is in the transition of old data to the latter control

From: Terry MacDonald <terry.macdonald@cosive.com>
To: Bret Jordan <bret.jordan@bluecoat.com>
Cc: cti-stix@lists.oasis-open.org, "John A. Wunder" <jwunder@mitre.org>
Date: 08/03/2016 05:10 PM
Subject: Re: [cti-stix] Labels property
Sent by: <cti-stix@lists.oasis-open.org>

---

That path forward seems pragmatic. The danger is in the transition of old data to the latter controlled vocabularies. That's when some data may not be allowed within the latter spec when it was in the earlier spec and would need to be translated somehow as it leaves.

Cheers
Terry MacDonald
Cosive

On 4/08/2016 3:58 AM, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

IMHO, the path looks something like:

Step 1: An object has no suggested or controlled vocabulary.  The labels field is just an open string.  Put what ever you want in the field or do not use it, it is optional.

Step 2: We think we have a pretty good idea of what the labels field needs to be for an object, so we create a Suggested Vocabulary.  We are not a 100% sure yet, so the field is an "open" vocabulary.  The field is now required.  You are strongly suggested to use our vocabulary, but you can use your own terms if you want. But something must be there.  The whole point of a vocabulary is we think we understand the field well enough to know that you need something in the field.  

Step 3:  We fully understand the values that should be tied to an object.  Aka the Malware Type or Indicator Type.  At this point we lock down the field and make them a controlled vocabulary where you can only use one of the terms we define in the spec.  BTW, none of our objects are at this level.    

Now step 3 begs the question, should we be using the labels field to track these former "Malware Type" and "Indicator Type" like data. Or do we want to introduce fields specifically for the open/controlled vocabularies.  Or do we want to introduce fields for general purpose tagging, so as to not use the same field for two different things.  


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 Aug 2, 2016, at 15:12, Wunder, John A. <jwunder@mitre.org> wrote:

Hey everyone,
 
One topic that has come up recently is what to do about the labels property. Labels is similar to Gmail labels or tags…it’s a list of strings used to categorize an object. Some STIX Objects have a suggested vocabulary defined for the labels field, other objects don’t.
 
Right now, when the labels property DOES have a suggested vocabulary for that STIX Object, the field is required. This means that labels are required on indicator, incident, malware, course of action, report, threat actor, and tool. Since lists require a minimum of one item, that means each of those objects must have at least one label at all times.
 
On the other hand, if there’s no suggested vocabulary for a STIX Object, the field is optional. So labels are optional for attack pattern, campaign, intrusion set, observed data, source, victim target, vulnerability, relationship, and sighting.
 
Allan (and IIRC others, though to be honest it’s hard to follow these conversations sometimes) have suggested making the labels property optional across all STIX Objects. This would be more consistent, but it would mean that on objects where you could previously rely on a label (e.g. indicator) you cannot. It also means there’s more optionality.
 
That might be fine, but I thought it was worth bringing up. In particular, some fields (e.g. Indicator Type, Malware Type) used to be their own field but are now rolled in to labels. Given this change, that data now becomes optional.
 
What do you think? Any objections to making the labels property optional across the board? Anybody want to second it? Any other options?
 
Thanks,
John