OASIS Cyber Threat Intelligence (CTI) TC

Regarding the SCO Relationships I notice that ‘belongs_to_ref’ will be made an external relationship for most of the SCOs that have it, but not for the Email Address Object. Is there a reason for this? What were the criteria used to determine which relationships would stay embedded vs be made external? Apologies if I’m missing something obvious or it has already been stated.   Thank you, Chris Lenk   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan Sent: Friday, April 19, 2019 1:01 PM To: cti@lists.oasis-open.org Subject: [cti] Working Call Agenda For Next Week   All,   As we work towards Milestone 2, there are a few things we need to resolve and get final clarity on.  Some of these topics will unfortunately be somewhat contentious.  In fact, there will be people on both sides that "_strongly_" disagree.  So while I understand we will not get unanimity, we need to get general consensus to move forward.  So it is important that we hear concrete use-cases in simple and easy to understand terms. We also need to respect that just because there is a use case, that does not mean the TC will agree to do it at this time.  So please, everyone!, be patient, calm, and let us work through these last few things.   Topics for the working call: Switch from JSON RFC8259 to I-JSON RFC7493 Change our definition of integer to comply with RFC7493 Versioning of Cyber Observables (* highly confrontational topic *)  Can we or should we support versioning by default on Cyber Observable objects? If we do, this will require breaking changes on other objects due to property name collisions People that need this, could do this with custom properties Right now we only have some of the properties and they are all optional So they do not follow the normal STIX versioning rules  No revoked or created_by_ref property What happens if you do not have versioning properties populated and then revision later? What happens if you have no created_by_ref, then can you really version it per our normal rules? Two groups have requested this, and several groups are against this.  Which SCO Properties are going to be stay as embedded relationships and which are going to move to external relationships I am including a spreadsheet in this email that shows what came out of the mini-group We just need to verify that this is correct.  If it is, we will need to define the "external relationships" for those properties that are changing  How will these new external relationships impact Patterning????   Please come prepared to discuss these issues.     Thanks Bret    

Great questions and thanks for bringing it up. I do not know the answer. If it was one that was missed, then we should talk about it.   Please everyone review that list of relationships from the excel sheet I sent out in detail. Bret From: Lenk, Chris <clenk@mitre.org> Sent: Tuesday, April 23, 2019 2:28:38 PM To: Bret Jordan; cti@lists.oasis-open.org Subject: [EXT] RE: [cti] Working Call Agenda For Next Week   Regarding the SCO Relationships I notice that ‘belongs_to_ref’ will be made an external relationship for most of the SCOs that have it, but not for the Email Address Object. Is there a reason for this? What were the criteria used to determine which relationships would stay embedded vs be made external? Apologies if I’m missing something obvious or it has already been stated.   Thank you, Chris Lenk   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan Sent: Friday, April 19, 2019 1:01 PM To: cti@lists.oasis-open.org Subject: [cti] Working Call Agenda For Next Week   All,   As we work towards Milestone 2, there are a few things we need to resolve and get final clarity on.  Some of these topics will unfortunately be somewhat contentious.  In fact, there will be people on both sides that "_strongly_" disagree.  So while I understand we will not get unanimity, we need to get general consensus to move forward.  So it is important that we hear concrete use-cases in simple and easy to understand terms. We also need to respect that just because there is a use case, that does not mean the TC will agree to do it at this time.  So please, everyone!, be patient, calm, and let us work through these last few things.   Topics for the working call: Switch from JSON RFC8259 to I-JSON RFC7493 Change our definition of integer to comply with RFC7493 Versioning of Cyber Observables (* highly confrontational topic *)  Can we or should we support versioning by default on Cyber Observable objects? If we do, this will require breaking changes on other objects due to property name collisions People that need this, could do this with custom properties Right now we only have some of the properties and they are all optional So they do not follow the normal STIX versioning rules  No revoked or created_by_ref property What happens if you do not have versioning properties populated and then revision later? What happens if you have no created_by_ref, then can you really version it per our normal rules? Two groups have requested this, and several groups are against this.  Which SCO Properties are going to be stay as embedded relationships and which are going to move to external relationships I am including a spreadsheet in this email that shows what came out of the mini-group We just need to verify that this is correct.  If it is, we will need to define the "external relationships" for those properties that are changing  How will these new external relationships impact Patterning????   Please come prepared to discuss these issues.     Thanks Bret