CTI STIX Subcommittee

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

This would, imho, go against interoperability and especially against automation. On Tuesday, 2 August 2016, 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

What does? That a field is optional? Allan On Tue, Aug 2, 2016 at 2:50 PM -0700, "Jerome Athias" < athiasjerome@gmail.com > wrote: This would, imho, go against interoperability and especially against automation. On Tuesday, 2 August 2016, 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

Yes sir The cybersecurity industry suffers from immaturity in the sense that the path integrate/standardize/automate is needed. APIs in products are good to have and help for integration. But if not standardized at the inter exchange level, like what we do here for the data interchange format: no or difficult automation. Benefits of the efforts of standardization at the categorization/classification level are clear for the community (note that my objective is serving the community, not the industry). Example of such would be CVE, CWE, CAPEC. It allows (at least in theory, meaning when properly understood and implemented (i.e. To make it work, and not just to add another "compatible with" logo for marketing)) automation via more interoperability between tools. I'm ok with a Label, basically tagging (attach any word(s) you want to a thing) mechanism. But, the benefits of common predefined controlled vocabularies for the end users (and sorry if you don't like some enumerations, if it doesn't match vendor A's one, or if 'difficult' (wow some costs) to implement) are high. (If one would argue against it, me happy to develop or prove me I'm wrong) So, I put that as a warning: "everything open"/"do what you want" approach for "flexibility" (or other reason$) will not, imho, help for optimization of the standardization effort 'we' have been working on here for 3+ years, and so, imhho, would not be optimized for the end users. Mappings are killing automation and have been pita for IT security ( for those who actually do the job). Take it as a warning against laziness  On Wednesday, 3 August 2016, Allan Thomson < athomson@lookingglasscyber.com > wrote: What does? That a field is optional? Allan On Tue, Aug 2, 2016 at 2:50 PM -0700, "Jerome Athias" < athiasjerome@gmail.com > wrote: This would, imho, go against interoperability and especially against automation. On Tuesday, 2 August 2016, 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

E.g. See 3.1.2. http://csrc.nist.gov/publications/drafts/nistir-8112/nistir_8112_draft.pdf On Wednesday, 3 August 2016, Jerome Athias < athiasjerome@gmail.com > wrote: Yes sir The cybersecurity industry suffers from immaturity in the sense that the path integrate/standardize/automate is needed. APIs in products are good to have and help for integration. But if not standardized at the inter exchange level, like what we do here for the data interchange format: no or difficult automation. Benefits of the efforts of standardization at the categorization/classification level are clear for the community (note that my objective is serving the community, not the industry). Example of such would be CVE, CWE, CAPEC. It allows (at least in theory, meaning when properly understood and implemented (i.e. To make it work, and not just to add another "compatible with" logo for marketing)) automation via more interoperability between tools. I'm ok with a Label, basically tagging (attach any word(s) you want to a thing) mechanism. But, the benefits of common predefined controlled vocabularies for the end users (and sorry if you don't like some enumerations, if it doesn't match vendor A's one, or if 'difficult' (wow some costs) to implement) are high. (If one would argue against it, me happy to develop or prove me I'm wrong) So, I put that as a warning: "everything open"/"do what you want" approach for "flexibility" (or other reason$) will not, imho, help for optimization of the standardization effort 'we' have been working on here for 3+ years, and so, imhho, would not be optimized for the end users. Mappings are killing automation and have been pita for IT security ( for those who actually do the job). Take it as a warning against laziness  On Wednesday, 3 August 2016, Allan Thomson < athomson@lookingglasscyber.com > wrote: What does? That a field is optional? Allan On Tue, Aug 2, 2016 at 2:50 PM -0700, "Jerome Athias" < athiasjerome@gmail.com > wrote: This would, imho, go against interoperability and especially against automation. On Tuesday, 2 August 2016, 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

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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

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 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.