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