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

From
Barnum, Sean D. <>
Date
2015-10-23T14:25:17+00:00
ID
Thread
Re: [cti-stix] RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
>If desired - I would volunteer to take the initial stab at extending the vocabulary.

Yes, please. :-)

I would suggest a first step of making sure their is an issue for this in the tracker.

Thank you Jason.

sean

From: "" <> on behalf of Jason Keirstead <>

Date: Friday, October 23, 2015 at 9:38 AM

To: Bernd Grobauer <>

Cc: John Wunder <>, "" <>, ""
 <>

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

Note, I have made this reply to CTI-STIX from CTI-Users

I agree pretty much 100% with what you say Bernd. I see there is a bit of a conflict here

- There is obviously a need to have a controlled vocabulary, so that tools and researchers can share categorized intelligence efficiently; however...

- The current vocabulary list is seemingly arbitrary - and has many gaps, and also redundancies, as you mentioned. Off the top of my head it should have 2x - 3x as many options, and like you mention, some are redundant. I totally agree that it makes no sense
 to have different Watchlist types when that can be inferred easily from the data.

Due to how STIX 1.X is constructed, we can easily revision this vocabulary as a non-breaking change. I would propose that the STIX TC undertake a work product to revision this vocabulary. This is a "quick win" that the TC can provide.

If desired - I would volunteer to take the initial stab at extending the vocabulary.

-

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 

"Grobauer,
 Bernd" ---2015/10/23 07:50:32 AM---Hi, > I heard a recent proposal to remove it entirely. What would be the

From: "Grobauer, Bernd" <>

To: "" <>, Jason Keirstead/CanEast/IBM@IBMCA, ""
 <>

Cc: "" <>

Date: 2015/10/23 07:50 AM

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

Sent by: <>

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