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

["Barnum, Sean D." <sbarnum@mitre.org>]

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, "cti-users@lists.oasis-open.org on behalf of Grobauer, Bernd" <cti-users@lists.oasis-open.org on behalf of Bernd.Grobauer@siemens.com> 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
>
>
>
>