OASIS Cyber Threat Intelligence (CTI) TC

There are many different concepts of “sources” that we seem to be talking about:   ·          The creator of the STIX/CybOX object o    An individual/organization  (created manually via something like Soltra Edge), probably represented by an Identity object o    Software, that creates STIX/CybOX objects automatically – no manual input ·          A similar object from outside the STIX model  (used to be external_ID in STIX 1.2) – NOT a CTI ID ·          A reference, like in a bibliography, which might be accessible via a URL – NOT a CTI object ·          An association to another type of STIX object – like CVE (assuming we represent Vulnerability as a STIX TLO)   Did I miss anything?   The original object could be the source of a translated object, but that seem better handled separately (as discussed in the recent I18N email threat).        

Would the delivery service, portal, or broker be in that list? 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 Feb 4, 2016, at 10:45, Piazza, Rich < rpiazza@mitre.org > wrote: There are many different concepts of “sources” that we seem to be talking about:   ·            The creator of the STIX/CybOX object   o      An individual/organization  (created manually via something like Soltra Edge), probably represented by an Identity object o      Software, that creates STIX/CybOX objects automatically – no manual input ·            A   similar   object from outside the STIX model  (used to be   external_ID   in STIX 1.2) – NOT a CTI ID ·            A reference, like in a bibliography, which might be accessible via a URL – NOT a CTI object ·            An association to another type of STIX object – like CVE (assuming we represent Vulnerability as a STIX TLO)   Did I miss anything?   The original object could be the source of a translated object, but that seem better handled separately (as discussed in the recent I18N email threat). Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Do you mean – how did I get this STIX thingee – via email, TAXII, UPS?
 
No, I’m not talking about that kind of source – I don’t know if that information is or should be captured.
 
No – the source of the information in the STIX thingee….
 


From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]

Sent: Thursday, February 04, 2016 1:33 PM
To: Piazza, Rich <rpiazza@mitre.org>
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 
Would the delivery service, portal, or broker be in that list?








 


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 Feb 4, 2016, at 10:45, Piazza, Rich < rpiazza@mitre.org > wrote:

 


There are many different concepts of “sources” that we seem to be talking about:


 


·            The
creator of the STIX/CybOX object  


o      An
individual/organization  (created manually via something like Soltra Edge), probably represented by an Identity object


o      Software,
that creates STIX/CybOX objects automatically – no manual input


·            A   similar   object
from outside the STIX model  (used to be   external_ID   in
STIX 1.2) – NOT a CTI ID


·            A
reference, like in a bibliography, which might be accessible via a URL – NOT a CTI object


·            An
association to another type of STIX object – like CVE (assuming we represent Vulnerability as a STIX TLO)


 


Did I miss anything?


 


The original object could be the source of a translated object, but that seem better handled separately (as discussed in the recent I18N email threat).




 

No, I was referring to a clearing house TAXII server, like an ISAC or ISAO.  Say BankA produces the Indicator and ships it to FS-ISAC.  Would we need or want any type of chain.  If not, then that is okay.  I just wanted to ask. 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 Feb 4, 2016, at 11:37, Piazza, Rich < rpiazza@MITRE.ORG > wrote: Do you mean – how did I get this STIX thingee – via email, TAXII, UPS?   No, I’m not talking about that kind of source – I don’t know if that information is or should be captured.   No – the source of the information in the STIX thingee….   From:   Jordan, Bret [ mailto:bret.jordan@bluecoat.com ]   Sent:   Thursday, February 04, 2016 1:33 PM To:   Piazza, Rich < rpiazza@mitre.org > Cc:   cti@lists.oasis-open.org Subject:   Re: [cti] Kinds of Sources   Would the delivery service, portal, or broker be in that list?   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 Feb 4, 2016, at 10:45, Piazza, Rich < rpiazza@mitre.org > wrote:   There are many different concepts of “sources” that we seem to be talking about:   ·            The creator of the STIX/CybOX object   o      An individual/organization  (created manually via something like Soltra Edge), probably represented by an Identity object o      Software, that creates STIX/CybOX objects automatically – no manual input ·            A   similar   object from outside the STIX model  (used to be   external_ID   in STIX 1.2) – NOT a CTI ID ·            A reference, like in a bibliography, which might be accessible via a URL – NOT a CTI object ·            An association to another type of STIX object – like CVE (assuming we represent Vulnerability as a STIX TLO)   Did I miss anything?   The original object could be the source of a translated object, but that seem better handled separately (as discussed in the recent I18N email threat). Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I didn’t want to bring that up – since from both proposals I got the impression we removed that use case from Information Source in order to simplify. 

 
Here’s the UML in 1.2 that supports that (I think!):
 

Where role property could be from then InformationSourceRole controlled vocab, which in 1.2 has:  aggregator, content enhancer/refiner, initial author and transformer/translator
 


From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]

Sent: Thursday, February 04, 2016 1:53 PM
To: Piazza, Rich <rpiazza@mitre.org>
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 
No, I was referring to a clearing house TAXII server, like an ISAC or ISAO.  Say BankA produces the Indicator and ships it to FS-ISAC.  Would we need or want any type of chain.  If not, then that is okay.  I just
wanted to ask.








 


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 Feb 4, 2016, at 11:37, Piazza, Rich < rpiazza@MITRE.ORG > wrote:

 


Do you mean – how did I get this STIX thingee – via email, TAXII, UPS?


 


No, I’m not talking about that kind of source – I don’t know if that information is or should be captured.


 


No – the source of the information in the STIX thingee….


 




From:   Jordan,
Bret [ mailto:bret.jordan@bluecoat.com ]  
Sent:   Thursday, February 04, 2016 1:33 PM
To:   Piazza, Rich < rpiazza@mitre.org >
Cc:   cti@lists.oasis-open.org
Subject:   Re: [cti] Kinds of Sources




 


Would the delivery service, portal, or broker be in that list?









 



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 Feb 4, 2016, at 10:45, Piazza, Rich < rpiazza@mitre.org > wrote:



 




There are many different concepts of “sources” that we seem to be talking about:




 




·            The
creator of the STIX/CybOX object  




o      An
individual/organization  (created manually via something like Soltra Edge), probably represented by an Identity object




o      Software,
that creates STIX/CybOX objects automatically – no manual input




·            A   similar   object
from outside the STIX model  (used to be   external_ID   in
STIX 1.2) – NOT a CTI ID




·            A
reference, like in a bibliography, which might be accessible via a URL – NOT a CTI object




·            An
association to another type of STIX object – like CVE (assuming we represent Vulnerability as a STIX TLO)




 




Did I miss anything?




 




The original object could be the source of a translated object, but that seem better handled separately (as discussed in the recent I18N email threat).








 

Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more of this opinion/assertion object?


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than just an identity.


John








From: < cti@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Thursday, February 4, 2016 at 1:52 PM
To: Rich Piazza < rpiazza@MITRE.ORG >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources





No, I was referring to a clearing house TAXII server, like an ISAC or ISAO.  Say BankA produces the Indicator and ships it to FS-ISAC.  Would we need or want any type of chain.  If not, then that is okay.  I just wanted to ask.











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 Feb 4, 2016, at 11:37, Piazza, Rich < rpiazza@MITRE.ORG > wrote:




Do you mean – how did I get this STIX thingee – via email, TAXII, UPS?

 

No, I’m not talking about that kind of source – I don’t know if that information is or should be captured.

 

No – the source of the information in the STIX thingee….

 



From:   Jordan, Bret [ mailto:bret.jordan@bluecoat.com ]  
Sent:   Thursday, February 04, 2016 1:33 PM
To:   Piazza, Rich < rpiazza@mitre.org >
Cc:   cti@lists.oasis-open.org
Subject:   Re: [cti] Kinds of Sources



 

Would the delivery service, portal, or broker be in that list?








 



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 Feb 4, 2016, at 10:45, Piazza, Rich < rpiazza@mitre.org > wrote:


 



There are many different concepts of “sources” that we seem to be talking about:



 



·            The creator of the STIX/CybOX object  



o      An individual/organization 
(created manually via something like Soltra Edge), probably represented by an Identity object



o      Software, that
creates STIX/CybOX objects automatically – no manual input



·            A   similar   object
from outside the STIX model  (used to be   external_ID   in
STIX 1.2) – NOT a CTI ID



·            A reference, like in a bibliography,
which might be accessible via a URL – NOT a CTI object



·            An association to another type of STIX
object – like CVE (assuming we represent Vulnerability as a STIX TLO)



 



Did I miss anything?



 



The original object could be the source of a translated object, but that seem better handled separately (as discussed in the recent I18N email threat).

Comments below:
 


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.


 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.



 

Hm I think see, yeah.


I’d just reword that last one to make it clear that you’re talking about a source association, not just any relationship between STIX objects. I seems to me like an incident pointing to a CVE isn’t really a source relationship….it’d be more like one report
to another report (or one indicator to another indicator, or an indicator to a report, etc).









From: Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 4, 2016 at 2:26 PM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources








Comments below:
 


From:
cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.


 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.



 

I’m trying to understand the “source” use cases first – independent of how to represent them.  So here is my improved list (avoiding using the loaded terms: relationship
and reference):
 
·         
  The creator of the STIX/CybOX object


o   
An individual/organization  (created manually via something like Soltra Edge)

o   
Software, that creates STIX/CybOX objects automatically – no manual input
·         
A similar object from outside the STIX model  (used to be
external_ID in STIX 1.2) – NOT a CTI ID
·         
A citation, like in a bibliography, which might be accessible via a URL – NOT a CTI object
·         
An association to another STIX object as the source of information – the “chain” use case.
 
I dropped the CVE case, as per John’s suggestion, especially because there seems to be some movement away from representing such things in TLOs – from Sean’s
earlier email:
 
I believe this presumption of applicability across other STIX objects was confirmed during recent discussions on the Exploit_Target refactoring where it was suggested that the CVE_ID, OSVDB_ID, CWE_ID and similarly
CAPEC_ID on TTP should likely just 
be implemented using the external_ids structure rather than separate purpose built fields.
 
Getting back to the proposed Relationship object…
 
A “source” relationship between two reports, I think is the use case Sarah was referring to, which is a sub use case of the chain use case Bret mentioned.  A
“source” relationship means referring to another STIX object as the source of (some of) the information included in the current STIX object.  This would be something like:
 
{
      "type": "relationship",
      "id": "relationship--1",
      "source_ref": "report--1",
      "target_ref": "report--2",
      "confidence": "high",
      "value": "information-source",    -- or whatever
      "created_by_ref": "identity--1"
}
 
The question is – how different is that from the some of the other relationships we know and love, but may not fit into one of the four “source” use cases above.
John mentioned wanting a source relationship from “an indicator to a report”.  In his recent JSON examples he expressed this in a relationship object  whose “value”
property was “in-report”. 
Is “in-report” a kind of “source” relationship?  I think that is a stretch. 

 
I think we need to understand when we want two STIX objects to be in a “source” relationship.
 
                Rich
 
 


From: Wunder, John A.

Sent: Thursday, February 04, 2016 2:32 PM
To: Piazza, Rich <rpiazza@mitre.org>; cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



Hm I think see, yeah.


 


I’d just reword that last one to make it clear that you’re talking about a source association, not just any relationship between STIX objects.
I seems to me like an incident pointing to a CVE isn’t really a source relationship….it’d be more like one report to another report (or one indicator to another indicator, or an indicator to a report, etc).




 


From:
Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 4, 2016 at 2:26 PM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources


 



Comments below:
 


From:
cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.


 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

Quick clarification:


---------

John mentioned wanting a source relationship from “an indicator to a report”.  In his recent JSON examples he expressed this in a relationship object
 whose “value” property was “in-report”.  
Is “in-report” a kind of “source” relationship?  I think that is a stretch. 
--------








I actually meant those as two distinct things. The first (indicator was created based on information in 1+ "reports") would probably use a value of “derived-from” or whatever we use. The second (this report contains this indicator) would use some other
relationship (whether “in-report”, or the reverse, “contains”). But those are distinct statements.


John




From: Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 4, 2016 at 3:50 PM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources








I’m trying to understand the “source” use cases first – independent of how to represent them.  So here is my improved list (avoiding using the loaded terms: relationship
and reference):
 
·         
  The creator of the STIX/CybOX object


o   
An individual/organization  (created manually via something like Soltra Edge)

o   
Software, that creates STIX/CybOX objects automatically – no manual input
·         
A similar object from outside the STIX model  (used to be
external_ID in STIX 1.2) – NOT a CTI ID
·         
A citation, like in a bibliography, which might be accessible via a URL – NOT a CTI object
·         
An association to another STIX object as the source of information – the “chain” use case.
 
I dropped the CVE case, as per John’s suggestion, especially because there seems to be some movement away from representing such things in TLOs – from Sean’s
earlier email:
 
I believe this presumption of applicability across other STIX objects was confirmed during recent discussions on the Exploit_Target refactoring where it was suggested that the CVE_ID, OSVDB_ID, CWE_ID and similarly
CAPEC_ID on TTP should likely just 
be implemented using the external_ids structure rather than separate purpose built fields.
 
Getting back to the proposed Relationship object…
 
A “source” relationship between two reports, I think is the use case Sarah was referring to, which is a sub use case of the chain use case Bret mentioned.  A
“source” relationship means referring to another STIX object as the source of (some of) the information included in the current STIX object.  This would be something like:
 
{
      "type": "relationship",
      "id": "relationship--1",
      "source_ref": "report--1",
      "target_ref": "report--2",
      "confidence": "high",
      "value": "information-source",    -- or whatever
      "created_by_ref": "identity--1"
}
 
The question is – how different is that from the some of the other relationships we know and love, but may not fit into one of the four “source” use cases above.
John mentioned wanting a source relationship from “an indicator to a report”.  In his recent JSON examples he expressed this in a relationship object  whose “value”
property was “in-report”. 
Is “in-report” a kind of “source” relationship?  I think that is a stretch. 

 
I think we need to understand when we want two STIX objects to be in a “source” relationship.
 
                Rich
 
 


From: Wunder, John A.

Sent: Thursday, February 04, 2016 2:32 PM
To: Piazza, Rich < rpiazza@mitre.org >;
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



Hm I think see, yeah.


 


I’d just reword that last one to make it clear that you’re talking about a source association, not just any relationship between STIX objects.
I seems to me like an incident pointing to a CVE isn’t really a source relationship….it’d be more like one report to another report (or one indicator to another indicator, or an indicator to a report, etc).




 


From:
Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 4, 2016 at 2:26 PM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources


 



Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.


 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

Thanks John…
 
You kind of made my point better than I did.  In STIX 1.2 we had VERY fixed relationships, now we are opening it up (how much is still an open issue
J ). 

 
Where do “source” use cases fit in?
 


From: Wunder, John A.

Sent: Thursday, February 04, 2016 4:07 PM
To: Piazza, Rich <rpiazza@mitre.org>; cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



Quick clarification:


 


---------



John mentioned wanting a source relationship from “an indicator to a report”.  In his recent JSON examples he expressed this in a relationship object  whose “value” property was “in-report”.  

Is “in-report” a kind of “source” relationship?  I think that is a stretch. 

--------




 


I actually meant those as two distinct things. The first (indicator was created based on information in 1+ "reports") would probably use
a value of “derived-from” or whatever we use. The second (this report contains this indicator) would use some other relationship (whether “in-report”, or the reverse, “contains”). But those are distinct statements.


 


John


 


From:
Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 4, 2016 at 3:50 PM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources


 



I’m trying to understand the “source” use cases first – independent of how to represent them.  So here is my improved list (avoiding
using the loaded terms: relationship and reference):
 

·         
  The creator of the STIX/CybOX object


o   
An individual/organization  (created manually via something like Soltra Edge)

o   
Software, that creates STIX/CybOX objects automatically – no manual input

·         
A similar object from outside the STIX model  (used to be
external_ID in STIX 1.2) – NOT a CTI ID

·         
A citation, like in a bibliography, which might be accessible via a URL – NOT a CTI object

·         
An association to another STIX object as the source of information – the “chain” use case.
 
I dropped the CVE case, as per John’s suggestion, especially because there seems to be some movement away from representing such things
in TLOs – from Sean’s earlier email:
 
I believe this presumption of applicability across other STIX objects was confirmed during recent discussions on the Exploit_Target refactoring where it was suggested that the CVE_ID,
OSVDB_ID, CWE_ID and similarly CAPEC_ID on TTP should likely just 
be implemented using the external_ids structure rather than separate purpose built fields.
 
Getting back to the proposed Relationship object…
 
A “source” relationship between two reports, I think is the use case Sarah was referring to, which is a sub use case of the chain use
case Bret mentioned.  A “source” relationship means referring to another STIX object as the source of (some of) the information included in the current STIX object.  This would be something like:
 
{
      "type": "relationship",
      "id": "relationship--1",
      "source_ref": "report--1",
      "target_ref": "report--2",
      "confidence": "high",
      "value": "information-source",    -- or whatever
      "created_by_ref": "identity--1"
}
 
The question is – how different is that from the some of the other relationships we know and love, but may not fit into one of the four
“source” use cases above.
John mentioned wanting a source relationship from “an indicator to a report”.  In his recent JSON examples he expressed this in a relationship
object  whose “value” property was “in-report”. 
Is “in-report” a kind of “source” relationship?  I think that is a stretch. 

 
I think we need to understand when we want two STIX objects to be in a “source” relationship.
 
                Rich
 
 


From: Wunder, John A.

Sent: Thursday, February 04, 2016 2:32 PM
To: Piazza, Rich < rpiazza@mitre.org >;
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



Hm I think see, yeah.


 


I’d just reword that last one to make it clear that you’re talking about a source association, not just any relationship between STIX
objects. I seems to me like an incident pointing to a CVE isn’t really a source relationship….it’d be more like one report to another report (or one indicator to another indicator, or an indicator to a report, etc).




 


From:
Rich Piazza < rpiazza@mitre.org >
Date: Thursday, February 4, 2016 at 2:26 PM
To: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources


 



Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.


 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

Comments inline Sent from my iPhone On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote: Comments below:   From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Wunder, John A. Sent: Thursday, February 04, 2016 2:18 PM To: cti@lists.oasis-open.org Subject: Re: [cti] Kinds of Sources   Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more of this opinion/assertion object?   This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships. Paul> I would agree that this would be in a chain   For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than just an identity.   I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking would be handled by relationships.  

Great conversation everyone.


Just wanted to let you know that this is not stagnating.
I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can.


I am doing a lot of thinking and talking with some folks on this issue in particular.
It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way
to solve all of them coherently.
I should have some thoughts out soon on this that I hope might move us forward.


sean









From: < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources





Comments inline

Sent from my iPhone

On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:







Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.







Paul> I would agree that this would be in a chain








 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.



 

So, after thinking on this and talking through it with a couple of people here is where I have landed.


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for.
I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.
What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:

sources external to STIX  sources internal to STIX





The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content
contained within a Package but many others are also likely.
The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of
similar information external to STIX (references).
So at this point:


sources external to STIX 

Person, organization or system Representation of similar information external to STIX
sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible


External sources of person, organization or system then broke down into various roles these sorts of sources play including:



producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)

Similarly, the external representations of similar information external to STIX broke down into

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)
So at this point:


sources external to STIX 

Person, organization or system

producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)
Representation of similar information external to STIX

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible





I think this gives a pretty good overview of the types of sources we should support.
I then took a look across this thinking about the most appropriate way to represent these.
InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated.
The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question.
The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


Here is what I propose:

Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next week (identity-based objects
like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:

“reference_URL” (optional) - specifies a URL to the external reference
“external_identifier” (optional) - specifies an identifier for the external reference content
“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)

Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


Producer
Analysis Originator
Codification Originator
Translator
Transformer
Anonymizer
Reviewer
Transmitter
Derivation Resource

Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)
For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by the embedded
ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency in relationships
may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove one option.




John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.




I have attached a simple diagram showing a few various example use cases and how this approach would support them.




Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details
first.




Please let us know what you think.




Sean





From: "Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources







Great conversation everyone.


Just wanted to let you know that this is not stagnating.
I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can.


I am doing a lot of thinking and talking with some folks on this issue in particular.
It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way
to solve all of them coherently.
I should have some thoughts out soon on this that I hope might move us forward.


sean









From: < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources





Comments inline

Sent from my iPhone

On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:







Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.







Paul> I would agree that this would be in a chain








 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.



 












Attachment: Source examples.png Description: Source examples.png

I like the idea of running with both a relationship and created_by_ref for the time being so we can evaluate how they work. It’s a complicated topic and we’re still early in the process. As we develop the specs and put together more examples (I'd encourage
people to develop examples using both approaches) it may become clear which is better.


I also really like the breakdown of Identity, Tool, and Reference as types of sources. This is something that Terry wanted to propose initially but I (stupidly) talked him out of because I thought it would overcomplicate the decision (I wanted to focus
on one thing at a time).


I think it might be helpful to clarify two additional points with the relationship approach:

By default, the “source” of a “has-source” relationship is in fact the source that’s being pointed to. This prevents the “turtles all the way down” problem of sourcing the source relationship. (source source source). If you add a “has-source” relationship
to that relationship, though, you can override that default.

Example:

John publishes an indicator. He creates a relationship FROM the indicator TO John with a value of “has-source”. That means that John is saying that John created the indicator John publishes an indicator but doesn’t add a source. Later on, Sean realizes it was me and wants to indicate that. He creates a relationship FROM the indicator TO John with a value of “has-source”. He also creates a relationship FROM the first has-source
relationship TO Sean with a value of “has-source”. That means that Sean is saying that John created the indicator.

Those of you favoring the source relationship approach should decide whether it’d be better to:

just accept the content size challenges of individual relationships have all relationships allow multiple “from”/“to" have just source relationships to have multiple “from"





Sean should be able to explain these topics more. Just wanted to clarify them before moving forward.


John




From: Sean Barnum < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 3:33 PM
To: Paul Patrick < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources








So, after thinking on this and talking through it with a couple of people here is where I have landed.


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for.
I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.
What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:

sources external to STIX  sources internal to STIX





The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content
contained within a Package but many others are also likely.
The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of
similar information external to STIX (references).
So at this point:


sources external to STIX 

Person, organization or system Representation of similar information external to STIX
sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible


External sources of person, organization or system then broke down into various roles these sorts of sources play including:



producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)

Similarly, the external representations of similar information external to STIX broke down into

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)
So at this point:


sources external to STIX 

Person, organization or system

producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)
Representation of similar information external to STIX

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible





I think this gives a pretty good overview of the types of sources we should support.
I then took a look across this thinking about the most appropriate way to represent these.
InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated.
The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question.
The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


Here is what I propose:

Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next week (identity-based objects
like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:

“reference_URL” (optional) - specifies a URL to the external reference
“external_identifier” (optional) - specifies an identifier for the external reference content
“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)

Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


Producer
Analysis Originator
Codification Originator
Translator
Transformer
Anonymizer
Reviewer
Transmitter
Derivation Resource

Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)
For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by the embedded
ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency in relationships
may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove one option.




John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.




I have attached a simple diagram showing a few various example use cases and how this approach would support them.




Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details
first.




Please let us know what you think.




Sean





From: "Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources







Great conversation everyone.


Just wanted to let you know that this is not stagnating.
I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can.


I am doing a lot of thinking and talking with some folks on this issue in particular.
It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way
to solve all of them coherently.
I should have some thoughts out soon on this that I hope might move us forward.


sean









From: < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources





Comments inline

Sent from my iPhone

On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:







Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.







Paul> I would agree that this would be in a chain








 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.



 

Looks good.  Minor comment below:
 


From: Barnum, Sean D.

Sent: Friday, February 05, 2016 3:34 PM
To: Paul Patrick <ppatrick@isightpartners.com>; Piazza, Rich <rpiazza@mitre.org>
Cc: Wunder, John A. <jwunder@mitre.org>; cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



So, after thinking on this and talking through it with a couple of people here is where I have landed.


 


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate
them to content that they are the source for.


I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.


What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:


·         
sources external to STIX 

·         
sources internal to STIX



The sources internal to STIX are really  STIX objects from which another STIX object
was abstracted or generated. An obvious example would be content contained within a Package but many others are also likely.
 
I’m confused by this – I thought a package contained EMBEDDED STIX objects.  Maybe that is why you say it is “obvious”?  Maybe you were thinking Report?
 


The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar
information external to STIX (references).


So at this point:



·         
sources external to STIX 

o    
Person, organization or system

o    
Representation of similar information external to STIX

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible

External sources of person, organization or system then broke down into various roles these sorts of sources play including:




·         
producer (who created the actual STIX content)

·         
original source of the thinking

·         
original source of the content (structured or unstructured capture)

·         
any translation/transformation steps along the way

·         
anonymizer

·         
reviewer

·         
transmitter (who was the STIX content received from)


Similarly, the external representations of similar information external to STIX broke down into


·         
general references - simple URLs to documents, blog posts, web pages, etc.

·         
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

So at this point:



·         
sources external to STIX 

o    
Person, organization or system

§  
producer (who created the actual STIX content)

§  
original source of the thinking

§  
original source of the content (structured or unstructured capture)

§  
any translation/transformation steps along the way

§  
anonymizer

§  
reviewer

§  
transmitter (who was the STIX content received from)

o    
Representation of similar information external to STIX

§  
general references - simple URLs to documents, blog posts, web pages, etc.

§  
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible


 


I think this gives a pretty good overview of the types of sources we should support.


I then took a look across this thinking about the most appropriate way to represent these.


InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it
was generated.


The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference)
dimensions was a remaining open question.


The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


 


Here is what I propose:


·         
Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next
week (identity-based objects like Source, Victim, Actor, etc.)

·         
Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and
potentially for use with COA.

·         
Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:



·         
“reference_URL” (optional) - specifies a URL to the external reference



“external_identifier” (optional) - specifies an identifier for the external reference content



“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)



·         
Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


o    
Producer



Analysis Originator



Codification Originator



Translator



Transformer



Anonymizer



Reviewer



Transmitter



Derivation Resource


·         
Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship.

·         
Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)

For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially
be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those
wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable
and potentially remove one option.


 


John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.


 


I have attached a simple diagram showing a few various example use cases and how this approach would support them.


 


Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had
been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first.


 


Please let us know what you think.


 


Sean


 


From:
"Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 






Great conversation everyone.


 


Just wanted to let you know that this is not stagnating.


I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together
normative text where we can.


 


I am doing a lot of thinking and talking with some folks on this issue in particular.


It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning
to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently.


I should have some thoughts out soon on this that I hope might move us forward.


 


sean




 


From:
< cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 




Comments inline

Sent from my iPhone




On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:



Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.





 

Paul> I would agree that this would be in a chain






 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

Rich, on your comment below, you are correct that Packages do contain EMBEDDED STIX objects.
I was referring to situations where after receiving a Package you may want to break out objects from the Package they were received in but wish to maintain the fact that they were contained in that package.




You receive:
Package A
Indicator 1


You break out the Indicator and keep the Package for provenance (with the relationship fact that the Indicator was contained in the Package) so in your system you have:
Package A
Indicator 1
Indicator 1
Relationship 1 from Indicator 1 to Package A with nature=“Contained_In"


You later send:
Package B
Indicator 1
Relationship 1 from Indicator 1 to Package A with nature=“Contained_In”




That was the basic case I was referring to.
Does that make sense?


sean








From: Rich Piazza < rpiazza@mitre.org >
Date: Friday, February 5, 2016 at 5:36 PM
To: "Barnum, Sean D." < sbarnum@mitre.org >, " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources








Looks good.  Minor comment below:
 


From: Barnum, Sean D.

Sent: Friday, February 05, 2016 3:34 PM
To: Paul Patrick < ppatrick@isightpartners.com >; Piazza, Rich < rpiazza@mitre.org >
Cc: Wunder, John A. < jwunder@mitre.org >;
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



So, after thinking on this and talking through it with a couple of people here is where I have landed.


 


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate
them to content that they are the source for.


I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.


What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:


·         
sources external to STIX 

·         
sources internal to STIX



The sources internal to STIX are really  STIX objects from which another STIX object
was abstracted or generated. An obvious example would be content contained within a Package but many others are also likely.
 
I’m confused by this – I thought a package contained EMBEDDED STIX objects.  Maybe that is why you say it is “obvious”?  Maybe you were thinking Report?
 


The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar
information external to STIX (references).


So at this point:



·         
sources external to STIX 

o    
Person, organization or system

o    
Representation of similar information external to STIX

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible

External sources of person, organization or system then broke down into various roles these sorts of sources play including:




·         
producer (who created the actual STIX content)

·         
original source of the thinking

·         
original source of the content (structured or unstructured capture)

·         
any translation/transformation steps along the way

·         
anonymizer

·         
reviewer

·         
transmitter (who was the STIX content received from)


Similarly, the external representations of similar information external to STIX broke down into


·         
general references - simple URLs to documents, blog posts, web pages, etc.

·         
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

So at this point:



·         
sources external to STIX 

o    
Person, organization or system

§  
producer (who created the actual STIX content)

§  
original source of the thinking

§  
original source of the content (structured or unstructured capture)

§  
any translation/transformation steps along the way

§  
anonymizer

§  
reviewer

§  
transmitter (who was the STIX content received from)

o    
Representation of similar information external to STIX

§  
general references - simple URLs to documents, blog posts, web pages, etc.

§  
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible


 


I think this gives a pretty good overview of the types of sources we should support.


I then took a look across this thinking about the most appropriate way to represent these.


InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it
was generated.


The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference)
dimensions was a remaining open question.


The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


 


Here is what I propose:


·         
Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for
next week (identity-based objects like Source, Victim, Actor, etc.)

·         
Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP
and potentially for use with COA.

·         
Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:



·         
“reference_URL” (optional) - specifies a URL to the external reference



“external_identifier” (optional) - specifies an identifier for the external reference content



“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)



·         
Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


o    
Producer



Analysis Originator



Codification Originator



Translator



Transformer



Anonymizer



Reviewer



Transmitter



Derivation Resource


·         
Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship.

·         
Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)

For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially
be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those
wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable
and potentially remove one option.


 


John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.


 


I have attached a simple diagram showing a few various example use cases and how this approach would support them.


 


Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had
been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first.


 


Please let us know what you think.


 


Sean


 


From:
"Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 






Great conversation everyone.


 


Just wanted to let you know that this is not stagnating.


I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together
normative text where we can.


 


I am doing a lot of thinking and talking with some folks on this issue in particular.


It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning
to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently.


I should have some thoughts out soon on this that I hope might move us forward.


 


sean




 


From:
< cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 




Comments inline

Sent from my iPhone




On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:



Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.





 

Paul> I would agree that this would be in a chain






 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

I understand your use case, but I wasn’t expecting that we needed to support it, given the introduction of Report object.
 
If you want to talk about TLOs that have are grouped together for some “intent”, use the Report. My impression of a Package, going forward, was just a container
to hold a group of objects – like a non-descript cardboard box filled with TLOs.
 


From: Barnum, Sean D.

Sent: Monday, February 08, 2016 10:02 AM
To: Piazza, Rich <rpiazza@mitre.org>; Paul Patrick <ppatrick@isightpartners.com>
Cc: Wunder, John A. <jwunder@mitre.org>; cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Rich, on your comment below, you are correct that Packages do contain EMBEDDED STIX objects.


I was referring to situations where after receiving a Package you may want to break out objects from the Package they were received in
but wish to maintain the fact that they were contained in that package.


 


 


You receive:


Package A


               
Indicator 1


 


You break out the Indicator and keep the Package for provenance (with the relationship fact that the Indicator was contained in the Package)
so in your system you have:


Package A


               
Indicator 1


Indicator 1


Relationship 1 from Indicator 1 to Package A with nature=“Contained_In"


 


You later send:


Package B


               
Indicator 1


               
Relationship 1 from Indicator 1 to Package A with nature=“Contained_In”


 


 


That was the basic case I was referring to.


Does that make sense?


 


sean



 


From:
Rich Piazza < rpiazza@mitre.org >
Date: Friday, February 5, 2016 at 5:36 PM
To: "Barnum, Sean D." < sbarnum@mitre.org >, " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources


 



Looks good.  Minor comment below:
 


From: Barnum, Sean D.

Sent: Friday, February 05, 2016 3:34 PM
To: Paul Patrick < ppatrick@isightpartners.com >; Piazza, Rich < rpiazza@mitre.org >
Cc: Wunder, John A. < jwunder@mitre.org >;
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



So, after thinking on this and talking through it with a couple of people here is where I have landed.


 


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate
them to content that they are the source for.


I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.


What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:


·         
sources external to STIX 

·         
sources internal to STIX



The sources internal to STIX are really  STIX objects from which another STIX object was abstracted
or generated. An obvious example would be content contained within a Package but many others are also likely.
 
I’m confused by this – I thought a package contained EMBEDDED STIX objects.  Maybe that is why you say it is “obvious”?  Maybe you were
thinking Report?
 


The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information
external to STIX (references).


So at this point:



·         
sources external to STIX 

o    
Person, organization or system

o    
Representation of similar information external to STIX

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible

External sources of person, organization or system then broke down into various roles these sorts of sources play including:




·         
producer (who created the actual STIX content)

·         
original source of the thinking

·         
original source of the content (structured or unstructured capture)

·         
any translation/transformation steps along the way

·         
anonymizer

·         
reviewer

·         
transmitter (who was the STIX content received from)


Similarly, the external representations of similar information external to STIX broke down into


·         
general references - simple URLs to documents, blog posts, web pages, etc.

·         
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

So at this point:



·         
sources external to STIX 

o    
Person, organization or system

§  
producer (who created the actual STIX content)

§  
original source of the thinking

§  
original source of the content (structured or unstructured capture)

§  
any translation/transformation steps along the way

§  
anonymizer

§  
reviewer

§  
transmitter (who was the STIX content received from)

o    
Representation of similar information external to STIX

§  
general references - simple URLs to documents, blog posts, web pages, etc.

§  
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible


 


I think this gives a pretty good overview of the types of sources we should support.


I then took a look across this thinking about the most appropriate way to represent these.


InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how
it was generated.


The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference)
dimensions was a remaining open question.


The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


 


Here is what I propose:


·         
Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary
topic of discussion for next week (identity-based objects like Source, Victim, Actor, etc.)

·         
Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information
source but also for malicious tool as a TTP and potentially for use with COA.

·         
Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:



·         
“reference_URL” (optional) - specifies a URL to the external reference



“external_identifier” (optional) - specifies an identifier for the external reference content



“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)



·         
Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


o    
Producer



Analysis Originator



Codification Originator



Translator



Transformer



Anonymizer



Reviewer



Transmitter



Derivation Resource


·         
Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship.

·         
Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)

For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that
the producer could potentially be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the
producer ref may do so. Those wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach
of the other is clearly preferable and potentially remove one option.


 


John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.


 


I have attached a simple diagram showing a few various example use cases and how this approach would support them.


 


Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had
been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first.


 


Please let us know what you think.


 


Sean


 


From:
"Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 






Great conversation everyone.


 


Just wanted to let you know that this is not stagnating.


I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together
normative text where we can.


 


I am doing a lot of thinking and talking with some folks on this issue in particular.


It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning
to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently.


I should have some thoughts out soon on this that I hope might move us forward.


 


sean




 


From:
< cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 




Comments inline

Sent from my iPhone




On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:



Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.





 

Paul> I would agree that this would be in a chain







 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

Report and Package are two different use cases. One is about contextual correlation and the other is about provenance.


You are correct that Report is for expressing some correlation between a set of objects based on some explicit shared context (“intent”).
The use case I was describing below is not that use case.


The use case of maintaining linkages between content and the Packages it was seen in is a provenance use case not an analysis context use case.


This is an area where we have heard different intended implementation approaches from different members of the community.
Some have clearly expressed that they will treat Packages as pure envelopes, pull out the content and throw away the Package.
Others have expressed that they will pull out the content but also keep the Package itself around as a useful element of provenance.
I would suggest that neither approach is wrong. Different users and communities view the value of various content differently.
Supporting the latter approach places no requirement on the users of the former approach to support this operationally.


Those taking the former approach would not care about the example scenario I in the thread below.
Those taking the latter approach would care.


Does that make sense?


sean











From: Rich Piazza < rpiazza@mitre.org >
Date: Monday, February 8, 2016 at 10:41 AM
To: "Barnum, Sean D." < sbarnum@mitre.org >, " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources








I understand your use case, but I wasn’t expecting that we needed to support it, given the introduction of Report object.
 
If you want to talk about TLOs that have are grouped together for some “intent”, use the Report. My impression of a Package, going forward, was just a container
to hold a group of objects – like a non-descript cardboard box filled with TLOs.
 


From: Barnum, Sean D.

Sent: Monday, February 08, 2016 10:02 AM
To: Piazza, Rich < rpiazza@mitre.org >; Paul Patrick < ppatrick@isightpartners.com >
Cc: Wunder, John A. < jwunder@mitre.org >;
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Rich, on your comment below, you are correct that Packages do contain EMBEDDED STIX objects.


I was referring to situations where after receiving a Package you may want to break out objects from the Package they were received in
but wish to maintain the fact that they were contained in that package.


 


 


You receive:


Package A


               
Indicator 1


 


You break out the Indicator and keep the Package for provenance (with the relationship fact that the Indicator was contained in the Package)
so in your system you have:


Package A


               
Indicator 1


Indicator 1


Relationship 1 from Indicator 1 to Package A with nature=“Contained_In"


 


You later send:


Package B


               
Indicator 1


               
Relationship 1 from Indicator 1 to Package A with nature=“Contained_In”


 


 


That was the basic case I was referring to.


Does that make sense?


 


sean



 


From:
Rich Piazza < rpiazza@mitre.org >
Date: Friday, February 5, 2016 at 5:36 PM
To: "Barnum, Sean D." < sbarnum@mitre.org >, " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: RE: [cti] Kinds of Sources


 



Looks good.  Minor comment below:
 


From: Barnum, Sean D.

Sent: Friday, February 05, 2016 3:34 PM
To: Paul Patrick < ppatrick@isightpartners.com >; Piazza, Rich < rpiazza@mitre.org >
Cc: Wunder, John A. < jwunder@mitre.org >;
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 



So, after thinking on this and talking through it with a couple of people here is where I have landed.


 


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate
them to content that they are the source for.


I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.


What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:


·         
sources external to STIX 

·         
sources internal to STIX



The sources internal to STIX are really  STIX objects from which another STIX object was abstracted
or generated. An obvious example would be content contained within a Package but many others are also likely.
 
I’m confused by this – I thought a package contained EMBEDDED STIX objects.  Maybe that is why you say it is “obvious”?  Maybe you were
thinking Report?
 


The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information
external to STIX (references).


So at this point:



·         
sources external to STIX 

o    
Person, organization or system

o    
Representation of similar information external to STIX

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible

External sources of person, organization or system then broke down into various roles these sorts of sources play including:




·         
producer (who created the actual STIX content)

·         
original source of the thinking

·         
original source of the content (structured or unstructured capture)

·         
any translation/transformation steps along the way

·         
anonymizer

·         
reviewer

·         
transmitter (who was the STIX content received from)


Similarly, the external representations of similar information external to STIX broke down into


·         
general references - simple URLs to documents, blog posts, web pages, etc.

·         
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

So at this point:



·         
sources external to STIX 

o    
Person, organization or system

§  
producer (who created the actual STIX content)

§  
original source of the thinking

§  
original source of the content (structured or unstructured capture)

§  
any translation/transformation steps along the way

§  
anonymizer

§  
reviewer

§  
transmitter (who was the STIX content received from)

o    
Representation of similar information external to STIX

§  
general references - simple URLs to documents, blog posts, web pages, etc.

§  
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

·         
sources internal to STIX

o    
STIX objects from which another STIX object was abstracted or generated

§  
Obvious example would be Package but others are also possible


 


I think this gives a pretty good overview of the types of sources we should support.


I then took a look across this thinking about the most appropriate way to represent these.


InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how
it was generated.


The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference)
dimensions was a remaining open question.


The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


 


Here is what I propose:


·         
Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary
topic of discussion for next week (identity-based objects like Source, Victim, Actor, etc.)

·         
Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information
source but also for malicious tool as a TTP and potentially for use with COA.

·         
Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:



·         
“reference_URL” (optional) - specifies a URL to the external reference



“external_identifier” (optional) - specifies an identifier for the external reference content



“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)



·         
Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


o    
Producer



Analysis Originator



Codification Originator



Translator



Transformer



Anonymizer



Reviewer



Transmitter



Derivation Resource


·         
Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship.

·         
Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)

For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that
the producer could potentially be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the
producer ref may do so. Those wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach
of the other is clearly preferable and potentially remove one option.


 


John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.


 


I have attached a simple diagram showing a few various example use cases and how this approach would support them.


 


Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had
been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first.


 


Please let us know what you think.


 


Sean


 


From:
"Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 






Great conversation everyone.


 


Just wanted to let you know that this is not stagnating.


I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together
normative text where we can.


 


I am doing a lot of thinking and talking with some folks on this issue in particular.


It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning
to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently.


I should have some thoughts out soon on this that I hope might move us forward.


 


sean




 


From:
< cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources


 




Comments inline

Sent from my iPhone




On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:



Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.





 

Paul> I would agree that this would be in a chain







 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects,
which I was thinking would be handled by relationships.



 

This now looks like 90% how i did it in XORCISM  So I guess, going into the right direction :p On Friday, 5 February 2016, Barnum, Sean D. < sbarnum@mitre.org > wrote: So, after thinking on this and talking through it with a couple of people here is where I have landed. I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for. I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit. What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX: sources external to STIX  sources internal to STIX The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content contained within a Package but many others are also likely. The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information external to STIX (references). So at this point: sources external to STIX  Person, organization or system Representation of similar information external to STIX sources internal to STIX STIX objects from which another STIX object was abstracted or generated Obvious example would be Package but others are also possible External sources of person, organization or system then broke down into various roles these sorts of sources play including: producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from) Similarly, the external representations of similar information external to STIX broke down into general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) So at this point: sources external to STIX  Person, organization or system producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from) Representation of similar information external to STIX general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) sources internal to STIX STIX objects from which another STIX object was abstracted or generated Obvious example would be Package but others are also possible I think this gives a pretty good overview of the types of sources we should support. I then took a look across this thinking about the most appropriate way to represent these. InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated. The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question. The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question. Here is what I propose: Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next week (identity-based objects like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties: “reference_URL” (optional) - specifies a URL to the external reference “external_identifier” (optional) - specifies an identifier for the external reference content “defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.) Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values: Producer Analysis Originator Codification Originator Translator Transformer Anonymizer Reviewer Transmitter Derivation Resource Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.) For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove one option. John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution. I have attached a simple diagram showing a few various example use cases and how this approach would support them. Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first. Please let us know what you think. Sean From: "Barnum, Sean D." < sbarnum@mitre.org > Date: Friday, February 5, 2016 at 10:41 AM To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org > Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Kinds of Sources Great conversation everyone. Just wanted to let you know that this is not stagnating. I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can. I am doing a lot of thinking and talking with some folks on this issue in particular. It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently. I should have some thoughts out soon on this that I hope might move us forward. sean From: < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com > Date: Thursday, February 4, 2016 at 8:41 PM To: Rich Piazza < rpiazza@mitre.org > Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Kinds of Sources Comments inline Sent from my iPhone On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote: Comments below:   From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Wunder, John A. Sent: Thursday, February 04, 2016 2:18 PM To: cti@lists.oasis-open.org Subject: Re: [cti] Kinds of Sources   Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more of this opinion/assertion object?   This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships. Paul> I would agree that this would be in a chain   For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than just an identity.   I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking would be handled by relationships.  

Good to hear Jerome.
Thanks.









From: Jerome Athias < athiasjerome@gmail.com >
Date: Saturday, February 6, 2016 at 12:16 AM
To: "Barnum, Sean D." < sbarnum@mitre.org >
Cc: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >,
John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources




This now looks like 90% how i did it in XORCISM 
So I guess, going into the right direction :p

On Friday, 5 February 2016, Barnum, Sean D. < sbarnum@mitre.org > wrote:




So, after thinking on this and talking through it with a couple of people here is where I have landed.


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for.
I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.
What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:

sources external to STIX  sources internal to STIX





The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content contained
within a Package but many others are also likely.
The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information
external to STIX (references).
So at this point:


sources external to STIX 

Person, organization or system Representation of similar information external to STIX
sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible


External sources of person, organization or system then broke down into various roles these sorts of sources play including:



producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)

Similarly, the external representations of similar information external to STIX broke down into

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)
So at this point:


sources external to STIX 

Person, organization or system

producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)
Representation of similar information external to STIX

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible





I think this gives a pretty good overview of the types of sources we should support.
I then took a look across this thinking about the most appropriate way to represent these.
InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated.
The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question.
The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.


Here is what I propose:

Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next week (identity-based objects
like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:

“reference_URL” (optional) - specifies a URL to the external reference
“external_identifier” (optional) - specifies an identifier for the external reference content
“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)

Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


Producer
Analysis Originator
Codification Originator
Translator
Transformer
Anonymizer
Reviewer
Transmitter
Derivation Resource

Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)
For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by the embedded
ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency in relationships
may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove one option.


John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.


I have attached a simple diagram showing a few various example use cases and how this approach would support them.


Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out
to you all as soon as possible rather than delaying it to capture all the details first.


Please let us know what you think.


Sean




From: "Barnum, Sean D." < sbarnum@mitre.org >
Date: Friday, February 5, 2016 at 10:41 AM
To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >,
Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources







Great conversation everyone.


Just wanted to let you know that this is not stagnating.
I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can.


I am doing a lot of thinking and talking with some folks on this issue in particular.
It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way
to solve all of them coherently.
I should have some thoughts out soon on this that I hope might move us forward.


sean









From: < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com "
< ppatrick@isightpartners.com >
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza < rpiazza@mitre.org >
Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources





Comments inline

Sent from my iPhone

On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:





Comments below:
 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To:
cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources


 


Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then
pass that along and note that? Or is that more of this opinion/assertion object?
 
This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.







Paul> I would agree that this would be in a chain








 


For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this
will be an actual content object rather than just an identity.



 
I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.



 

This will be a great topic for our upcoming working meeting. I'm all for kicking the tires, looking under the hood, and going for a test drive before buying. I'm hoping by the time we finalize the spec we only have one approach for this use. -Marlon   From: cti@lists.oasis-open.org on behalf of Barnum, Sean D. Sent: Monday, February 08, 2016 10:02:55 AM To: Jerome Athias Cc: Paul Patrick; Piazza, Rich; Wunder, John A.; cti@lists.oasis-open.org Subject: Re: [cti] Kinds of Sources Good to hear Jerome. Thanks. From: Jerome Athias < athiasjerome@gmail.com > Date: Saturday, February 6, 2016 at 12:16 AM To: "Barnum, Sean D." < sbarnum@mitre.org > Cc: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >, John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Kinds of Sources This now looks like 90% how i did it in XORCISM  So I guess, going into the right direction :p On Friday, 5 February 2016, Barnum, Sean D. < sbarnum@mitre.org > wrote: So, after thinking on this and talking through it with a couple of people here is where I have landed. I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for. I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit. What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX: sources external to STIX  sources internal to STIX The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content contained within a Package but many others are also likely. The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information external to STIX (references). So at this point: sources external to STIX  Person, organization or system Representation of similar information external to STIX sources internal to STIX STIX objects from which another STIX object was abstracted or generated Obvious example would be Package but others are also possible External sources of person, organization or system then broke down into various roles these sorts of sources play including: producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from) Similarly, the external representations of similar information external to STIX broke down into general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) So at this point: sources external to STIX  Person, organization or system producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from) Representation of similar information external to STIX general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) sources internal to STIX STIX objects from which another STIX object was abstracted or generated Obvious example would be Package but others are also possible I think this gives a pretty good overview of the types of sources we should support. I then took a look across this thinking about the most appropriate way to represent these. InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated. The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question. The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question. Here is what I propose: Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next week (identity-based objects like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties: “reference_URL” (optional) - specifies a URL to the external reference “external_identifier” (optional) - specifies an identifier for the external reference content “defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.) Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values: Producer Analysis Originator Codification Originator Translator Transformer Anonymizer Reviewer Transmitter Derivation Resource Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.) For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove one option. John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution. I have attached a simple diagram showing a few various example use cases and how this approach would support them. Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first. Please let us know what you think. Sean From: "Barnum, Sean D." < sbarnum@mitre.org > Date: Friday, February 5, 2016 at 10:41 AM To: " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org > Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Kinds of Sources Great conversation everyone. Just wanted to let you know that this is not stagnating. I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can. I am doing a lot of thinking and talking with some folks on this issue in particular. It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently. I should have some thoughts out soon on this that I hope might move us forward. sean From: < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com " < ppatrick@isightpartners.com > Date: Thursday, February 4, 2016 at 8:41 PM To: Rich Piazza < rpiazza@mitre.org > Cc: John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Kinds of Sources Comments inline Sent from my iPhone On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote: Comments below:   From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Wunder, John A. Sent: Thursday, February 04, 2016 2:18 PM To: cti@lists.oasis-open.org Subject: Re: [cti] Kinds of Sources   Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more of this opinion/assertion object?   This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships. Paul> I would agree that this would be in a chain   For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than just an identity.   I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking would be handled by relationships.  

Can we see some examples of what you are explaining?  The way this is written it feels like we are adding a lot of additional complexity beyond what we have in STIX 1.2 today.  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 Feb 5, 2016, at 13:33, Barnum, Sean D. < sbarnum@mitre.org > wrote: So, after thinking on this and talking through it with a couple of people here is where I have landed. I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for. I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit. What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX: sources external to STIX  sources internal to STIX The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content contained within a Package but many others are also likely. The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information external to STIX (references). So at this point: sources external to STIX  Person, organization or system Representation of similar information external to STIX sources internal to STIX STIX objects from which another STIX object was abstracted or generated Obvious example would be Package but others are also possible External sources of person, organization or system then broke down into various roles these sorts of sources play including: producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from) Similarly, the external representations of similar information external to STIX broke down into general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) So at this point: sources external to STIX  Person, organization or system producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from) Representation of similar information external to STIX general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) sources internal to STIX STIX objects from which another STIX object was abstracted or generated Obvious example would be Package but others are also possible I think this gives a pretty good overview of the types of sources we should support. I then took a look across this thinking about the most appropriate way to represent these. InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated. The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question. The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question. Here is what I propose: Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next week (identity-based objects like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties: “reference_URL” (optional) - specifies a URL to the external reference “external_identifier” (optional) - specifies an identifier for the external reference content “defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.) Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values: Producer Analysis Originator Codification Originator Translator Transformer Anonymizer Reviewer Transmitter Derivation Resource Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.) For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove one option. John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution. I have attached a simple diagram showing a few various example use cases and how this approach would support them. Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first. Please let us know what you think. Sean From:   Barnum, Sean D. < sbarnum@mitre.org > Date:   Friday, February 5, 2016 at 10:41 AM To:   ppatrick@isightpartners.com < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org > Cc:   John Wunder < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Kinds of Sources Great conversation everyone. Just wanted to let you know that this is not stagnating. I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can. I am doing a lot of thinking and talking with some folks on this issue in particular. It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently. I should have some thoughts out soon on this that I hope might move us forward. sean From:   < cti@lists.oasis-open.org > on behalf of ppatrick@isightpartners.com < ppatrick@isightpartners.com > Date:   Thursday, February 4, 2016 at 8:41 PM To:   Rich Piazza < rpiazza@mitre.org > Cc:   John Wunder < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] Kinds of Sources Comments inline Sent from my iPhone On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote: Comments below:   From: cti@lists.oasis-open.org   [ mailto:cti@lists.oasis-open.org ]   On Behalf Of   Wunder, John A. Sent:   Thursday, February 04, 2016 2:18 PM To:   cti@lists.oasis-open.org Subject:   Re: [cti] Kinds of Sources   Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more of this opinion/assertion object?   This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships. Paul> I would agree that this would be in a chain   For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than just an identity.   I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking would be handled by relationships.   <Source examples.png> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that   generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I would see examples for two scenarios being especially important for demonstrating this approach:

Producer creates several objects (7 seems like a decent number to demonstrate scale w/o being overwhelming) Producer creates several objects (let’s say 7 again), indicates that they were created based on two references to non-STIX reports Anonymous producer would be another one, but that’s really just the absence of fields and relationships so I’m not sure it tells us much
For each example I think it would also be helpful to do it both with and without the optional “has-source” relationship to the identity of the producer.


Normally I’d volunteer but I don’t think I have time before the call tomorrow. Can somebody else? I could walk you through it if you want, talk to me on Slack.



John




From: "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Monday, February 8, 2016 at 1:42 PM
To: Sean Barnum < sbarnum@mitre.org >
Cc: Paul Patrick < ppatrick@isightpartners.com >, Rich Piazza < rpiazza@mitre.org >, "Wunder, John A." < jwunder@mitre.org >,
" cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Kinds of Sources





Can we see some examples of what you are explaining?  The way this is written it feels like we are adding a lot of additional complexity beyond what we have in STIX 1.2 today. 











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 Feb 5, 2016, at 13:33, Barnum, Sean D. < sbarnum@mitre.org > wrote:




So, after thinking on this and talking through it with a couple of people here is where I have landed.


I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate them to content that they are the source for.
I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit.
What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:

sources external to STIX  sources internal to STIX






The sources internal to STIX are really  STIX objects from which another STIX object was abstracted or generated. An obvious example would be content contained within a Package but many others are also likely.

The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information external to STIX (references).

So at this point:


sources external to STIX 

Person, organization or system Representation of similar information external to STIX
sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible


External sources of person, organization or system then broke down into various roles these sorts of sources play including:



producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)


Similarly, the external representations of similar information external to STIX broke down into

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

So at this point:


sources external to STIX 

Person, organization or system

producer (who created the actual STIX content) original source of the thinking original source of the content (structured or unstructured capture) any translation/transformation steps along the way anonymizer reviewer transmitter (who was the STIX content received from)
Representation of similar information external to STIX

general references - simple URLs to documents, blog posts, web pages, etc. Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)

sources internal to STIX

STIX objects from which another STIX object was abstracted or generated

Obvious example would be Package but others are also possible







I think this gives a pretty good overview of the types of sources we should support.

I then took a look across this thinking about the most appropriate way to represent these.

InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how it was generated.

The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference) dimensions was a remaining open question.

The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question.




Here is what I propose:

Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary topic of discussion for next
week (identity-based objects like Source, Victim, Actor, etc.) Add a new Tool top level object based on ToolInformationType. This offers a  basis for use here within information source but also for malicious tool as a TTP and potentially for use with COA. Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:


“reference_URL” (optional) - specifies a URL to the external reference
“external_identifier” (optional) - specifies an identifier for the external reference content
“defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)

Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:


Producer
Analysis Originator
Codification Originator
Translator
Transformer
Anonymizer
Reviewer
Transmitter
Derivation Resource

Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship. Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.)

For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that the producer could potentially be specified both by
the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the producer ref may do so. Those wishing for consistency
in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach of the other is clearly preferable and potentially remove
one option.




John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution.




I have attached a simple diagram showing a few various example use cases and how this approach would support them.




Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details
first.




Please let us know what you think.




Sean





From:   "Barnum, Sean D." < sbarnum@mitre.org >
Date:   Friday, February 5, 2016 at 10:41 AM
To:   " ppatrick@isightpartners.com " < ppatrick@isightpartners.com >,
Rich Piazza < rpiazza@mitre.org >
Cc:   John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject:   Re: [cti] Kinds of Sources







Great conversation everyone.


Just wanted to let you know that this is not stagnating.
I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together normative text where we can.


I am doing a lot of thinking and talking with some folks on this issue in particular.
It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding
a way to solve all of them coherently.
I should have some thoughts out soon on this that I hope might move us forward.


sean









From:   < cti@lists.oasis-open.org > on behalf of " ppatrick@isightpartners.com "
< ppatrick@isightpartners.com >
Date:   Thursday, February 4, 2016 at 8:41 PM
To:   Rich Piazza < rpiazza@mitre.org >
Cc:   John Wunder < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Subject:   Re: [cti] Kinds of Sources





Comments inline

Sent from my iPhone

On Feb 4, 2016, at 1:26 PM, Piazza, Rich < rpiazza@mitre.org > wrote:






Comments below:

 



From: cti@lists.oasis-open.org   [ mailto:cti@lists.oasis-open.org ]   On
Behalf Of   Wunder, John A.
Sent:   Thursday, February 04, 2016 2:18 PM
To:   cti@lists.oasis-open.org
Subject:   Re: [cti] Kinds of Sources



 



Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more
of this opinion/assertion object?

 

This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.







Paul> I would agree that this would be in a chain










 



For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than
just an identity.




 

I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking
would be handled by relationships.




 









<Source
examples.png>
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that  
generates
this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php