OASIS Cyber Threat Intelligence (CTI) TC

All, In STIX 2.0 we are using the labels property of the object to capture the object type data. For example, in STIX 1.x we had indicator type , in STIX 2.0 we are putting that same data in the labels field on the Indicator object instead of having a property called indicator_type .  We can not use type as it is already being used in the model. So the following objects all have these vocabularies that represent the type of object it is: Threat Actor Type == Threat Actor Label Vocab == Threat Actor Object -> labels property Malware Type      == Malware Labels Vocab     == Malware Object      -> labels property Tool Type         == Tool Labels Vocab        == Tool Object         -> labels property COA Type          ... Incident Type     ... Report Type       ... Indicator Type    ... So in all of these cases we are using this pattern of putting the object type in the labels fields.  There is one exception to this rule though... For the Relationship Object we are putting the relationship type (or the relationship verb) in the name property.  I just wanted to shed some light on this and see what the community thinks of this. 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.   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

We should be consistent across all TLOs.  Relationships are a "special" TLO class (the "Edges" of the "Vertices") so there may be a basis for a different data model.  However, can't readily think of one and barring suggestion of same, would argue for consistency. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Sun, Aug 7, 2016 at 1:21 AM -0400, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote: All, In STIX 2.0 we are using the labels property of the object to capture the "object type" data. For example, in STIX 1.x we had "indicator type", in STIX 2.0 we are putting that same data in the "labels" field on the Indicator object instead of having a property called "indicator_type".  We can not use "type" as it is already being used in the model. So the following objects all have these vocabularies that represent the type of object it is: Threat Actor Type == Threat Actor Label Vocab == Threat Actor Object -> labels property Malware Type      == Malware Labels Vocab     == Malware Object      -> labels property Tool Type         == Tool Labels Vocab        == Tool Object         -> labels property COA Type          ... Incident Type     ... Report Type       ... Indicator Type    ... So in all of these cases we are using this pattern of putting the "object type" in the labels fields.  There is one exception to this rule though... For the Relationship Object we are putting the "relationship type" (or the relationship verb) in the "name" property.  I just wanted to shed some light on this and see what the community thinks of this. 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." 

An important consideration here is that the current field, “name”, has only one value. “labels”, on the other hand, supports multiple values. Should relationships be allowed to have more
than one label (e.g.,  Threat Actor A is [“related-to”, “member-of”] Threat Actor B) or just a single label/name?
 
I can see it working both ways, just wanted to point out that this is about more than just name vs. label.
 
John
 

From:
<cti@lists.oasis-open.org> on behalf of Patrick Maroney <Pmaroney@Specere.org>
Date: Sunday, August 7, 2016 at 5:38 PM
To: Bret Jordan <bret.jordan@bluecoat.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Relationship object - name property


 




We should be consistent across all TLOs.  Relationships are a "special" TLO class (the "Edges" of the "Vertices") so there may be a basis for a different data model.  However, can't readily think of one and
barring suggestion of same, would argue for consistency.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

 





On Sun, Aug 7, 2016 at 1:21 AM -0400, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote:


All,

 


In STIX 2.0 we are using the labels property of the object to capture the "object type" data. For example, in STIX 1.x we had "indicator type", in STIX 2.0 we are putting that same data in the "labels" field on the Indicator object instead
of having a property called "indicator_type".  We can not use "type" as it is already being used in the model.


 


So the following objects all have these vocabularies that represent the type of object it is:


Threat Actor Type == Threat Actor Label Vocab == Threat Actor Object -> labels property


Malware Type      == Malware Labels Vocab     == Malware Object      -> labels property


Tool Type         == Tool Labels Vocab        == Tool Object         -> labels property


COA Type          ...


Incident Type     ...


Report Type       ...


Indicator Type    ...


 


 


 


So in all of these cases we are using this pattern of putting the "object type" in the labels fields.  There is one exception to this rule though... For the Relationship Object we are putting the "relationship type" (or the relationship
verb) in the "name" property.  I just wanted to shed some light on this and see what the community thinks of this.


 









 


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









 

I think more than one name is a bad idea, especially because we will be adding a confidence property in the future.
 


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Monday, August 08, 2016 8:50 AM
To: Patrick Maroney <Pmaroney@Specere.org>; Jordan, Bret <bret.jordan@bluecoat.com>; cti@lists.oasis-open.org
Subject: Re: [cti] Relationship object - name property


 
An important consideration here is that the current field, “name”, has only one value. “labels”, on the other hand, supports multiple values. Should
relationships be allowed to have more than one label (e.g.,  Threat Actor A is [“related-to”, “member-of”] Threat Actor B) or just a single label/name?
 
I can see it working both ways, just wanted to point out that this is about more than just name vs. label.
 
John
 

From:
< cti@lists.oasis-open.org > on behalf of Patrick Maroney < Pmaroney@Specere.org >
Date: Sunday, August 7, 2016 at 5:38 PM
To: Bret Jordan < bret.jordan@bluecoat.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Relationship object - name property


 





We should be consistent across all TLOs.  Relationships are a "special" TLO class (the "Edges" of the "Vertices") so there may be a basis for a different data model.  However, can't readily think of one and barring suggestion of same, would argue for consistency.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

 


 


On Sun, Aug 7, 2016 at 1:21 AM -0400, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote:


All,

 


In STIX 2.0 we are using the labels property of the object to capture the "object type" data. For example, in STIX 1.x we had "indicator type", in STIX 2.0 we are putting that same data in the "labels" field on
the Indicator object instead of having a property called "indicator_type".  We can not use "type" as it is already being used in the model.


 


So the following objects all have these vocabularies that represent the type of object it is:


Threat Actor Type == Threat Actor Label Vocab == Threat Actor Object -> labels property


Malware Type      == Malware Labels Vocab     == Malware Object      -> labels property


Tool Type         == Tool Labels Vocab        == Tool Object         -> labels property


COA Type          ...


Incident Type     ...


Report Type       ...


Indicator Type    ...


 


 


 


So in all of these cases we are using this pattern of putting the "object type" in the labels fields.  There is one exception to this rule though... For the Relationship Object we are putting the "relationship type"
(or the relationship verb) in the "name" property.  I just wanted to shed some light on this and see what the community thinks of this.


 










 


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









 

That is a good point.  These should probably just have a single value.  Bret  Sent from my Commodore 64 On Aug 8, 2016, at 6:50 AM, Wunder, John A. < jwunder@mitre.org > wrote: An important consideration here is that the current field, “name”, has only one value. “labels”, on the other hand, supports multiple values. Should relationships be allowed to have more than one label (e.g.,  Threat Actor A is [“related-to”, “member-of”] Threat Actor B) or just a single label/name?   I can see it working both ways, just wanted to point out that this is about more than just name vs. label.   John   From: < cti@lists.oasis-open.org > on behalf of Patrick Maroney < Pmaroney@Specere.org > Date: Sunday, August 7, 2016 at 5:38 PM To: Bret Jordan < bret.jordan@bluecoat.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Relationship object - name property   We should be consistent across all TLOs.  Relationships are a "special" TLO class (the "Edges" of the "Vertices") so there may be a basis for a different data model.  However, can't readily think of one and barring suggestion of same, would argue for consistency. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org   On Sun, Aug 7, 2016 at 1:21 AM -0400, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote: All,   In STIX 2.0 we are using the labels property of the object to capture the "object type" data. For example, in STIX 1.x we had "indicator type", in STIX 2.0 we are putting that same data in the "labels" field on the Indicator object instead of having a property called "indicator_type".  We can not use "type" as it is already being used in the model.   So the following objects all have these vocabularies that represent the type of object it is: Threat Actor Type == Threat Actor Label Vocab == Threat Actor Object -> labels property Malware Type      == Malware Labels Vocab     == Malware Object      -> labels property Tool Type         == Tool Labels Vocab        == Tool Object         -> labels property COA Type          ... Incident Type     ... Report Type       ... Indicator Type    ...       So in all of these cases we are using this pattern of putting the "object type" in the labels fields.  There is one exception to this rule though... For the Relationship Object we are putting the "relationship type" (or the relationship verb) in the "name" property.  I just wanted to shed some light on this and see what the community thinks of this.     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."   

"Threat Actor A" and "Threat Actor B" are vertex unique identifiers which (I assume) would be carried in the name field of those vertices. "related-to" is a class of edge but does not identify a specific edge, so I'd think that "label" or "relationship-type" is more appropriate than "name". Is an edge uniquely identified by anything other than two vertex IDs? If not, edges would not have names. Dave
Original Message----- From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Wunder, John A. Sent: Monday, August 08, 2016 8:50 AM To: Patrick Maroney; Jordan, Bret; cti@lists.oasis-open.org Subject: Re: [cti] Relationship object - name property An important consideration here is that the current field, “name”, has only one value. “labels”, on the other hand, supports multiple values. Should relationships be allowed to have more than one label (e.g., Threat Actor A is [“related-to”, “member-of”] Threat Actor B) or just a single label/name? I can see it working both ways, just wanted to point out that this is about more than just name vs. label. John From: <cti@lists.oasis-open.org> on behalf of Patrick Maroney <Pmaroney@Specere.org> Date: Sunday, August 7, 2016 at 5:38 PM To: Bret Jordan <bret.jordan@bluecoat.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Relationship object - name property We should be consistent across all TLOs. Relationships are a "special" TLO class (the "Edges" of the "Vertices") so there may be a basis for a different data model. However, can't readily think of one and barring suggestion of same, would argue for consistency. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Sun, Aug 7, 2016 at 1:21 AM -0400, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote: All, In STIX 2.0 we are using the labels property of the object to capture the "object type" data. For example, in STIX 1.x we had "indicator type", in STIX 2.0 we are putting that same data in the "labels" field on the Indicator object instead of having a property called "indicator_type". We can not use "type" as it is already being used in the model. So the following objects all have these vocabularies that represent the type of object it is: Threat Actor Type == Threat Actor Label Vocab == Threat Actor Object -> labels property Malware Type == Malware Labels Vocab == Malware Object -> labels property Tool Type == Tool Labels Vocab == Tool Object -> labels property COA Type ... Incident Type ... Report Type ... Indicator Type ... So in all of these cases we are using this pattern of putting the "object type" in the labels fields. There is one exception to this rule though... For the Relationship Object we are putting the "relationship type" (or the relationship verb) in the "name" property. I just wanted to shed some light on this and see what the community thinks of this. 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."

For a relationship, I agree with David that ‘relationship-type’ would be better than name Paul Patrick On 8/8/16, 11:17 AM, "cti@lists.oasis-open.org on behalf of Kemp, David P" <cti@lists.oasis-open.org on behalf of dpkemp@nsa.gov> wrote: "Threat Actor A" and "Threat Actor B" are vertex unique identifiers which (I assume) would be carried in the name field of those vertices. "related-to" is a class of edge but does not identify a specific edge, so I'd think that "label" or "relationship-type" is more appropriate than "name". Is an edge uniquely identified by anything other than two vertex IDs? If not, edges would not have names. Dave This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

That makes sense to me to change the field from name to relationship-type, and would potentially help differentiate the SROs from the SDOs. Cheers Terry MacDonald Cosive On 9/08/2016 3:30 AM, "Paul Patrick" < Paul.Patrick@fireeye.com > wrote: For a relationship, I agree with David that ‘relationship-type’ would be better than name Paul Patrick On 8/8/16, 11:17 AM, " cti@lists.oasis-open.org on behalf of Kemp, David P" < cti@lists.oasis-open.org on behalf of dpkemp@nsa.gov > wrote:     "Threat Actor A" and "Threat Actor B" are vertex unique identifiers which (I assume) would be carried in the name field of those vertices.   "related-to" is a class of edge but does not identify a specific edge, so I'd think that "label" or "relationship-type" is more appropriate than "name".      Is an edge uniquely identified by anything other than two vertex IDs?   If not, edges would not have names.     Dave This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Agreed. I think our reservations about having both “type” and “relationship_type” are probably very minor compared to the extra clarity this would bring.
 

From:
<cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, August 10, 2016 at 4:19 PM
To: Paul Patrick <Paul.Patrick@fireeye.com>
Cc: "Kemp, David P" <dpkemp@nsa.gov>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Relationship object - name property


 



That makes sense to me to change the field from name to relationship-type, and would potentially help differentiate the SROs from the SDOs.
Cheers
Terry MacDonald
Cosive

 

On 9/08/2016 3:30 AM, "Paul Patrick" < Paul.Patrick@fireeye.com > wrote:

For a relationship, I agree with David that ‘relationship-type’ would be better than name


Paul Patrick


On 8/8/16, 11:17 AM, " cti@lists.oasis-open.org on behalf of Kemp, David P" < cti@lists.oasis-open.org on behalf of
dpkemp@nsa.gov > wrote:


    "Threat Actor A" and "Threat Actor B" are vertex unique identifiers which (I assume) would be carried in the name field of those vertices.   "related-to" is a class of edge but does not identify a specific edge, so I'd think that "label" or "relationship-type"
is more appropriate than "name".

     Is an edge uniquely identified by anything other than two vertex IDs?   If not, edges would not have names.

    Dave




This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Agreed. There's also type, definition_type, and definition properties on marking-definition objects, so it's not unprecedented (and actually rather consistent). Greg >
Original Message----- > From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of > Wunder, John A. > Sent: Wednesday, August 10, 2016 3:25 PM > To: Terry MacDonald <terry.macdonald@cosive.com>; Paul Patrick > <Paul.Patrick@fireeye.com> > Cc: Kemp, David P <dpkemp@nsa.gov>; cti@lists.oasis-open.org > Subject: Re: [cti] Relationship object - name property > > Agreed. I think our reservations about having both “type” and > “relationship_type” are probably very minor compared to the extra clarity > this would bring. > > > > From: <cti@lists.oasis-open.org> on behalf of Terry MacDonald > <terry.macdonald@cosive.com> > Date: Wednesday, August 10, 2016 at 4:19 PM > To: Paul Patrick <Paul.Patrick@fireeye.com> > Cc: "Kemp, David P" <dpkemp@nsa.gov>, "cti@lists.oasis-open.org" > <cti@lists.oasis-open.org> > Subject: Re: [cti] Relationship object - name property > > > > That makes sense to me to change the field from name to relationship-type, > and would potentially help differentiate the SROs from the SDOs. > > Cheers > Terry MacDonald > Cosive > > > > On 9/08/2016 3:30 AM, "Paul Patrick" <Paul.Patrick@fireeye.com > < mailto:Paul.Patrick@fireeye.com > > wrote: > > For a relationship, I agree with David that ‘relationship-type’ would > be better than name > > > Paul Patrick > > > On 8/8/16, 11:17 AM, "cti@lists.oasis-open.org > < mailto:cti@lists.oasis-open.org > on behalf of Kemp, David P" > <cti@lists.oasis-open.org < mailto:cti@lists.oasis-open.org > on behalf of > dpkemp@nsa.gov < mailto:dpkemp@nsa.gov > > wrote: > > > "Threat Actor A" and "Threat Actor B" are vertex unique identifiers > which (I assume) would be carried in the name field of those vertices. > "related-to" is a class of edge but does not identify a specific edge, so I'd > think that "label" or "relationship-type" is more appropriate than "name". > > Is an edge uniquely identified by anything other than two vertex > IDs? If not, edges would not have names. > > Dave > > > > > This email and any attachments thereto may contain private, > confidential, and/or privileged material for the sole use of the intended > recipient. Any review, copying, or distribution of this email (or any > attachments thereto) by others is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.

Unless anyone has any objections I’ll go through the documents tomorrow and make this update. On 8/10/16, 5:14 PM, "Back, Greg" <gback@mitre.org> wrote: Agreed. There's also type, definition_type, and definition properties on marking-definition objects, so it's not unprecedented (and actually rather consistent). Greg >
Original Message----- > From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of > Wunder, John A. > Sent: Wednesday, August 10, 2016 3:25 PM > To: Terry MacDonald <terry.macdonald@cosive.com>; Paul Patrick > <Paul.Patrick@fireeye.com> > Cc: Kemp, David P <dpkemp@nsa.gov>; cti@lists.oasis-open.org > Subject: Re: [cti] Relationship object - name property > > Agreed. I think our reservations about having both “type” and > “relationship_type” are probably very minor compared to the extra clarity > this would bring. > > > > From: <cti@lists.oasis-open.org> on behalf of Terry MacDonald > <terry.macdonald@cosive.com> > Date: Wednesday, August 10, 2016 at 4:19 PM > To: Paul Patrick <Paul.Patrick@fireeye.com> > Cc: "Kemp, David P" <dpkemp@nsa.gov>, "cti@lists.oasis-open.org" > <cti@lists.oasis-open.org> > Subject: Re: [cti] Relationship object - name property > > > > That makes sense to me to change the field from name to relationship-type, > and would potentially help differentiate the SROs from the SDOs. > > Cheers > Terry MacDonald > Cosive > > > > On 9/08/2016 3:30 AM, "Paul Patrick" <Paul.Patrick@fireeye.com > < mailto:Paul.Patrick@fireeye.com > > wrote: > > For a relationship, I agree with David that ‘relationship-type’ would > be better than name > > > Paul Patrick > > > On 8/8/16, 11:17 AM, "cti@lists.oasis-open.org > < mailto:cti@lists.oasis-open.org > on behalf of Kemp, David P" > <cti@lists.oasis-open.org < mailto:cti@lists.oasis-open.org > on behalf of > dpkemp@nsa.gov < mailto:dpkemp@nsa.gov > > wrote: > > > "Threat Actor A" and "Threat Actor B" are vertex unique identifiers > which (I assume) would be carried in the name field of those vertices. > "related-to" is a class of edge but does not identify a specific edge, so I'd > think that "label" or "relationship-type" is more appropriate than "name". > > Is an edge uniquely identified by anything other than two vertex > IDs? If not, edges would not have names. > > Dave > > > > > This email and any attachments thereto may contain private, > confidential, and/or privileged material for the sole use of the intended > recipient. Any review, copying, or distribution of this email (or any > attachments thereto) by others is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.

If we go back to using relationship_type , do we still need name and description ? 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 Aug 10, 2016, at 15:15, Wunder, John A. < jwunder@mitre.org > wrote: Unless anyone has any objections I’ll go through the documents tomorrow and make this update. On 8/10/16, 5:14 PM, Back, Greg < gback@mitre.org > wrote:    Agreed. There's also type, definition_type, and definition properties on marking-definition objects, so it's not unprecedented (and actually rather consistent).    Greg
Original Message----- From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Wunder, John A. Sent: Wednesday, August 10, 2016 3:25 PM To: Terry MacDonald < terry.macdonald@cosive.com >; Paul Patrick < Paul.Patrick@fireeye.com > Cc: Kemp, David P < dpkemp@nsa.gov >; cti@lists.oasis-open.org Subject: Re: [cti] Relationship object - name property Agreed. I think our reservations about having both “type” and “relationship_type” are probably very minor compared to the extra clarity this would bring. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Wednesday, August 10, 2016 at 4:19 PM To: Paul Patrick < Paul.Patrick@fireeye.com > Cc: Kemp, David P < dpkemp@nsa.gov >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] Relationship object - name property That makes sense to me to change the field from name to relationship-type, and would potentially help differentiate the SROs from the SDOs. Cheers Terry MacDonald Cosive On 9/08/2016 3:30 AM, Paul Patrick < Paul.Patrick@fireeye.com < mailto:Paul.Patrick@fireeye.com > > wrote: For a relationship, I agree with David that ‘relationship-type’ would be better than name Paul Patrick On 8/8/16, 11:17 AM, cti@lists.oasis-open.org < mailto:cti@lists.oasis-open.org >  on behalf of Kemp, David P < cti@lists.oasis-open.org < mailto:cti@lists.oasis-open.org >  on behalf of dpkemp@nsa.gov < mailto:dpkemp@nsa.gov > > wrote:     Threat Actor A and Threat Actor B are vertex unique identifiers which (I assume) would be carried in the name field of those vertices. related-to is a class of edge but does not identify a specific edge, so I'd think that label or relationship-type is more appropriate than name .     Is an edge uniquely identified by anything other than two vertex IDs?   If not, edges would not have names.    Dave This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I feel like we can get rid of name, since relationship_type will cover that.
 
I would prefer to keep “description”. A lot of relationships will be analyst-generated and it would be nice to be able to have some narrative text further explaining them. As an example,
if a threat-actor is related to another threat-actor you could explain how they’re related and provide some background beyond just saying they’re related (which is not super useful on its own).
 
John
 

From:
Bret Jordan <bret.jordan@bluecoat.com>
Date: Wednesday, August 10, 2016 at 5:19 PM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: Greg Back <gback@mitre.org>, Terry MacDonald <terry.macdonald@cosive.com>, Paul Patrick <Paul.Patrick@fireeye.com>, "Kemp, David P" <dpkemp@nsa.gov>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Relationship object - name property


 



If we go back to using "relationship_type", do we still need "name" and "description" ?








 


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 Aug 10, 2016, at 15:15, Wunder, John A. < jwunder@mitre.org > wrote:

 


Unless anyone has any objections I’ll go through the documents tomorrow and make this update.

On 8/10/16, 5:14 PM, "Back, Greg" < gback@mitre.org > wrote:

   Agreed. There's also type, definition_type, and definition properties on marking-definition objects, so it's not unprecedented (and actually rather consistent).


   Greg





Original Message-----
From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of
Wunder, John A.
Sent: Wednesday, August 10, 2016 3:25 PM
To: Terry MacDonald < terry.macdonald@cosive.com >; Paul Patrick
< Paul.Patrick@fireeye.com >
Cc: Kemp, David P < dpkemp@nsa.gov >;
cti@lists.oasis-open.org
Subject: Re: [cti] Relationship object - name property

Agreed. I think our reservations about having both “type” and
“relationship_type” are probably very minor compared to the extra clarity
this would bring.



From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald
< terry.macdonald@cosive.com >
Date: Wednesday, August 10, 2016 at 4:19 PM
To: Paul Patrick < Paul.Patrick@fireeye.com >
Cc: "Kemp, David P" < dpkemp@nsa.gov >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject: Re: [cti] Relationship object - name property



That makes sense to me to change the field from name to relationship-type,
and would potentially help differentiate the SROs from the SDOs.

Cheers
Terry MacDonald
Cosive



On 9/08/2016 3:30 AM, "Paul Patrick" < Paul.Patrick@fireeye.com
< mailto:Paul.Patrick@fireeye.com > > wrote:

            For a relationship, I agree with David that ‘relationship-type’ would
be better than name


            Paul Patrick


            On 8/8/16, 11:17 AM, " cti@lists.oasis-open.org
< mailto:cti@lists.oasis-open.org >  on behalf of Kemp, David P"
< cti@lists.oasis-open.org < mailto:cti@lists.oasis-open.org >  on behalf of
dpkemp@nsa.gov < mailto:dpkemp@nsa.gov > > wrote:


               "Threat Actor A" and "Threat Actor B" are vertex unique identifiers
which (I assume) would be carried in the name field of those vertices.
"related-to" is a class of edge but does not identify a specific edge, so I'd
think that "label" or "relationship-type" is more appropriate than "name".

                Is an edge uniquely identified by anything other than two vertex
IDs?   If not, edges would not have names.

               Dave




            This email and any attachments thereto may contain private,
confidential, and/or privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any
attachments thereto) by others is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and permanently
delete the original and any copies of this email and any attachments thereto.








 

I agree we should get rid of the name field. I prefer that distinction between SROs and SDOs. Cheers Terry MacDonald Cosive On 11/08/2016 9:21 AM, "Wunder, John A." < jwunder@mitre.org > wrote: I feel like we can get rid of name, since relationship_type will cover that.   I would prefer to keep “description”. A lot of relationships will be analyst-generated and it would be nice to be able to have some narrative text further explaining them. As an example, if a threat-actor is related to another threat-actor you could explain how they’re related and provide some background beyond just saying they’re related (which is not super useful on its own).   John   From: Bret Jordan < bret.jordan@bluecoat.com > Date: Wednesday, August 10, 2016 at 5:19 PM To: "Wunder, John A." < jwunder@mitre.org > Cc: Greg Back < gback@mitre.org >, Terry MacDonald < terry.macdonald@cosive.com >, Paul Patrick < Paul.Patrick@fireeye.com >, "Kemp, David P" < dpkemp@nsa.gov >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Relationship object - name property   If we go back to using "relationship_type", do we still need "name" and "description" ?   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 Aug 10, 2016, at 15:15, Wunder, John A. < jwunder@mitre.org > wrote:   Unless anyone has any objections I’ll go through the documents tomorrow and make this update. On 8/10/16, 5:14 PM, "Back, Greg" < gback@mitre.org > wrote:    Agreed. There's also type, definition_type, and definition properties on marking-definition objects, so it's not unprecedented (and actually rather consistent).    Greg
Original Message----- From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open. org ] On Behalf Of Wunder, John A. Sent: Wednesday, August 10, 2016 3:25 PM To: Terry MacDonald < terry.macdonald@cosive.com >; Paul Patrick < Paul.Patrick@fireeye.com > Cc: Kemp, David P < dpkemp@nsa.gov >; cti@lists.oasis-open.org Subject: Re: [cti] Relationship object - name property Agreed. I think our reservations about having both “type” and “relationship_type” are probably very minor compared to the extra clarity this would bring. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Wednesday, August 10, 2016 at 4:19 PM To: Paul Patrick < Paul.Patrick@fireeye.com > Cc: "Kemp, David P" < dpkemp@nsa.gov >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Relationship object - name property That makes sense to me to change the field from name to relationship-type, and would potentially help differentiate the SROs from the SDOs. Cheers Terry MacDonald Cosive On 9/08/2016 3:30 AM, "Paul Patrick" < Paul.Patrick@fireeye.com < mailto:Paul.Patrick@fireeye. com > > wrote:             For a relationship, I agree with David that ‘relationship-type’ would be better than name             Paul Patrick             On 8/8/16, 11:17 AM, " cti@lists.oasis-open.org < mailto:cti@lists.oasis-open. org >  on behalf of Kemp, David P" < cti@lists.oasis-open.org < mailto:cti@lists.oasis-open. org >  on behalf of dpkemp@nsa.gov < mailto:dpkemp@nsa.gov > > wrote:                "Threat Actor A" and "Threat Actor B" are vertex unique identifiers which (I assume) would be carried in the name field of those vertices. "related-to" is a class of edge but does not identify a specific edge, so I'd think that "label" or "relationship-type" is more appropriate than "name".                 Is an edge uniquely identified by anything other than two vertex IDs?   If not, edges would not have names.                Dave             This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.