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

["Grobauer, Bernd" <Bernd.Grobauer@siemens.com>]

Hi Sean,

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

Like I wrote in my previous email: my call for getting rid of
the IndicatorType element several weeks ago had been part
of a calculated provocation to gauge the scope there might be
for simplifying the standard. I don't use such
provocations lightly, but at the time I felt it important
to get some clarification on where we stand regarding changes
towards STIX 2.0 and CybOX 3.0. And I think the discussion that
ensued was helpful...

So let me state now in all clarity: I am not calling for
the removal of IndicatorType and I am all in favor for improving the
values and understanding how it is used and should be used.


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

John-Mark Gurney has done so (thanks!):

https://github.com/STIXProject/specifications/issues/35

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

Thanks, that has given me a better picture of why the vocabulary
looks the way it does!

Kind regards,

Bernd




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