Re: [cti-stix] Labels property

I agree.

You can build a path toward a mandatory controlled vocab in a number of ways. While STIX is currently phrased as declarative statements on what is present in a legal STIX object, this is a convenience, and not actually what happens - what happens is that some software consumes STIX objects and other software produces them. This allows us to make something mandatory over time.

So for Step 1, we can MAY have a label.

For Step 2, we can say producers SHOULD include a label - SHOULD is 99% of a MUST, but allows just enough wiggle-room to avoid declaring all existing producers as being no longer conformant.

For Step 3 (or 4), we can producers MUST include a label, consumers MUST handle legacy objects without.

The only problem I see is that because the group made open and controlled vocabularies as fundamentally different types, the transition is much harder than it ought to be.

My only question remaining question is whether we can jump straight to step 2 for the objects where we're currently mandating labels?

On 3 August 2016 at 16:57, 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

Dave Cridland

phone +448454681066

email dave.cridland@surevine.com

skype dave.cridland.surevine

Surevine

Participate | Collaborate | Innovate

Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND

If you think you have received this message in error, please notify us.

cti-stix message