[cti-users] Indicator Type / Vocabulary Implementation Questions

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[cti-users] Indicator Type / Vocabulary Implementation Questions

Jason Keirstead

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

JA
Reply | Threaded
Open this post in threaded view
|

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

JA
1) We should establish a review/enhancement/update process for the
default controlled vocabularies.
(reuse was good but needs to evolve)

2) Tools should not cry, but 'Other' in general will lead to bad
scenarios (bad statistics/metrics and automation...)

Note that use of an Ontology (where 'synonyms' are defined) would help
solving this issue.







2015-10-22 18:18 GMT+03:00 Jason Keirstead <[hidden email]>:

> 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
>
>
> "The default vocabulary type is IndicatorTypeVocab-1.1 in the
> http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined
> in the stix_default_vocabularies.xsd file or at the URL
> http://stix.mitre.org/XMLSchema/default_vocabularies/1.2.0/stix_default_vocabularies.xsd.
> Users may also define their own vocabulary using the type extension
> mechanism, specify a vocabulary name and reference using the attributes, or
> simply use this as a string field."
>
>
> @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
>

This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/

Reply | Threaded
Open this post in threaded view
|

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

Jason Keirstead
In reply to this post by Jason Keirstead

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


Inactive hide details for "Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to ha"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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



Reply | Threaded
Open this post in threaded view
|

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

Wunder, John A.
It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


Inactive hide details for "Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to ha"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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





This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
Reply | Threaded
Open this post in threaded view
|

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

Aharon Chernin
In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX easier for software developers, but more difficult for product owners who are trying to push the boundaries of STIX within their products. Just the other day I was working on a proposal that had us doing something different with STIX that required us to release a few custom vocab entries. However, I could argue against custom vocabs as I have seen implementations of STIX that do not understand the whole concept of including additional XSDs in the namespace/header portion of the XML document.



Aharon

From: <[hidden email]> on behalf of "Wunder, John A." <[hidden email]>
Date: Thursday, October 22, 2015 at 1:14 PM
To: Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


Inactive hide details for "Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to ha"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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





This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
Reply | Threaded
Open this post in threaded view
|

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

Jason Keirstead

The other issue with using XSDs to define custom vocabularies is

- It is not always possible for an implementer to easily put such artifacts up on the internet in a vendor-controlled space; and

- Many STIX-consuming systems will not have access to the internet at all, so they can't download the XSD to begin with

But to re-iterate - I can't even use a custom vocabulary here as this is generated content and this user-generated content, which obviously can't auto-generate an XSD and put it on the internet.

My options are either (a) Limit the user to only the controlled vocabulary, or (b) Use the controlled vocabulary as a defaut, but in the end let them use any string

-
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


Inactive hide details for Aharon Chernin ---2015/10/22 03:04:36 PM---In regards to forcing a controlled vocab in STIX 2, I am tAharon Chernin ---2015/10/22 03:04:36 PM---In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX ea

From: Aharon Chernin <[hidden email]>
To: "Wunder, John A." <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/10/22 03:04 PM
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
Sent by: <[hidden email]>





In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX easier for software developers, but more difficult for product owners who are trying to push the boundaries of STIX within their products. Just the other day I was working on a proposal that had us doing something different with STIX that required us to release a few custom vocab entries. However, I could argue against custom vocabs as I have seen implementations of STIX that do not understand the whole concept of including additional XSDs in the namespace/header portion of the XML document.



Aharon

From: <[hidden email]> on behalf of "Wunder, John A." <[hidden email]>
Date:
Thursday, October 22, 2015 at 1:14 PM
To:
Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Subject:
Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date:
Thursday, October 22, 2015 at 1:10 PM
To:
"Palmer, Cliff A. (NE)" <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Subject:
RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


Inactive hide details for "Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to ha"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From:
"Palmer, Cliff A. (NE)" <[hidden email]>
To:
Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date:
2015/10/22 12:55 PM
Subject:
RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (
https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.


Cliff Palmer


From:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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



This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive:
http://lists.oasis-open.org/archives/cti-users/
List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee:
https://www.oasis-open.org/committees/cti/
Join OASIS:
http://www.oasis-open.org/join/
[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]

Reply | Threaded
Open this post in threaded view
|

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

Jordan, Bret
In reply to this post by Aharon Chernin
Extensibility and the whole xsi-type concept only works if you can guarantee that every implementer of every product and device will "fully" implement it.  If not, then you have things breaking all over the place.  And our efforts of making sure we can accommodate every possible use-case, means, that in practical terms no one can actually communicate unless they are using the same software package (which is not realistic).  Simplicity will gain us adoption, and from adoption we can iterate over time and add features. 

I am in strong favor of "one-way-of-doing-things".  I am also in strong favor of getting rid of and simplifying the extensibility so that we can guarantee interoperability.  

To Jason's points, I would suggest we add an option for "other" and we also try to be more diligent about updating the controlled vocabulary.  Maybe go so far as to say that every January we will rev the controlled vocabularies.  



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 Oct 22, 2015, at 12:04, Aharon Chernin <[hidden email]> wrote:

In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX easier for software developers, but more difficult for product owners who are trying to push the boundaries of STIX within their products. Just the other day I was working on a proposal that had us doing something different with STIX that required us to release a few custom vocab entries. However, I could argue against custom vocabs as I have seen implementations of STIX that do not understand the whole concept of including additional XSDs in the namespace/header portion of the XML document.



Aharon

From: <[hidden email]> on behalf of "Wunder, John A." <[hidden email]>
Date: Thursday, October 22, 2015 at 1:14 PM
To: Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


<graycol.gif>"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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



<graycol.gif>
This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/


signature.asc (859 bytes) Download Attachment
JA
Reply | Threaded
Open this post in threaded view
|

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

JA
I think the controlled vocabularies are a great topic for the Interoperability TC


On Thursday, 22 October 2015, Jordan, Bret <[hidden email]> wrote:
Extensibility and the whole xsi-type concept only works if you can guarantee that every implementer of every product and device will "fully" implement it.  If not, then you have things breaking all over the place.  And our efforts of making sure we can accommodate every possible use-case, means, that in practical terms no one can actually communicate unless they are using the same software package (which is not realistic).  Simplicity will gain us adoption, and from adoption we can iterate over time and add features. 

I am in strong favor of "one-way-of-doing-things".  I am also in strong favor of getting rid of and simplifying the extensibility so that we can guarantee interoperability.  

To Jason's points, I would suggest we add an option for "other" and we also try to be more diligent about updating the controlled vocabulary.  Maybe go so far as to say that every January we will rev the controlled vocabularies.  



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 Oct 22, 2015, at 12:04, Aharon Chernin <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;achernin@soltra.com&#39;);" target="_blank">achernin@...> wrote:

In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX easier for software developers, but more difficult for product owners who are trying to push the boundaries of STIX within their products. Just the other day I was working on a proposal that had us doing something different with STIX that required us to release a few custom vocab entries. However, I could argue against custom vocabs as I have seen implementations of STIX that do not understand the whole concept of including additional XSDs in the namespace/header portion of the XML document.



Aharon

From: <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...> on behalf of "Wunder, John A." <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jwunder@mitre.org&#39;);" target="_blank">jwunder@...>
Date: Thursday, October 22, 2015 at 1:14 PM
To: Jason Keirstead <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Jason.Keirstead@ca.ibm.com&#39;);" target="_blank">Jason.Keirstead@...>, "Palmer, Cliff A. (NE)" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Cliff.Palmer@gd-ms.com&#39;);" target="_blank">Cliff.Palmer@...>
Cc: "<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@..." <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...> on behalf of Jason Keirstead <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Jason.Keirstead@ca.ibm.com&#39;);" target="_blank">Jason.Keirstead@...>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Cliff.Palmer@gd-ms.com&#39;);" target="_blank">Cliff.Palmer@...>
Cc: "<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@..." <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


<graycol.gif>"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Cliff.Palmer@gd-ms.com&#39;);" target="_blank">Cliff.Palmer@...>
To: Jason Keirstead/CanEast/IBM@IBMCA, "<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@..." <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank"> cti-users@... [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">mailto:cti-users@...] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank"> cti-users@...
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



<graycol.gif>
This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-subscribe@lists.oasis-open.org&#39;);" target="_blank">cti-users-subscribe@...
Unsubscribe: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-unsubscribe@lists.oasis-open.org&#39;);" target="_blank">cti-users-unsubscribe@...
Post: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...
List help: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-help@lists.oasis-open.org&#39;);" target="_blank">cti-users-help@...
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/

Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by Jason Keirstead
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: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 11:18 AM
To: "[hidden email]" <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by JA
I agree to all of the below. :-)




On 10/22/15, 11:31 AM, "[hidden email] on behalf of Jerome Athias" <[hidden email] on behalf of [hidden email]> wrote:

>1) We should establish a review/enhancement/update process for the
>default controlled vocabularies.
>(reuse was good but needs to evolve)
>
>2) Tools should not cry, but 'Other' in general will lead to bad
>scenarios (bad statistics/metrics and automation...)
>
>Note that use of an Ontology (where 'synonyms' are defined) would help
>solving this issue.
>
>
>
>
>
>
>
>2015-10-22 18:18 GMT+03:00 Jason Keirstead <[hidden email]>:
>> 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
>>
>>
>> "The default vocabulary type is IndicatorTypeVocab-1.1 in the
>> http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined
>> in the stix_default_vocabularies.xsd file or at the URL
>> http://stix.mitre.org/XMLSchema/default_vocabularies/1.2.0/stix_default_vocabularies.xsd.
>> Users may also define their own vocabulary using the type extension
>> mechanism, specify a vocabulary name and reference using the attributes, or
>> simply use this as a string field."
>>
>>
>> @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
>>
>
>This publicly archived list provides a forum for asking questions,
>offering answers, and discussing topics of interest on STIX,
>TAXII, and CybOX.  Users and developers of solutions that leverage
>STIX, TAXII and CybOX are invited to participate.
>
>In order to verify user consent to OASIS mailing list guidelines
>and to minimize spam in the list archive, subscription is required
>before posting.
>
>Subscribe: [hidden email]
>Unsubscribe: [hidden email]
>Post: [hidden email]
>List help: [hidden email]
>List archive: http://lists.oasis-open.org/archives/cti-users/
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>CTI Technical Committee: https://www.oasis-open.org/committees/cti/
>Join OASIS: http://www.oasis-open.org/join/
>
Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by Jason Keirstead
Comments inline

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.


[sean]I don’t see any way that this could be practical. I would propose that there is no way we could define a single controlled vocabulary applicable for all cases and contexts. This is the reason we have a “default” vocabulary rather than “the” vocabulary. Such a decision would rule out STIX as an option for a good portion of the user community that STIX is targeted to support.


I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")


[sean]As I stated in my previous reply, all default vocabs are open to community suggestions for improvement. The IndicatorType default vocab is especially understood to need more love so please feel free to create an issue in the tracker pointing out the gaps you see and offering proposed values. The “potential” dimension that you mention is what Confidence on the Indicator is for. The Type is an assertion of what type of Indicator the producer believes it is. Any uncertainty around whether the observable pattern of the Indicator accurately identifies that Type is expressed using Confidence.



-
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


Inactive hide details for "Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to ha"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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





This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by Aharon Chernin
Comments inline

From: <[hidden email]> on behalf of Aharon Chernin <[hidden email]>
Date: Thursday, October 22, 2015 at 2:04 PM
To: John Wunder <[hidden email]>, Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX easier for software developers, but more difficult for product owners who are trying to push the boundaries of STIX within their products.

[sean]I would go further to propose that it is not only "product owners who are trying to push the boundaries of STIX within their products” who would find it more difficult (or in many cases impossible) but also large swaths of users in specific sharing communities or inter-tool exchanges who may need to characterize non-standard and/or more specific values for controlled vocabulary properties.

Just the other day I was working on a proposal that had us doing something different with STIX that required us to release a few custom vocab entries. However, I could argue against custom vocabs as I have seen implementations of STIX that do not understand the whole concept of including additional XSDs in the namespace/header portion of the XML document.

[sean]So, I would argue here that the answer is not to cripple needed capability but rather to find ways to help implementers do things correctly and more easily. I would also say let’s not get caught up in XML-centric issues as that is very likely not going to be the only option going forward.



Aharon

From: <[hidden email]> on behalf of "Wunder, John A." <[hidden email]>
Date: Thursday, October 22, 2015 at 1:14 PM
To: Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


Inactive hide details for "Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to ha"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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





This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
Reply | Threaded
Open this post in threaded view
|

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

Jason Keirstead
In reply to this post by Barnum, Sean D.

> 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 everyone is OK with using free-form string, then that is what I will use, and it makes things easier on my end for sure.

I just wanted to make sure there weren't known tools out there expecting this string to always be present in a vocabulary.

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

A user creates a rule in their SIEM, and wants to have anything that matches that rule, treated as threat intel, and pushed out to their STIX repository via TAXII. The logic behind that rule can be absolutely anything including deep analytics and behavioural analysis - so the "type" description you need for that indicator, can also be absolutely anything. The current default vocabulary is far to small to encompass all possible use cases for user-defined rules creating automated threat intel.

-
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


Inactive hide details for "Barnum, Sean D." ---2015/10/22 03:53:15 PM---Jason, I am a little confused. Hopefully you can clarif"Barnum, Sean D." ---2015/10/22 03:53:15 PM---Jason, I am a little confused. Hopefully you can clarify for me.

From: "Barnum, Sean D." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 03:53 PM
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
Sent by: <[hidden email]>





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: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date:
Thursday, October 22, 2015 at 11:18 AM
To:
"[hidden email]" <[hidden email]>
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



Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by Jordan, Bret
Comments inline


From: <[hidden email]> on behalf of "Jordan, Bret" <[hidden email]>
Date: Thursday, October 22, 2015 at 2:15 PM
To: Aharon Chernin <[hidden email]>
Cc: John Wunder <[hidden email]>, Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

Extensibility and the whole xsi-type concept only works if you can guarantee that every implementer of every product and device will "fully" implement it.  
If not, then you have things breaking all over the place.  

[sean]I would argue that this is fundamentally not true. The entire extensibility approach built into the language is designed such that every implementer can decide which profile of the language they wish to support. This may mean that they support particular extensions or that they support no extensions at all other than the default ones. Each extension is defined explicitly such that there is no ambiguity on what it is and implementers have a clear specification of what structure they need to support if they choose to support that extension. If an implementer chooses not to implement certain (or any) extensions they need to understand that by doing so they limit their ability to interoperate with other implementers who do implement them. Is it possible for every implementation to be fully interoperable for all information with every other implementation? No. I would argue that this will never be possible because different implementations (CTI platform, analytic workbench, SIEM, malware analysis tool, digital forensic analysis tool, etc.) are focused at doing different things with different information. The key is that they all deal with “cyber threat information” and effective cyber security involves use and integration/orchestration across them and their information. This is why it is important that STIX serve the purpose of an ontology/data-model across the domain serving both localized tactical use cases as well as bridging strategic ones.

And our efforts of making sure we can accommodate every possible use-case, means, that in practical terms no one can actually communicate unless they are using the same software package (which is not realistic).  

[sean]First, I would assert that we are certainly NOT "making sure we can accommodate every possible use-case”. Not even close. We are targeting the most common use cases for cyber threat information. That does not mean only the most common use cases from a particular individuals perspective or usage scenarios but across the cyber security landscape. The terms esoteric and niche are often thrown around (not in this message but in others with the same tone and intent) by some who wish to discount the validity or importance of use cases other then theirs. I would request that we avoid derogatory use of terms like these going forward and would further assert that none of the broad set of use cases currently listed on the STIX use-cases wiki are esoteric or niche. They are ALL common use cases occurring as we speak and every day across a broad set of users in the cyber security domain. Ironically, I would say that the use cases on that list that are least common today are ones that are more difficult without something like STIX (e.g. Indicator Sighting Reporting) and are often asserted as the most common ones we need to focus on at the expense of others discounted as esoteric or niche.
And again, the conclusionary statement here is fundamentally untrue. Addressing the set of relevant use cases does not require that everyone use the same product. They simply need to agree on elements of the profiles they will support (based on their use cases) and use products that support those profile elements. Assertions that flexibility is impossible and everyone would have to be using the same product are demonstrably untrue in current use.

Simplicity will gain us adoption, and from adoption we can iterate over time and add features. 

I am in strong favor of "one-way-of-doing-things".  I am also in strong favor of getting rid of and simplifying the extensibility so that we can guarantee interoperability.  

[sean]I would like to request that we stop using the buzzwords “simplicity” and “one-way-of-doing-things” in an ambiguous manner. They are at best distracting and disruptive if used without specifics of what particular issue is being discussed, what specific structure is being deemed too complex, what specific structure is being proposed as “simple” or the "one-way-of-doing-things” and details of how it supports the capabilities of the “complex” structure in a better way or explicitly argues that those capabilities are not relevant. Using them ambiguously is like a politician saying “its for the children”. Of course, we can all agree on the benefit of that, right? Well, unfortunately it typically means we are not all necessarily agreeing on the same thing. What I think is “simple” or the “one-way-of-doing things” is likely different from your thinking on the same terms. Specifics are absolutely necessary. I am very much interested in discussing such issues if we can do so in a manner that is specific.
It looks like it is being used here to imply that the “simplicity” of removing core capability like extensibility is an obviously good thing and gains us adoption. I would argue that this is a naïve presumption. May it gain us adoption for the absolute lowest common denominator? Perhaps. Would it kill adoption for a wide range of uses beyond the lowest common denominator and force those players to seek alternative (and likely competing) solutions? Very likely.
Simplifying and normalizing/standardizing are good things but only as they still fit within what is necessary to actually serve purpose.
Remember, Einstein’s quote is “Everything should be made as simple as possible, but not simpler”. The second half of the quote is absolutely crucial to the principle. Simple alone is not necessarily good but as simple as possible to still serve purpose is.
Where we can identify opportunities to simplify structure and still serve the purposes necessary I will be 100% supportive and always have been (remember, we have done this several times over the last few releases). Where arguments are made that “simplicity” should be pursued at the expense of serving the purposes necessary you will find me skeptical and requiring clear and unassailable justification. I view such defense of the community’s work to date as a key responsibility as an expert and as a co-chair.

To Jason's points, I would suggest we add an option for "other" and we also try to be more diligent about updating the controlled vocabulary.  Maybe go so far as to say that every January we will rev the controlled vocabularies.  

[sean]Looks like we have found common ground on a need to be more diligent about updating the default controlled vocabularies.



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 Oct 22, 2015, at 12:04, Aharon Chernin <[hidden email]> wrote:

In regards to forcing a controlled vocab in STIX 2, I am torn. A controlled vocab would make STIX easier for software developers, but more difficult for product owners who are trying to push the boundaries of STIX within their products. Just the other day I was working on a proposal that had us doing something different with STIX that required us to release a few custom vocab entries. However, I could argue against custom vocabs as I have seen implementations of STIX that do not understand the whole concept of including additional XSDs in the namespace/header portion of the XML document.



Aharon

From: <[hidden email]> on behalf of "Wunder, John A." <[hidden email]>
Date: Thursday, October 22, 2015 at 1:14 PM
To: Jason Keirstead <[hidden email]>, "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

It would be nice to understand what software is doing with the field. Does it show up in the UI as a sort/filter? Do you base processing on it?

I heard a recent proposal to remove it entirely. What would be the impact of that?

John

From: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 1:10 PM
To: "Palmer, Cliff A. (NE)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

I would agree, but the spec currently lets you put in any string.

I would propose that in STIX 2.0, if the consensus is that it should be a controlled vocabulary, that that be enforced in the spec, and that documents that don't follow the vocabulary are invalid.

I am not looking to do anything with the indicator at all on the recieving end - this is an indicator the software will produce as a result of an automated response. I find the current vocabulary to be very restrictive and full of obvious gaps. Even simple things like "Compromised Host" are absent. Also, all of the instances current vocabulary should be able to be prefixed with "Potential" in my opinion. ("Potential Malware Artifact")

-
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


<graycol.gif>"Palmer, Cliff A. (NE)" ---2015/10/22 12:55:52 PM---Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. Y

From: "Palmer, Cliff A. (NE)" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 12:55 PM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason, it seems to me that there is a value to having a controlled vocabulary for Indicator Type. You can probably enumerate the benefits in your circumstances better than anyone outside of your situation. The value of controlling the vocabulary should translate into a benefit to your users and provide an incentive for adoption.
Others will want to discuss adopting an ontology to control handling of indicators based on type. While my first thought is “There be dragons” (https://en.wikipedia.org/wiki/Here_be_dragons) it’s also true that an indicator type might not be as challenging as other ontologies. Are you able to describe how the indicator type affects the way you understand or treat the indicator?
I have built ontologies and found it interesting work, but it’s definitely non-trivial. I’d like to hear more about how you proceed.

Cliff Palmer

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Thursday, October 22, 2015 11:18 AM
To:
[hidden email]
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



<graycol.gif>
This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/

Reply | Threaded
Open this post in threaded view
|

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

Grobauer, Bernd
In reply to this post by Wunder, John A.
Hi,

> I heard a recent proposal to remove it entirely. What would be the
> impact of that?

I had made the suggestion to remove the IncidentType entirely in
my somewhat provocative mail a few weeks ago, in which I wanted
to explore how much potential for simplification in going towards
STIX 2.0 there might be.

Why had I suggested to remove it?

The main reason is that I do not find the values that are currently part of the
standard vocabulary particularly useful:

- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
  into the Indicator Type? I could understand "Watchlist", which tells you
  to watch for whatever Observable Patterns are indicated in the indicator.

- Another type is 'C2' -- at the same time I have the ability to reference
  in the indicator a kill chain phase ... and if the referenced kill chain
  is of any use, it will have something corresponding to 'C2'.

  Now I have (again) two ways of expressing the same thing ... we have
  just stumbled over this issue a few days ago in a sharing group we
  are part of: we use the reference to the killchain phase to indicate
  C2-activity, others use the indicator type.

  Similarly, "Exfiltration" -- should that not be described with a reference
  from the indicator to an TTP "Exfiltration"?

Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
seem like there would be no end to the list of allowed vocabulary (think
"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)

My suggestion to get rid of the indicator type was really a bit of a calculated
provocation -- I have no trouble with keeping it in STIX. But we should
ensure that the standard vocabulary is defined such that it really adds
value rather than adding confusion by allowing yet more ways to describe
the same thing in different ways.

Kind regards,

Bernd

----------------

Bernd Grobauer, Siemens CERT




Reply | Threaded
Open this post in threaded view
|

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

pmaroney
There is a common theme running in our important discourse.  It is important for Vendors and those focusing on narrow Use Cases to understand the complexity of APT Intrusions.  We understand and *completely* support many of the arguments made for simplicity and easily addressing narrowly focused use cases.  If I just need to send a list of IP Address, Domains, etc. to security appliance, then an efficient/consistent/simplified mechanism is absolutely a key CTI requirement.

Those of us who have been dealing with the full scope of APT Targeting, Compromise, Lateral Movement, Entrenchment, repeated Mapping/Exploitation of Victim Organizations and Infrastructure, etc. for many many years (pre Titan Rain) are also key stakeholders in "Our Thing".  

We are not pushing for "Complexity" just for complexities sake:  we are pushing these higher dimensional representation concepts because this complexity is part of the reality we operate in on a daily basis.  If we can't model all of the key elements of Adversary, TTP, and Target Domains, we can't change the Cyber Battle Space dynamics.  Doing so globally, across sectors, in real-time, is the "Holy Grail" we seek. No one said this would be easy, but it is a much much better use of our collective energies in comparison to another decade of playing APT Whack-A-Mole and counting Body Bags.

Hopefully I'm not triggering a new wave of "Less Filling" <==> " Tastes Great"  😁 

On to specifics (great discussion by the way)

(1) IncidentType is critical to some of the highest value CTI Use Cases, including mandatory Incident Reporting (in some cases, required under law in 72 hours after detection!).  Automating, standardizing/normalizing, and aligning Incident Reporting across Stakeholder 



(2) C2 is one of the highest value CTI Elements one can convey.

"One of the most common forms of indicator seen describes a pattern for TCP traffic beaconing to a specific command and control (C2, C&C) server. This idiom describes creating such an indicator in STIX."

The presence of attempted or active C2 is one of the strongest indicators of "Wildfire": Active compromise of an asset/network.  If you see it you are pwned, only question is the degree.

C2 can be a component of all Kill Chain Phases (Lockheed Martin™) , from "Recon" to "Actions on Intent".

We could consider the "one way to do things" principle, but given the importance of semantically and temporally characterizing C2 in the Operation Domain, we would need to ensure we can clearly convey in all required contexts.


(3) Similar comments to C2 on "Exfil".  Although we have a running joke in certain Domains ( "...but no evidence of Exfiltration"). "Exfil" is the "Game Over" state in CTI Operational Domains.

(4) "Malicious.CybOXObject"  

It would be great to start focusing on a number of long standing enumerated type issues in CTI.  In some cases they are non-sequitur with current realities, incomplete, bloated, etc.  We should also be mindful of related standards and use these and/or map to their taxonomies.  Some of the enumerations in other standards have similar issues with currency/relevance, but we should adopt these wherever possible and engage with those communities to fix them "in one place" (Jerome Athias has one of the best perspectives on these standards, where they intersect, conflict, etc.:  Jerome would be a great resource to lead this effort)


Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a dir="ltr" href="tel:(856)983-0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="4/1"> (856)983-0001
Cell: <a dir="ltr" href="tel:(609)841-5104" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="4/2"> (609)841-5104
Email: [hidden email]

_____________________________
From: Grobauer, Bernd <[hidden email]>
Sent: Friday, October 23, 2015 6:50 AM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
To: <[hidden email]>, <[hidden email]>, <[hidden email]>
Cc: <[hidden email]>


Hi,

> I heard a recent proposal to remove it entirely. What would be the
> impact of that?

I had made the suggestion to remove the IncidentType entirely in
my somewhat provocative mail a few weeks ago, in which I wanted
to explore how much potential for simplification in going towards
STIX 2.0 there might be.

Why had I suggested to remove it?

The main reason is that I do not find the values that are currently part of the
standard vocabulary particularly useful:

- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
into the Indicator Type? I could understand "Watchlist", which tells you
to watch for whatever Observable Patterns are indicated in the indicator.

- Another type is 'C2' -- at the same time I have the ability to reference
in the indicator a kill chain phase ... and if the referenced kill chain
is of any use, it will have something corresponding to 'C2'.

Now I have (again) two ways of expressing the same thing ... we have
just stumbled over this issue a few days ago in a sharing group we
are part of: we use the reference to the killchain phase to indicate
C2-activity, others use the indicator type.

Similarly, "Exfiltration" -- should that not be described with a reference
from the indicator to an TTP "Exfiltration"?

Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
seem like there would be no end to the list of allowed vocabulary (think
"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)

My suggestion to get rid of the indicator type was really a bit of a calculated
provocation -- I have no trouble with keeping it in STIX. But we should
ensure that the standard vocabulary is defined such that it really adds
value rather than adding confusion by allowing yet more ways to describe
the same thing in different ways.

Kind regards,

Bernd

----------------

Bernd Grobauer, Siemens CERT






Reply | Threaded
Open this post in threaded view
|

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

Paul Patrick
Patrick,

Great description of why are so critical to a number of us. I think you hit the nail o.n the head


Paul Patrick

Sent from my iPhone

On Oct 23, 2015, at 8:02 AM, Patrick Maroney <[hidden email]> wrote:

There is a common theme running in our important discourse.  It is important for Vendors and those focusing on narrow Use Cases to understand the complexity of APT Intrusions.  We understand and *completely* support many of the arguments made for simplicity and easily addressing narrowly focused use cases.  If I just need to send a list of IP Address, Domains, etc. to security appliance, then an efficient/consistent/simplified mechanism is absolutely a key CTI requirement.

Those of us who have been dealing with the full scope of APT Targeting, Compromise, Lateral Movement, Entrenchment, repeated Mapping/Exploitation of Victim Organizations and Infrastructure, etc. for many many years (pre Titan Rain) are also key stakeholders in "Our Thing".  

We are not pushing for "Complexity" just for complexities sake:  we are pushing these higher dimensional representation concepts because this complexity is part of the reality we operate in on a daily basis.  If we can't model all of the key elements of Adversary, TTP, and Target Domains, we can't change the Cyber Battle Space dynamics.  Doing so globally, across sectors, in real-time, is the "Holy Grail" we seek. No one said this would be easy, but it is a much much better use of our collective energies in comparison to another decade of playing APT Whack-A-Mole and counting Body Bags.

Hopefully I'm not triggering a new wave of "Less Filling" <==> " Tastes Great"  😁 

On to specifics (great discussion by the way)

(1) IncidentType is critical to some of the highest value CTI Use Cases, including mandatory Incident Reporting (in some cases, required under law in 72 hours after detection!).  Automating, standardizing/normalizing, and aligning Incident Reporting across Stakeholder 



(2) C2 is one of the highest value CTI Elements one can convey.

"One of the most common forms of indicator seen describes a pattern for TCP traffic beaconing to a specific command and control (C2, C&C) server. This idiom describes creating such an indicator in STIX."

The presence of attempted or active C2 is one of the strongest indicators of "Wildfire": Active compromise of an asset/network.  If you see it you are pwned, only question is the degree.

C2 can be a component of all Kill Chain Phases (Lockheed Martin™) , from "Recon" to "Actions on Intent".

We could consider the "one way to do things" principle, but given the importance of semantically and temporally characterizing C2 in the Operation Domain, we would need to ensure we can clearly convey in all required contexts.


(3) Similar comments to C2 on "Exfil".  Although we have a running joke in certain Domains ( "...but no evidence of Exfiltration"). "Exfil" is the "Game Over" state in CTI Operational Domains.

(4) "Malicious.CybOXObject"  

It would be great to start focusing on a number of long standing enumerated type issues in CTI.  In some cases they are non-sequitur with current realities, incomplete, bloated, etc.  We should also be mindful of related standards and use these and/or map to their taxonomies.  Some of the enumerations in other standards have similar issues with currency/relevance, but we should adopt these wherever possible and engage with those communities to fix them "in one place" (Jerome Athias has one of the best perspectives on these standards, where they intersect, conflict, etc.:  Jerome would be a great resource to lead this effort)


Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a dir="ltr" href="tel:(856)983-0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="4/1"> (856)983-0001
Cell: <a dir="ltr" href="tel:(609)841-5104" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="4/2"> (609)841-5104
Email: [hidden email]

_____________________________
From: Grobauer, Bernd <[hidden email]>
Sent: Friday, October 23, 2015 6:50 AM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
To: <[hidden email]>, <[hidden email]>, <[hidden email]>
Cc: <[hidden email]>


Hi,

> I heard a recent proposal to remove it entirely. What would be the
> impact of that?

I had made the suggestion to remove the IncidentType entirely in
my somewhat provocative mail a few weeks ago, in which I wanted
to explore how much potential for simplification in going towards
STIX 2.0 there might be.

Why had I suggested to remove it?

The main reason is that I do not find the values that are currently part of the
standard vocabulary particularly useful:

- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
into the Indicator Type? I could understand "Watchlist", which tells you
to watch for whatever Observable Patterns are indicated in the indicator.

- Another type is 'C2' -- at the same time I have the ability to reference
in the indicator a kill chain phase ... and if the referenced kill chain
is of any use, it will have something corresponding to 'C2'.

Now I have (again) two ways of expressing the same thing ... we have
just stumbled over this issue a few days ago in a sharing group we
are part of: we use the reference to the killchain phase to indicate
C2-activity, others use the indicator type.

Similarly, "Exfiltration" -- should that not be described with a reference
from the indicator to an TTP "Exfiltration"?

Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
seem like there would be no end to the list of allowed vocabulary (think
"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)

My suggestion to get rid of the indicator type was really a bit of a calculated
provocation -- I have no trouble with keeping it in STIX. But we should
ensure that the standard vocabulary is defined such that it really adds
value rather than adding confusion by allowing yet more ways to describe
the same thing in different ways.

Kind regards,

Bernd

----------------

Bernd Grobauer, Siemens CERT






Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by Barnum, Sean D.
Comments inline

From: Jason Keirstead <[hidden email]>
Date: Thursday, October 22, 2015 at 3:48 PM
To: "Barnum, Sean D." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

> 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 everyone is OK with using free-form string, then that is what I will use, and it makes things easier on my end for sure.

I just wanted to make sure there weren't known tools out there expecting this string to always be present in a vocabulary.

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

A user creates a rule in their SIEM, and wants to have anything that matches that rule, treated as threat intel, and pushed out to their STIX repository via TAXII. The logic behind that rule can be absolutely anything including deep analytics and behavioural analysis - so the "type" description you need for that indicator, can also be absolutely anything. The current default vocabulary is far to small to encompass all possible use cases for user-defined rules creating automated threat intel.


[sean]I would certainly agree that the current IndicatorType default vocab is far too small even for the most common cases. This is a known issue and we continue to encourage the community to offer their thoughts on how it should be expanded and/or refactored. You are even more correct in your statement that "The current default vocabulary is far to small to encompass all possible use cases for user-defined rules creating automated threat intel.” I think this will always be true given the potential diversity in such use cases. This is why the controlled vocabulary capability is structured how it is in STIX with the three levels: default vocab, explicit custom vocab, free-form string.
I am unsure of the deeper details of the ecosystem you describe of your interaction with users and their STIX CTI generated by SIEM alerts. It sounds like for each user the set of values may actually be fairly consistent (they know which types of deep analytics or behavioral analysis rules they would be writing). Given this do you have the freedom/influence to suggest that they each define the vocabulary they will use as a custom controlled vocabulary so that you can interact with their content in a constrained and validated way? If so, then custom vocabs defined by the users may be something to look into. If not, then free-form strings may be your best bet though I do agree with Jerome’s earlier statements about such unknown/unconstrained values leading to "bad statistics/metrics and automation…”. Sounds like you are limited by your users and their use cases.



-
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


Inactive hide details for "Barnum, Sean D." ---2015/10/22 03:53:15 PM---Jason, I am a little confused. Hopefully you can clarif"Barnum, Sean D." ---2015/10/22 03:53:15 PM---Jason, I am a little confused. Hopefully you can clarify for me.

From: "Barnum, Sean D." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>
Date: 2015/10/22 03:53 PM
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
Sent by: <[hidden email]>





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: <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Date:
Thursday, October 22, 2015 at 11:18 AM
To:
"[hidden email]" <[hidden email]>
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





This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
Reply | Threaded
Open this post in threaded view
|

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

Barnum, Sean D.
In reply to this post by Grobauer, Bernd
Bernd,

I definitely agree with you that the IndicatorType default vocab needs a lot of love and additional attention.
The current values came from the input of the community and what people wanted but everyone always knew it needed improving.

May I suggest that rather than talking about removing the property that we instead have a structured discussion around collaboratively improving the values and more directly characterizing how different players may wish to use that property and its values?

I think the first step would be to enter an issue in the tracker for this so that we can get it on the table. I also agree with an earlier statement that the issue of default vocab values has clear overlap with the interoperability SC so while we need to work internally within the STIX SC for ensuring our default vocabs have the appropriate values for STIX use cases it probably also makes sense to work at a higher level on the process by which we define and manage the various default controlled vocabs.

As an aside, it may be useful to know that one of the uses for the IndicatorType property that some community members expressed intent for in the past was for aiding in automated filtering and orchestration of Indicators upon ingest. For example, automated routing of 'IP Watchlist' or 'Domain Watchlist’ Indicators to network analysts or tools while routing 'File Hash Watchlist’ to host/endpoint analysts or tools or routing “Malware Artifacts” or “C2” to malware analysts for further investigation.
I don’t necessarily think that saying “C2” in IndicatorType and associating the Indicator with “Command and Control” as a Kill Chain phase are the same thing. They are both mentioning C2 but for different reasons and in different contexts.
Just thought I would point out how some have mentioned using the property.

sean




On 10/23/15, 6:49 AM, "[hidden email] on behalf of Grobauer, Bernd" <[hidden email] on behalf of [hidden email]> wrote:

>Hi,
>
>> I heard a recent proposal to remove it entirely. What would be the
>> impact of that?
>
>I had made the suggestion to remove the IncidentType entirely in
>my somewhat provocative mail a few weeks ago, in which I wanted
>to explore how much potential for simplification in going towards
>STIX 2.0 there might be.
>
>Why had I suggested to remove it?
>
>The main reason is that I do not find the values that are currently part of the
>standard vocabulary particularly useful:
>
>- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
>  into the Indicator Type? I could understand "Watchlist", which tells you
>  to watch for whatever Observable Patterns are indicated in the indicator.
>
>- Another type is 'C2' -- at the same time I have the ability to reference
>  in the indicator a kill chain phase ... and if the referenced kill chain
>  is of any use, it will have something corresponding to 'C2'.
>
>  Now I have (again) two ways of expressing the same thing ... we have
>  just stumbled over this issue a few days ago in a sharing group we
>  are part of: we use the reference to the killchain phase to indicate
>  C2-activity, others use the indicator type.
>
>  Similarly, "Exfiltration" -- should that not be described with a reference
>  from the indicator to an TTP "Exfiltration"?
>
>Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
>seem like there would be no end to the list of allowed vocabulary (think
>"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)
>
>My suggestion to get rid of the indicator type was really a bit of a calculated
>provocation -- I have no trouble with keeping it in STIX. But we should
>ensure that the standard vocabulary is defined such that it really adds
>value rather than adding confusion by allowing yet more ways to describe
>the same thing in different ways.
>
>Kind regards,
>
>Bernd
>
>----------------
>
>Bernd Grobauer, Siemens CERT
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Cory Casanave
In reply to this post by pmaroney

Patrick,

Great perspective – it is a common and difficult problem to balance scope, complexity, extensibility and simplicity. The inconvenient truth is that Cyber security is not simple, but we don’t want to introduce arbitrary complexity either.

 

Well, I’m probably putting a target on my back, but I’m going to suggest that some things that may seem simple do, in fact, introduce more complexity and restriction as reality sets in.  (remember when XML was the simple alternative, then we got XML Schema and 100 extensions – same for java).

 

I have noticed a set of recurring themes that if we could deal with in a consistent way, may help this difficult balance. So just consider these as some thoughts from the peanut gallery.

 

·         Big Vs. complicated.

A very small and simple instance document may be described by a large schema. A large schema in and of its self is not necessarily complex. What is complex is:

o   When you have to insert a lot of “stuff” the simple case doesn’t need. Some of this may be inevitable, but it can be mitigated by good design.

o   When there are many ways to say the same thing. This is unclear semantics and/or redundant elements.

o   When it is not clear how to do the simple thing. This can be mitigated with use case specific documentation (like the “idioms”)

o   When large schema/vocabularies/models are not modular so you can look at manageable “chunks”.

·         String encoding.

A very common “simplification” is to substitute a reference to a thing with a name or ID usually a string. E.g. victim: ”Joe Smith”. While this seems simple it causes multiple problems that result in downstream complexity. A reference to a thing should always be a type for that thing. E.g. victim: -> person: {name:”Joe Smith”}. Reasons for this are:

o   What is in the “string” is unclear and tends to be inconsistent, making interoperability difficult.

o   When other “facts” need be said about the thing, you have a place to put them and don’t try and encode it in complex strings.

o   If the string is an ID, there is no consistency for the basis for the identifier.

·         My hierarchy is not your hierarchy.

While it seems simple to put things in a hierarchy, hierarchies tend to be specific to a use case or perspective. Independent entities should be independent and referenced, not embedded as an attribute. The complexity introduced by some implementation frameworks for references can be a problem – but can be mitigated by a good framework/API. Problems with embedding include:

o   The same entity may show up in multiple places, resulting in confusing redundant data.

o   Embedded entities may lack identity, making analysis difficult.

o   It is hard to “say more about” such an embedded entity or to reference it later.

·         There is more to say

When you try and put everything someone may need to know in a single “data package”, the packages become large and very coupled to a single perspective of what must or can be communicated. Having an architecture that allows for accessing additional data – be it extended vocabularies or more information on Joe Smith allows the structures to be smaller, simpler and less coupled. Building the expectation of linking into the architecture allows for this simplicity, which also provides for extensibility. This can also be done in “secure” or partially connected communities by building linking into security and using intermediate data cashes.  

o   Note: My view is that this is solved: every reference should be a URI, how you “dereference” that URI is where your secure boundaries come in.

·         Realistic extension

Some of our technologies fight extensibility and ad-hoc mechanisms are to be built-in to support it, sometimes these mechanisms add complexity. On the other hand, assuming there will never be a need for extension is unrealistic in an open community. Sometimes it is better to:

o   Use a technology that allows for extension naturally

o   Be realistic about where extensibility is really needed. When it is – use the extensibility mechanisms for everything. E.g. all vocabularies are an “extension”, even if some are considered well known and curated.

·         It is obvious what it means

Much design and implementation experiences come from closed or smaller environments than CTI. If, for example, we are integrating 3 systems in company XYZ there is a shared understanding and culture of the team. What things mean, constraints and formats tend to be worked out dynamically – and this is practical in such an environment. In a large and dynamic community it is simply amazing how different people interpret the same things. In a community environment there is a need for clear and precise semantics and, wherever possible, automated validation. Loose specifications will never be interoperable. If not interoperable, what is the point?

·         This is the only technology we will need

Whatever it is, there is a favorite of the day and a desire to “just do that”. Well, not everyone will have the same favorites and the style of the day changes (sometimes it seems like we are the fashion industry). Over-committing to a single technology builds that technologies limitations into your solution – which may look really stupid in 5 years. Separation of concerns is vital.

·         Real complexity

As a final thought – recognize “real complexity” – if what you are trying to do and communicate is not simple, don’t expect a simple result. The challenge is recognizing and supporting the real complexity in as simple a way as possible. If complexity is being introduced for other than “real” reasons, what is introducing them?

 

This got longer than intended, sorry about that! If we can find our way to deal with these issues in a consistent way with good design and a supporting implementation framework that makes them easy to deal with we can have a usable balance between simplicity, scope and extensibility.

               

-Cory Casanave

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Patrick Maroney
Sent: Friday, October 23, 2015 9:03 AM
To: [hidden email]; Grobauer, Bernd; [hidden email]; [hidden email]
Cc: [hidden email]
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

 

There is a common theme running in our important discourse.  It is important for Vendors and those focusing on narrow Use Cases to understand the complexity of APT Intrusions.  We understand and *completely* support many of the arguments made for simplicity and easily addressing narrowly focused use cases.  If I just need to send a list of IP Address, Domains, etc. to security appliance, then an efficient/consistent/simplified mechanism is absolutely a key CTI requirement.

 

Those of us who have been dealing with the full scope of APT Targeting, Compromise, Lateral Movement, Entrenchment, repeated Mapping/Exploitation of Victim Organizations and Infrastructure, etc. for many many years (pre Titan Rain) are also key stakeholders in "Our Thing".  

 

We are not pushing for "Complexity" just for complexities sake:  we are pushing these higher dimensional representation concepts because this complexity is part of the reality we operate in on a daily basis.  If we can't model all of the key elements of Adversary, TTP, and Target Domains, we can't change the Cyber Battle Space dynamics.  Doing so globally, across sectors, in real-time, is the "Holy Grail" we seek. No one said this would be easy, but it is a much much better use of our collective energies in comparison to another decade of playing APT Whack-A-Mole and counting Body Bags.

 

Hopefully I'm not triggering a new wave of "Less Filling" <==> " Tastes Great"  😁 

 

On to specifics (great discussion by the way)

 

(1) IncidentType is critical to some of the highest value CTI Use Cases, including mandatory Incident Reporting (in some cases, required under law in 72 hours after detection!).  Automating, standardizing/normalizing, and aligning Incident Reporting across Stakeholder 

 

 

 

(2) C2 is one of the highest value CTI Elements one can convey.

 

"One of the most common forms of indicator seen describes a pattern for TCP traffic beaconing to a specific command and control (C2, C&C) server. This idiom describes creating such an indicator in STIX."

 

The presence of attempted or active C2 is one of the strongest indicators of "Wildfire": Active compromise of an asset/network.  If you see it you are pwned, only question is the degree.

 

C2 can be a component of all Kill Chain Phases (Lockheed Martin™) , from "Recon" to "Actions on Intent".

 

We could consider the "one way to do things" principle, but given the importance of semantically and temporally characterizing C2 in the Operation Domain, we would need to ensure we can clearly convey in all required contexts.

 

 

(3) Similar comments to C2 on "Exfil".  Although we have a running joke in certain Domains ( "...but no evidence of Exfiltration"). "Exfil" is the "Game Over" state in CTI Operational Domains.

 

(4) "Malicious.CybOXObject"  

 

It would be great to start focusing on a number of long standing enumerated type issues in CTI.  In some cases they are non-sequitur with current realities, incomplete, bloated, etc.  We should also be mindful of related standards and use these and/or map to their taxonomies.  Some of the enumerations in other standards have similar issues with currency/relevance, but we should adopt these wherever possible and engage with those communities to fix them "in one place" (Jerome Athias has one of the best perspectives on these standards, where they intersect, conflict, etc.:  Jerome would be a great resource to lead this effort)

 

 

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a href="tel:(856)983-0001">(856)983-0001
Cell: <a href="tel:(609)841-5104">(609)841-5104
Email: [hidden email]

 

_____________________________
From: Grobauer, Bernd <[hidden email]>
Sent: Friday, October 23, 2015 6:50 AM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
To: <[hidden email]>, <[hidden email]>, <[hidden email]>
Cc: <[hidden email]>


Hi,

> I heard a recent proposal to remove it entirely. What would be the
> impact of that?

I had made the suggestion to remove the IncidentType entirely in
my somewhat provocative mail a few weeks ago, in which I wanted
to explore how much potential for simplification in going towards
STIX 2.0 there might be.

Why had I suggested to remove it?

The main reason is that I do not find the values that are currently part of the
standard vocabulary particularly useful:

- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
into the Indicator Type? I could understand "Watchlist", which tells you
to watch for whatever Observable Patterns are indicated in the indicator.

- Another type is 'C2' -- at the same time I have the ability to reference
in the indicator a kill chain phase ... and if the referenced kill chain
is of any use, it will have something corresponding to 'C2'.

Now I have (again) two ways of expressing the same thing ... we have
just stumbled over this issue a few days ago in a sharing group we
are part of: we use the reference to the killchain phase to indicate
C2-activity, others use the indicator type.

Similarly, "Exfiltration" -- should that not be described with a reference
from the indicator to an TTP "Exfiltration"?

Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
seem like there would be no end to the list of allowed vocabulary (think
"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)

My suggestion to get rid of the indicator type was really a bit of a calculated
provocation -- I have no trouble with keeping it in STIX. But we should
ensure that the standard vocabulary is defined such that it really adds
value rather than adding confusion by allowing yet more ways to describe
the same thing in different ways.

Kind regards,

Bernd

----------------

Bernd Grobauer, Siemens CERT





12