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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Should name be required


I generally agree with Terry’s assessment of where required vs optional should be defined, with one exception.

 

Indicator requires the pattern attribute and therefore requiring a name in addition to the pattern is painful in cases where a machine may create the indicator and not a human.

 

If the name attribute becomes required in this case then I could see an easy way to create a name attribute based on the pattern (i.e. a copy of it) but that’s not ideal because then that might introduce confusion to whether the name is really the primary field to convey the pattern to match on or the name is.

 

allan

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Sunday, August 7, 2016 at 1:26 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Should name be required

 

Hi Bret,

The way I think of it is that anything that is likely to be referred to by humans in an implementation's user interface should have a name property that would enable the implementation to show it to the human.

The relationship needs a name to show the type of relationship it is to show the user (I would prefer for it to be called relationship name vs relationship label to show that relationships are different from SDOs).

The objects listed in the required section on Brett's email also need a name to differentiate them quickly within the user interface (I'm thinking about a graph model display).

The infrastructure object i think does need a required name, because as a user I would like to know at a glance what infrastructure object i am looking at in a graph model.

The indicator is a tricky one. I am probably leaning towards making it required, as a name is often useful e.g. 'heart bleed large packet detection'.

The observed data I am happy for it to remain without a name. The reason for this is that a name would just repeat the data that's already within the object. I.e. an observable data object with an IP of 1.2.3.4 would likely have a name of 'IP 1.2.3.4', which is something that an implementation can easily generate automatically.

Similarly I'm happy for the sighting relationship to not have a name property as we know that a sighting is specifically a 'sighting' relationship, so a name provides no other help in this case.

Cheers
Terry MacDonald
Cosive

 

On 7/08/2016 5:27 PM, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

The following objects have the name property as required:

Attack Pattern

Campaign

Course of Action

Incident

Intrusion Set

Malware

Relationship (see previous email)

Report

Source

Threat Actor

Tool

Victim Target

Vulnerability

 

 

The following objects have the name property as optional:

Indicator

Infrastructure

 

 

The following objects do NOT have a name property

Observed Data

Sighting

 

So my question is, do we have the required vs optional state set correctly for all of these objects?  Specifically as it pertains to the "name" property. 

 

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

 



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