CTI STIX Subcommittee

Hey all,


We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza,
John Mark-Gurney, and Sean Barnum.


The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed:


1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains"
2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report.
3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1.
4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3.


#3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible.


I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt
with some diagrams of #1 and #2, though not #3.


By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt:



- The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is
- Changes to what’s in the report are versioned with the report itself
- Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report)
- There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report
- #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice


On the other hand, one or more people also felt that #1 was the right approach, because they felt that:


- Signatures and versioning are just as doable in #1
- Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources
- Reports may evolve over time and relationships enable
- That objects should “belong” to the report with some level of confidence
- It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful)
- It’s one way of doing things to have all references between TLOs happen via a relationship object



What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it.





Attachment: reports.pptx Description: reports.pptx

My vote is for option #2...   With option #1 there is no way to guarantee that a consumer will get all of the relationships and thus no way to guarantee that the consumer will get the full report.  So that is a show stopper for me.   Option #3 radically increases the complexity of what we are trying to do and greatly increases the amount of transactions and content that has to flow over the wire. 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 18, 2016, at 10:10, Wunder, John A. < jwunder@mitre.org > wrote: Hey all, We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum. The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed: 1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. 3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1. 4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3. #3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible. I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt with some diagrams of #1 and #2, though not #3. By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt: - The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is - Changes to what’s in the report are versioned with the report itself - Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report) - There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report - #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice On the other hand, one or more people also felt that #1 was the right approach, because they felt that: - Signatures and versioning are just as doable in #1 - Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources - Reports may evolve over time and relationships enable - That objects should “belong” to the report with some level of confidence - It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful) - It’s one way of doing things to have all references between TLOs happen via a relationship object What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it. <reports.pptx> --------------------------------------------------------------------- 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

definitely in favor of #2 as well based on the examples (thanks for them as they really help explain) on github. its simple, avoids unnecessary relationship object where its not required. allan On Feb 18, 2016, at 9:29 AM, Jordan, Bret < bret.jordan@BLUECOAT.COM > wrote: My vote is for option #2...   With option #1 there is no way to guarantee that a consumer will get all of the relationships and thus no way to guarantee that the consumer will get the full report.  So that is a show stopper for me.   Option #3 radically increases the complexity of what we are trying to do and greatly increases the amount of transactions and content that has to flow over the wire. 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 18, 2016, at 10:10, Wunder, John A. < jwunder@mitre.org > wrote: Hey all, We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum. The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed: 1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. 3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1. 4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3. #3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible. I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt with some diagrams of #1 and #2, though not #3. By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt: - The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is - Changes to what’s in the report are versioned with the report itself - Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report) - There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report - #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice On the other hand, one or more people also felt that #1 was the right approach, because they felt that: - Signatures and versioning are just as doable in #1 - Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources - Reports may evolve over time and relationships enable - That objects should “belong” to the report with some level of confidence - It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful) - It’s one way of doing things to have all references between TLOs happen via a relationship object What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it. <reports.pptx> --------------------------------------------------------------------- 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

Would it make sense to have Report as a relationshipType rather than a separate object?
 

Example
(using only created_by_ref for brevity)
{
 "type": "package",
 "id": "package--44af6c39-c09b-49c5-9de2-394224b04982",
 "sources":
   {
     "type": "identity",
     "id": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
     "name": "Symantec",
   }
 ],
 "indicators": [
   {
     "type": "indicator",
     "id": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
     "created_at": "2015-12-21T19:59:17.000000+00:00",
     "title": "Some indicator",
     "indicator_types": ["IP Watchlist"],
     "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
   }  
 ],
 "campaigns": [
   {
     "type": "campaign",
     "id": "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",
     "created_at": "2015-12-21T19:59:17.000000+00:00",
     "title": "Some Campaign",
     "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
   }
 ],
 "relationships": [
   {
     "type": "relationship",
     "id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68b",
     "created_at": "2015-12-21T19:59:17.000000+00:00",
     "from": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",
     "to": ["indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2"
            "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",
            "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a"
           ],
     "relationship_nature": "Report Contains",
     "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",
     "report_context":{
          "type": "report",   
          "id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",

          "created_at": "2015-12-21T19:59:11.000000+00:00",
          "title": "The Black Vine Cyberespionage Group",
          "description": "A simple report with an indicator, campaign and a relationship between them",
          "intents": ["Threat Report"],
          "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
        }
   },
   {
     "type": "relationship",
     "id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",
     "created_at": "2015-12-21T19:59:17.000000+00:00",
     "from": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
     "to": "campaign--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",
     "relationship_nature": "Related Campaign",
     "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"
   }
 ]
}
 
The following could be removed (debatable) within the report_context:
          "type": "report",                                     // implied by the “report_context” parent/key
          "id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd", // implied by the relationship “from” key
          "created_at": "2015-12-21T19:59:11.000000+00:00",     // implied by the relationship “created_at” key
 
 
What do you think?
 
-Marlon
 
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Allan Thomson
Sent: Thursday, February 18, 2016 12:34 PM
To: Jordan, Bret
Cc: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Report object approaches


 
definitely in favor of #2 as well based on the examples (thanks for them as they really help explain) on github.

 


its simple, avoids unnecessary relationship object where its not required.


 


allan


 





On Feb 18, 2016, at 9:29 AM, Jordan, Bret < bret.jordan@BLUECOAT.COM > wrote:

 


My vote is for option #2...  

 


With option #1 there is no way to guarantee that a consumer will get all of the relationships and thus no way to guarantee that the consumer will get the full report.  So that is a show stopper for me.  


 


Option #3 radically increases the complexity of what we are trying to do and greatly increases the amount of transactions and content that has to flow over the wire.

 


 







 


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

 


Hey all,

 


We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich
Piazza, John Mark-Gurney, and Sean Barnum.


 


The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed:


 


1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains"


2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report.


3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1.


4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3.


 


#3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible.


 


I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt
with some diagrams of #1 and #2, though not #3.


 


By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt:


 



- The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is


- Changes to what’s in the report are versioned with the report itself


- Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report)


- There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report


- #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice


 


On the other hand, one or more people also felt that #1 was the right approach, because they felt that:


 


- Signatures and versioning are just as doable in #1


- Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources


- Reports may evolve over time and relationships enable


- That objects should “belong” to the report with some level of confidence


- It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful)


- It’s one way of doing things to have all references between TLOs happen via a relationship object



 


What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it.


 


<reports.pptx>

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




 






 

Personally, I agree with #2.  I know it was brought up on the call on Tuesday the idea that reports can “grow” and “evolve”, but I don’t believe that to be true. The word report means something specific to a lot of people, and it means a representation of the facts at a specific point in time. I understand the use case of trying to group data together and have it evolve, but I wouldn’t call that a report.  I think we’re having yet another example of problems with overloaded language, just like the Incident/Investigation conversation. They might be functionally the same in terms of grouping data together, but they have specific connotations that I don’t think you’re going to get around.  Sarah Kelley Senior CERT Analyst Center for Internet Security (CIS) Integrated Intelligence Center (IIC) Multi-State Information Sharing and Analysis Center (MS-ISAC) 1-866-787-4722 (7×24 SOC) Email:  cert@cisecurity.org www.cisecurity.org Follow us @CISecurity From: < cti-stix@lists.oasis-open.org > on behalf of "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov > Date: Thursday, February 18, 2016 at 12:40 PM To: Allan Thomson < athomson@lgscout.com >, "Jordan, Bret" < bret.jordan@BLUECOAT.COM > Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Report object approaches Would it make sense to have Report as a relationshipType rather than a separate object?   Example (using only created_by_ref for brevity) {  "type": "package",  "id": "package--44af6c39-c09b-49c5-9de2-394224b04982",  "sources":    {      "type": "identity",      "id": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",      "name": "Symantec",    }  ],  "indicators": [    {      "type": "indicator",      "id": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",      "created_at": "2015-12-21T19:59:17.000000+00:00",      "title": "Some indicator",      "indicator_types": ["IP Watchlist"],      "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"    }    ],  "campaigns": [    {      "type": "campaign",      "id": "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",      "created_at": "2015-12-21T19:59:17.000000+00:00",      "title": "Some Campaign",      "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"    }  ],  "relationships": [    {      "type": "relationship",      "id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68b",      "created_at": "2015-12-21T19:59:17.000000+00:00",      "from": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",      "to": ["indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2"             "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",             "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a"            ],      "relationship_nature": "Report Contains",      "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",      "report_context":{           "type": "report",              "id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",           "created_at": "2015-12-21T19:59:11.000000+00:00",           "title": "The Black Vine Cyberespionage Group",           "description": "A simple report with an indicator, campaign and a relationship between them",           "intents": ["Threat Report"],           "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"         }    },    {      "type": "relationship",      "id": "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",      "created_at": "2015-12-21T19:59:17.000000+00:00",      "from": "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",      "to": "campaign--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",      "relationship_nature": "Related Campaign",      "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283"    }  ] }   The following could be removed (debatable) within the report_context:           "type": "report",                                     // implied by the “report_context” parent/key           "id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd", // implied by the relationship “from” key           "created_at": "2015-12-21T19:59:11.000000+00:00",     // implied by the relationship “created_at” key     What do you think?   -Marlon     From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson Sent: Thursday, February 18, 2016 12:34 PM To: Jordan, Bret Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Report object approaches   definitely in favor of #2 as well based on the examples (thanks for them as they really help explain) on github.   its simple, avoids unnecessary relationship object where its not required.   allan   On Feb 18, 2016, at 9:29 AM, Jordan, Bret < bret.jordan@BLUECOAT.COM > wrote:   My vote is for option #2...     With option #1 there is no way to guarantee that a consumer will get all of the relationships and thus no way to guarantee that the consumer will get the full report.  So that is a show stopper for me.     Option #3 radically increases the complexity of what we are trying to do and greatly increases the amount of transactions and content that has to flow over the wire.       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 18, 2016, at 10:10, Wunder, John A. < jwunder@mitre.org > wrote:   Hey all,   We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum.   The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed:   1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains" 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. 3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1. 4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3.   #3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible.   I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt with some diagrams of #1 and #2, though not #3.   By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt:   - The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is - Changes to what’s in the report are versioned with the report itself - Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report) - There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report - #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice   On the other hand, one or more people also felt that #1 was the right approach, because they felt that:   - Signatures and versioning are just as doable in #1 - Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources - Reports may evolve over time and relationships enable - That objects should “belong” to the report with some level of confidence - It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful) - It’s one way of doing things to have all references between TLOs happen via a relationship object   What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it.   <reports.pptx> --------------------------------------------------------------------- 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     ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . .

On 18.02.2016 17:51:38, Sarah Kelley wrote: > Personally, I agree with #2. > +1 for #2, let's not overcomplicate things. ^_^ > > I understand the use case of trying to group data together and have > it evolve, but I wouldn’t call that a report. I think we’re having > yet another example of problems with overloaded language, just like > the Incident/Investigation conversation. > Spot on, Sarah, you've sure got a knack for hitting the nail on the head! -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "It Has To Work." --RFC 1925 Attachment: signature.asc Description: PGP signature

Interesting idea, but I think that make it much more complex. 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 18, 2016, at 10:40, Taylor, Marlon < Marlon.Taylor@hq.dhs.gov > wrote: Would it make sense to have Report as a relationshipType rather than a separate object?   Example   (using only created_by_ref for brevity) {   type : package ,   id : package--44af6c39-c09b-49c5-9de2-394224b04982 ,   sources :    {       type : identity ,       id : identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283 ,       name : Symantec ,    }  ],   indicators : [    {       type : indicator ,       id : indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2 ,       created_at : 2015-12-21T19:59:17.000000+00:00 ,       title : Some indicator ,       indicator_types : [ IP Watchlist ],       created_by_ref : identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283    }    ],   campaigns : [    {       type : campaign ,       id : campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c ,       created_at : 2015-12-21T19:59:17.000000+00:00 ,       title : Some Campaign ,       created_by_ref : identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283    }  ],   relationships : [    {       type : relationship ,       id : relationship--f82356ae-fe6c-437c-9c24-6b64314ae68b ,       created_at : 2015-12-21T19:59:17.000000+00:00 ,       from : report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd ,       to : [ indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2             campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c ,              relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a            ],       relationship_nature : Report Contains ,       created_by_ref : identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283 ,      report_context :{            type : report ,               id : report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd ,            created_at : 2015-12-21T19:59:11.000000+00:00 ,            title : The Black Vine Cyberespionage Group ,            description : A simple report with an indicator, campaign and a relationship between them ,            intents : [ Threat Report ],            created_by_ref : identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283         }    },    {       type : relationship ,       id : relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a ,       created_at : 2015-12-21T19:59:17.000000+00:00 ,       from : indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2 ,       to : campaign--26ffb872-1dd9-446e-b6f5-d58527e5b5d2 ,       relationship_nature : Related Campaign ,       created_by_ref : identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283    }  ] }   The following could be removed (debatable) within the report_context:           type : report ,                                     // implied by the “report_context” parent/key            id : report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd , // implied by the relationship “from” key            created_at : 2015-12-21T19:59:11.000000+00:00 ,     // implied by the relationship “created_at” key     What do you think?   -Marlon     From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Allan Thomson Sent:   Thursday, February 18, 2016 12:34 PM To:   Jordan, Bret Cc:   Wunder, John A.;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Report object approaches   definitely in favor of #2 as well based on the examples (thanks for them as they really help explain) on github.   its simple, avoids unnecessary relationship object where its not required.   allan   On Feb 18, 2016, at 9:29 AM, Jordan, Bret < bret.jordan@BLUECOAT.COM > wrote:   My vote is for option #2...     With option #1 there is no way to guarantee that a consumer will get all of the relationships and thus no way to guarantee that the consumer will get the full report.  So that is a show stopper for me.     Option #3 radically increases the complexity of what we are trying to do and greatly increases the amount of transactions and content that has to flow over the wire.       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 18, 2016, at 10:10, Wunder, John A. < jwunder@mitre.org > wrote:   Hey all,     We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum.   The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed:   1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. 3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1. 4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3.   #3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible.   I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt with some diagrams of #1 and #2, though not #3.   By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt:   - The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is - Changes to what’s in the report are versioned with the report itself - Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report) - There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report - #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice   On the other hand, one or more people also felt that #1 was the right approach, because they felt that:   - Signatures and versioning are just as doable in #1 - Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources - Reports may evolve over time and relationships enable - That objects should “belong” to the report with some level of confidence - It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful) - It’s one way of doing things to have all references between TLOs happen via a relationship object   What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it.   <reports.pptx> --------------------------------------------------------------------- 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’d be in favor of #2.  Report is more “complete” and easier to verify.  And all of the other reasons articulated below.
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Thursday, February 18, 2016 12:11 PM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Report object approaches


 
Hey all,

 


We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich
Piazza, John Mark-Gurney, and Sean Barnum.


 


The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed:


 


1. The report contains just a title, description, and other TLO properties. Content is placed in the report through the use of relationships with a FROM of the report, a TO of the TLO, and a kind_of_relationship=“contains"


2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report.


3. A hybrid approach where the report contains the same items as #2, but the idrefs point to the relationships from #1.


4. A further hybrid where the report idrefs point to EITHER content as in #2 or relationships as in #3.


 


#3 and #4 are mainly compromise positions if you like #1 or #2 but are OK with something more optional/flexible.


 


I posted some examples on gist:  https://gist.github.com/johnwunder/a8c5a5107f07a83dad67  (except of #4, which would be redundant with #2 and #3). I also attached a .ppt
with some diagrams of #1 and #2, though not #3.


 


By the end of the conversation most of the group was gravitating towards #2, including myself. The reasons for this are that we felt:


 



- The report and the references to the content it contains can be signed as a single TLO, verifying that it is what we think it is


- Changes to what’s in the report are versioned with the report itself


- Only the original producer of the report indicates what’s in it, having other people indicate what’s in it is not an important use case (they can just issue their own report)


- There’s not a strong desire to represent how something is in a report (relationship nature or value field) or the confidence that something is in a report


- #3 in particular has a lot of double-booking, it’s redundant to represent that the information is contained in the report twice


 


On the other hand, one or more people also felt that #1 was the right approach, because they felt that:


 


- Signatures and versioning are just as doable in #1


- Having other people indicate things are in the report is a use case, and in any case even if it isn’t you can tell what the producer is asserting by looking at their sources


- Reports may evolve over time and relationships enable


- That objects should “belong” to the report with some level of confidence


- It might be important to say how content is in a report via kind_of_relationship (or, if not, it’s not harmful)


- It’s one way of doing things to have all references between TLOs happen via a relationship object



 


What do you think about this? Which of those options do you prefer? Let’s try to get some consensus on this so we can push it into the draft specs and close it.


 

Wunder, John A. wrote this message on Thu, Feb 18, 2016 at 17:10 +0000: > We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum. > > The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed: [...] > 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. I'm in favor of this... I do have a question though... Are there limits to which TLO's are included? I ask because could you possibly include a COA in it? and if so, you'd want to add a relationship object to associate it w/ an indicator... If so, relationship objects would be allowed, and in reality, it'd just be that reprot relationship objects would not exist.. [...] -- John-Mark

I would strongly suggest that there should be NO limits on what sort of TLOs could be in a Report. sean On 2/18/16, 2:00 PM, "cti-stix@lists.oasis-open.org on behalf of John-Mark Gurney" <cti-stix@lists.oasis-open.org on behalf of jmg@newcontext.com> wrote: >Wunder, John A. wrote this message on Thu, Feb 18, 2016 at 17:10 +0000: >> We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum. >> >> The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed: > >[...] > >> 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. > >I'm in favor of this... > >I do have a question though... Are there limits to which TLO's are >included? I ask because could you possibly include a COA in it? and >if so, you'd want to add a relationship object to associate it w/ an >indicator... If so, relationship objects would be allowed, and in >reality, it'd just be that reprot relationship objects would not exist.. > >[...] > >-- >John-Mark > >--------------------------------------------------------------------- >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 >

I think that was the general consensus on the Slack chat.... -----Original Message----- From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Thursday, February 18, 2016 2:04 PM To: John-Mark Gurney <jmg@newcontext.com>; Wunder, John A. <jwunder@mitre.org> Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Report object approaches I would strongly suggest that there should be NO limits on what sort of TLOs could be in a Report. sean On 2/18/16, 2:00 PM, "cti-stix@lists.oasis-open.org on behalf of John-Mark Gurney" <cti-stix@lists.oasis-open.org on behalf of jmg@newcontext.com> wrote: >Wunder, John A. wrote this message on Thu, Feb 18, 2016 at 17:10 +0000: >> We had a discussion on Slack about the Report object yesterday and I wanted to summarize for those of you who don’t want to read a 500msg back and forth. The people involved were myself, Bret Jordan, Jason Keirstead, Mark Davidson, Rich Piazza, John Mark-Gurney, and Sean Barnum. >> >> The topic of discussion was how you relate objects to a report, and there were essentially four options that were discussed: > >[...] > >> 2. The report contains a title, description, other TLO properties, and a list of idrefs for the content that the producer says are “in” the report. > >I'm in favor of this... > >I do have a question though... Are there limits to which TLO's are >included? I ask because could you possibly include a COA in it? and >if so, you'd want to add a relationship object to associate it w/ an >indicator... If so, relationship objects would be allowed, and in >reality, it'd just be that reprot relationship objects would not exist.. > >[...] > >-- >John-Mark > >--------------------------------------------------------------------- >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 >