OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] Finalizing the indicator labels vocab


We’ve had a bunch of back and forth on this, I’d like to propose that we move forward with the minimal list (including anonymization, but not VERIS) and evaluate adding items from VERIS during the 2.1 release. I’m worried that by adding a bunch of items now we’ll just spark more discussion and be unable to finalize this prior to July. Once we have more time after the 2.0 release though we can spend a lot more time thinking it through.

 

It would give us the following list:

 

anomalous-activity, anonymization, benign, compromised, malicious-activity, attribution

 

That’s a pretty solid core of well-understood values that we can build off of.

 

Any objections to this approach?

 

John

 

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 2, 2016 at 7:37 PM
To: Terry MacDonald <terry.macdonald@cosive.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Finalizing the indicator labels vocab

 

Indicator Label is the old Indicator Type form STIX 1.2.  We have just standardized on the "label" name for the property.  And there are a lot of people that use that field for processing of indicators.  So we have learned from the community that we can not drop it.  Even if it shares some commonality with attack pattern or other things.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jun 1, 2016, at 02:54, Terry MacDonald <terry.macdonald@cosive.com> wrote:

 

My Thoughts:

 

1. I quite like adding the VERIS enumerations. They have experience of classifying data over the last 6 years or so, and their list has been proven to cover the majority of actions. I see the list as far longer, as the actions are divided into 7 sections - Malware, Hacking, Social Engineering, Misuse, Error, Environmental, Physical - each with its own list of actions. While not all sections would be useful (i.e. physical and environmental), the rest could well be. Some I could envisage 'Social Engineering - Spam' being useful, as is 'Hacking - DoS', and 'Malware - Ransomware'. 

 

2. Not sure about this. Need more info really.

 

3. I'm not sure about 'attribution'. in fact Indicator Labels themselves seem a bit odd. The label field is effectively a small cut down, embedded version of an Attack Pattern object. I would rather see the Indicator Label removed, and instead people use the Attack Pattern object to describe what action (Attack Pattern) the Indicator is describing.


Cheers

 

Terry MacDonald | Chief Product Officer

 

<cosive_mail_signature.png>

 

 

 

 

 

On Wed, Jun 1, 2016 at 2:46 AM, Wunder, John A. <jwunder@mitre.org> wrote:

All,

 

We’ve had the indicator labels vocab topic open for awhile now, I think it’s time to solidify on a list for 2.0 MVP. That means answering the following questions:

 

1.       Kyle Maxwell suggested adding the VERIS “action enumerations” to the list, from here: http://veriscommunity.net/enums.html#section-actions. Should we do that? It’s about 25 new items.

2.       Kyle also suggested adding detail to “anonymization” to capture the suspected anonymization technique (proxy, TOR, etc.). Should we do that?

3.       Gary suggested adding attribution to the list to capture information that might not itself be directly suspicious or might be too noisy to block, but is useful for attribution. Should we add that?

 

My thoughts are:

 

1, 2: it’s tempting, but at this point I think we should stay very minimalistic with the suggest vocab and add to it over time. Thus, no, I don’t think we should add these…since it’s an open vocab people are free to expand the list to use these and other more specific ones. As we get to 2.1 and after that we’ll hopefully start to notice on a common set of things we should add, and we can go from there.

3: This seems useful to me, is just one additional value, and is differentiated enough from the others to make it clear when it should be used. So, I think we should add it.

 

What do you all think? Let’s try to get comments early this week and finish up this topic for Friday. I’m happy to talk on Slack about it as well.

 

John

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]