OASIS Cyber Threat Intelligence (CTI) TC

All,
 
One of the topics we talked about at the F2F in DC was the question of how CybOX gets included in STIX. There was a very long discussion with a couple different options, but the two primary options were these:
 
1.       
CybOX has a container (defined by CybOX) that gets directly embedded in STIX TLOs as a field. So Observation and Asset would have a field called “cybox” (or something), that was a CybOX container.
I’ll call this approach “embedded cybox”.
2.       
CybOX has a container (defined by CybOX) that gets included as a STIX TLO itself. Things like observations and assets reference that “cybox-container” TLO by ID for their CybOX content. I’ll call
this approach “referenced cybox”.
 
There was decent consensus at the F2F was that #2 was the preferred approach (we took an informal straw poll). The thought was that it would allow people to reference existing CybOX containers rather than
having to duplicate content. F2F consensus is not SC consensus though: not everyone was at the F2F and we need to reconfirm things more broadly before moving forward.
 
To slightly complicate things, since the F2F, a decent chunk of people on Slack and in person have been getting consensus on Slack for the other approach (#1). The feeling is that the referenced approach is
overly verbose (an observation is 2 TLOs rather than 1) and containers are in reality not going to be referenced enough to make it worth it. Either way, I wanted to have us make a clear decision on the full list.
 
So, to show you an example, here’s an Observation via approach #2 (F2F consensus):
 
{
 "type": "observation",
 "id": "observation--b67d30ff-02ac-498a-92f9-32f845f448cf",
 "created_time": "2016-04-06T19:58:16Z",
 "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
 "start": "2015-12-21T19:00:00Z",
 "end": "2015-12-21T19:00:00Z",
 "count": 50,
 "cybox_container_ref": "cybox-container--e7130ab5-8c91-4660-8d89-033b1a2fc280"
},
{
 "type": "cybox-container",
 "id": "cybox-container--e7130ab5-8c91-4660-8d89-033b1a2fc280",
 "created_time": "2016-04-06T19:58:16Z",
 "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
 "objects": [
     {
     "type": "file-object",
     "file_name": "malware.exe",
     "hashes": {
     "md5": "3773a88f65a5e780c8dff9cdc3a056f3",
     "sha1": "cac35ec206d868b7d7cb0b55f31d9425b075082b"
   }
 ]
}
 
Note how it’s two TLOs to report the file observation, but you could reference that cybox-container from a different observation if you wanted to.
 
On the other hand, option #1 (recent consensus on Slack):
 
{
 "type": "observation",
 "id": "observation--b67d30ff-02ac-498a-92f9-32f845f448cf",
 "created_time": "2016-04-06T19:58:16Z",
 "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
 "start": "2015-12-21T19:00:00Z",
 "end": "2015-12-21T19:00:00Z",
 "count": 50,
 "cybox ": {
 "objects": [
  {
   "type": "file-object",
   "file_name": "malware.exe",
   "hashes": {
   "md5": "3773a88f65a5e780c8dff9cdc3a056f3",
   "sha1": "cac35ec206d868b7d7cb0b55f31d9425b075082b"
  }
 ]
}
 
While you can’t reference the CybOX from another observation, it’s only one TLO to report the observation and you don’t need to resolve an ID reference.
 
IMO it comes down to whether we see these CybOX containers commonly being reused by sensors and repositories across different producers. If they will be, then the referenced approach probably makes sense.
If they won’t be (sensors and other tools generate CybOX from scratch for each observation rather than looking up existing content in a database) then the embedded approach is probably better.
 
So, what do you think, and why?
 
Personally, I like approach #1 (as I did at the F2F). I don’t think that tools will in reality re-use CybOX content (especially sensors) and so the extra overhead of having to look up those cybox-containers
by ID (as well as the extra conceptual complexity for people to understand this approach) is not worth the tradeoff. I also feel like Observation is probably the STIX TLO that will be passed around the most at scale and so having to resolve that ID reference
to point to the container is a high cost (unlike, for example, Campaign, which will be at a much lower scale).
 
John

I prefer option #1...   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 Jun 23, 2016, at 14:39, Wunder, John A. < jwunder@mitre.org > wrote: All,   One of the topics we talked about at the F2F in DC was the question of how CybOX gets included in STIX. There was a very long discussion with a couple different options, but the two primary options were these:   1.          CybOX has a container (defined by CybOX) that gets directly embedded in STIX TLOs as a field. So Observation and Asset would have a field called “cybox” (or something), that was a CybOX container. I’ll call this approach “embedded cybox”. 2.          CybOX has a container (defined by CybOX) that gets included as a STIX TLO itself. Things like observations and assets reference that “cybox-container” TLO by ID for their CybOX content. I’ll call this approach “referenced cybox”.   There was decent consensus at the F2F was that #2 was the preferred approach (we took an informal straw poll). The thought was that it would allow people to reference existing CybOX containers rather than having to duplicate content. F2F consensus is not SC consensus though: not everyone was at the F2F and we need to reconfirm things more broadly before moving forward.   To slightly complicate things, since the F2F, a decent chunk of people on Slack and in person have been getting consensus on Slack for the other approach (#1). The feeling is that the referenced approach is overly verbose (an observation is 2 TLOs rather than 1) and containers are in reality not going to be referenced enough to make it worth it. Either way, I wanted to have us make a clear decision on the full list.   So, to show you an example, here’s an Observation via approach #2 (F2F consensus):   {   type : observation ,   id : observation--b67d30ff-02ac-498a-92f9-32f845f448cf ,   created_time : 2016-04-06T19:58:16Z ,   created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,   start : 2015-12-21T19:00:00Z ,   end : 2015-12-21T19:00:00Z ,   count : 50,   cybox_container_ref : cybox-container--e7130ab5-8c91-4660-8d89-033b1a2fc280 }, {   type : cybox-container ,   id : cybox-container--e7130ab5-8c91-4660-8d89-033b1a2fc280 ,   created_time : 2016-04-06T19:58:16Z ,   created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,   objects : [      {       type : file-object ,       file_name : malware.exe ,       hashes : {       md5 : 3773a88f65a5e780c8dff9cdc3a056f3 ,       sha1 : cac35ec206d868b7d7cb0b55f31d9425b075082b    }  ] }   Note how it’s two TLOs to report the file observation, but you could reference that cybox-container from a different observation if you wanted to.   On the other hand, option #1 (recent consensus on Slack):   {   type : observation ,   id : observation--b67d30ff-02ac-498a-92f9-32f845f448cf ,   created_time : 2016-04-06T19:58:16Z ,   created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,   start : 2015-12-21T19:00:00Z ,   end : 2015-12-21T19:00:00Z ,   count : 50,   cybox : {   objects : [   {     type : file-object ,     file_name : malware.exe ,     hashes : {     md5 : 3773a88f65a5e780c8dff9cdc3a056f3 ,     sha1 : cac35ec206d868b7d7cb0b55f31d9425b075082b   }  ] }   While you can’t reference the CybOX from another observation, it’s only one TLO to report the observation and you don’t need to resolve an ID reference.   IMO it comes down to whether we see these CybOX containers commonly being reused by sensors and repositories across different producers. If they will be, then the referenced approach probably makes sense. If they won’t be (sensors and other tools generate CybOX from scratch for each observation rather than looking up existing content in a database) then the embedded approach is probably better.   So, what do you think, and why?   Personally, I like approach #1 (as I did at the F2F). I don’t think that tools will in reality re-use CybOX content (especially sensors) and so the extra overhead of having to look up those cybox-containers by ID (as well as the extra conceptual complexity for people to understand this approach) is not worth the tradeoff. I also feel like Observation is probably the STIX TLO that will be passed around the most at scale and so having to resolve that ID reference to point to the container is a high cost (unlike, for example, Campaign, which will be at a much lower scale).   John Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Wunder, John A. wrote this message on Thu, Jun 23, 2016 at 20:39 +0000: > One of the topics we talked about at the F2F in DC was the question of how CybOX gets included in STIX. There was a very long discussion with a couple different options, but the two primary options were these: > > > 1. CybOX has a container (defined by CybOX) that gets directly embedded in STIX TLOs as a field. So Observation and Asset would have a field called “cybox” (or something), that was a CybOX container. I’ll call this approach “embedded cybox”. I support this approch. > 2. CybOX has a container (defined by CybOX) that gets included as a STIX TLO itself. Things like observations and assets reference that “cybox-container” TLO by ID for their CybOX content. I’ll call this approach “referenced cybox”. > > There was decent consensus at the F2F was that #2 was the preferred approach (we took an informal straw poll). The thought was that it would allow people to reference existing CybOX containers rather than having to duplicate content. F2F consensus is not SC consensus though: not everyone was at the F2F and we need to reconfirm things more broadly before moving forward. I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. > Personally, I like approach #1 (as I did at the F2F). I don’t think that tools will in reality re-use CybOX content (especially sensors) and so the extra overhead of having to look up those cybox-containers by ID (as well as the extra conceptual complexity for people to understand this approach) is not worth the tradeoff. I also feel like Observation is probably the STIX TLO that will be passed around the most at scale and so having to resolve that ID reference to point to the container is a high cost (unlike, for example, Campaign, which will be at a much lower scale). This is exactly why I like #1. The Observation object will probably be one of the largest objects by volume (may not be fully shared), and making it easy to use is good. -- John-Mark

I absolutely prefer option #1. An observation TLO was the always the place to embed CybOX objects in my mind. It was it's sole purpose. Cheers Terry MacDonald Cosive On 24/06/2016 07:28, "John-Mark Gurney" < jmg@newcontext.com > wrote: Wunder, John A. wrote this message on Thu, Jun 23, 2016 at 20:39 +0000: > One of the topics we talked about at the F2F in DC was the question of how CybOX gets included in STIX. There was a very long discussion with a couple different options, but the two primary options were these: > > > 1.       CybOX has a container (defined by CybOX) that gets directly embedded in STIX TLOs as a field. So Observation and Asset would have a field called “cybox” (or something), that was a CybOX container. I’ll call this approach “embedded cybox”. I support this approch. > 2.       CybOX has a container (defined by CybOX) that gets included as a STIX TLO itself. Things like observations and assets reference that “cybox-container” TLO by ID for their CybOX content. I’ll call this approach “referenced cybox”. > > There was decent consensus at the F2F was that #2 was the preferred approach (we took an informal straw poll). The thought was that it would allow people to reference existing CybOX containers rather than having to duplicate content. F2F consensus is not SC consensus though: not everyone was at the F2F and we need to reconfirm things more broadly before moving forward. I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly.  With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. > Personally, I like approach #1 (as I did at the F2F). I don’t think that tools will in reality re-use CybOX content (especially sensors) and so the extra overhead of having to look up those cybox-containers by ID (as well as the extra conceptual complexity for people to understand this approach) is not worth the tradeoff. I also feel like Observation is probably the STIX TLO that will be passed around the most at scale and so having to resolve that ID reference to point to the container is a high cost (unlike, for example, Campaign, which will be at a much lower scale). This is exactly why I like #1.  The Observation object will probably be one of the largest objects by volume (may not be fully shared), and making it easy to use is good. -- 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

On 23.06.2016 14:28:33, John-Mark Gurney wrote: > > I will say that part of the reason that #2 was chosen at the F2F was > that there are use cases for other standards, like DFAX, where they > want to be able to reference the CybOX object directly. With #2, the > CybOX container now has a unique GUID that can be addressed, but as > was pointed out, this still doesn't prevent referncing the CybOX > data, as an implementation can refer to the GUID of the Observation > TLO. > This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925 Attachment: signature.asc Description: Digital signature

We understand the problem so much more now than we did back in DC.  And the in looking at the structure it really does not makes sense to have a STIX TLO  called cybox-container.  In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container.  But now that we have put pen to paper, it really does not fit or work.   Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it.  MAEC for example is not going to use STIX objects to use CybOX data.  That just does not make sense.   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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com > wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. --RFC 1925 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct From: "Jordan, Bret" <bret.jordan@bluecoat.com> To: Trey Darley <trey@kingfisherops.com> Cc: John-Mark Gurney <jmg@newcontext.com>, "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date: 06/24/2016 09:30 AM Subject: Re: [cti] CybOX Containers in STIX Sent by: <cti@lists.oasis-open.org> We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work. Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense. 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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com > wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

They can do that be referencing the Observations or other TLOs in STIX if they so desire.   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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Jordan, Bret ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct From: Jordan, Bret < bret.jordan@bluecoat.com > To: Trey Darley < trey@kingfisherops.com > Cc: John-Mark Gurney < jmg@newcontext.com >, Wunder, John A. < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Date: 06/24/2016 09:30 AM Subject: Re: [cti] CybOX Containers in STIX Sent by: < cti@lists.oasis-open.org > We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work. Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense. 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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com > wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. --RFC 1925 [attachment signature.asc deleted by Jason Keirstead/CanEast/IBM] Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

+1 From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Friday, June 24, 2016 at 5:41 AM To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>, "Wunder, John" <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] CybOX Containers in STIX They can do that be referencing the Observations or other TLOs in STIX if they so desire. 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 Jun 24, 2016, at 06:38, Jason Keirstead <Jason.Keirstead@ca.ibm.com< mailto:Jason.Keirstead@ca.ibm.com >> wrote: I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security< http://www.ibm.com/security > www.securityintelligence.com< http://www.securityintelligence.com > Without data, all you are is just another person with an opinion - Unknown <graycol.gif>"Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct From: "Jordan, Bret" <bret.jordan@bluecoat.com< mailto:bret.jordan@bluecoat.com >> To: Trey Darley <trey@kingfisherops.com< mailto:trey@kingfisherops.com >> Cc: John-Mark Gurney <jmg@newcontext.com< mailto:jmg@newcontext.com >>, "Wunder, John A." <jwunder@mitre.org< mailto:jwunder@mitre.org >>, "cti@lists.oasis-open.org< mailto:cti@lists.oasis-open.org >" <cti@lists.oasis-open.org< mailto:cti@lists.oasis-open.org >> Date: 06/24/2016 09:30 AM Subject: Re: [cti] CybOX Containers in STIX Sent by: <cti@lists.oasis-open.org< mailto:cti@lists.oasis-open.org >> ________________________________ We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work. Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense. 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 Jun 24, 2016, at 03:15, Trey Darley <trey@kingfisherops.com< mailto:trey@kingfisherops.com >> wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] <<attachment: winmail.dat>>

All,
 
We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that, and the fact that discussion
has died down, I move that we open a ballot to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.
 
Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings, where we get a lot
of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this
priority one on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend it reviewing the Observation and Sighting sections of the STIX TLOs document.
 
Observation:

https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj
Sighting:

https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw
 
Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here:

https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi
 
John
 

From:
Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, June 24, 2016 at 10:16 AM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>, "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



+1
 

From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, June 24, 2016 at 5:41 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>, "Wunder, John" <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



They can do that be referencing the Observations or other TLOs in STIX if they so desire.  







 


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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

 


I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs.



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: Trey Darley < trey@kingfisherops.com >
Cc: John-Mark Gurney < jmg@newcontext.com >, "Wunder, John A."
< jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Date: 06/24/2016 09:30 AM
Subject: Re: [cti] CybOX Containers in STIX
Sent by: < cti@lists.oasis-open.org >










We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never
actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work.


Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense.



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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com >
wrote:

On 23.06.2016 14:28:33, John-Mark Gurney wrote:

I will say that part of the reason that #2 was chosen at the F2F was
that there are use cases for other standards, like DFAX, where they
want to be able to reference the CybOX object directly. With #2, the
CybOX container now has a unique GUID that can be addressed, but as
was pointed out, this still doesn't prevent referncing the CybOX
data, as an implementation can refer to the GUID of the Observation
TLO.

This was the infamous Arglebargle discussion, which was both heated
and long. Option #2 was a hard-won compromise to support the needs of
DFAX as expressed by Eoghan Casey et al.

Personally, I'm happy to go with option #1 for all the reasons
elucidated by John and Allan but in consideration of the many hours of
debate that went into the option #2 compromise, we should reenter that
discussion with sensitivity.

From a technical perspective it is not clear to me why DFAX couldn't
define its own container for CybOX, much as STIX and MAEC are doing.

If I recall correctly (and please weigh in here, good people of DC3!)
the primary motivation behind having a container object living in
CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're
calling them now across STIX, DFAX, and MAEC.

It's probably worth devoting the next TC working call to this topic,
since it's a critical question for STIX Indicators, Observations,
Sightings, not to mention the ongoing work of the CybOX SC and our
friends over at DC3.

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]








 

One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require CybOX, however). Is that
what we want? As a reminder, the use cases were:
 
1.       
“I saw this Indicator”
2.       
“I saw this Indicator 12 times between X time and Y time”
3.       
“I saw this Indicator and here’s the specific observation of what I saw”
4.       
“I saw this Campaign”
5.       
(#2 and #3 for campaign)
 
In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?
 
John
 

From:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Wednesday, June 29, 2016 at 11:25 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



All,
 
We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that, and the fact that discussion
has died down, I move that we open a ballot to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.
 
Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings, where we get a lot
of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this
priority one on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend it reviewing the Observation and Sighting sections of the STIX TLOs document.
 
Observation:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj
Sighting:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw
 
Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here:
https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi
 
John
 

From:
Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, June 24, 2016 at 10:16 AM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>, "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



+1
 

From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, June 24, 2016 at 5:41 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@kingfisherops.com>, John-Mark Gurney <jmg@newcontext.com>, "Wunder, John" <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



They can do that be referencing the Observations or other TLOs in STIX if they so desire.  







 


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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

 


I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs.



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: Trey Darley < trey@kingfisherops.com >
Cc: John-Mark Gurney < jmg@newcontext.com >, "Wunder, John A."
< jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Date: 06/24/2016 09:30 AM
Subject: Re: [cti] CybOX Containers in STIX
Sent by: < cti@lists.oasis-open.org >














We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never
actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work.


Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense.



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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com >
wrote:

On 23.06.2016 14:28:33, John-Mark Gurney wrote:

I will say that part of the reason that #2 was chosen at the F2F was
that there are use cases for other standards, like DFAX, where they
want to be able to reference the CybOX object directly. With #2, the
CybOX container now has a unique GUID that can be addressed, but as
was pointed out, this still doesn't prevent referncing the CybOX
data, as an implementation can refer to the GUID of the Observation
TLO.

This was the infamous Arglebargle discussion, which was both heated
and long. Option #2 was a hard-won compromise to support the needs of
DFAX as expressed by Eoghan Casey et al.

Personally, I'm happy to go with option #1 for all the reasons
elucidated by John and Allan but in consideration of the many hours of
debate that went into the option #2 compromise, we should reenter that
discussion with sensitivity.

From a technical perspective it is not clear to me why DFAX couldn't
define its own container for CybOX, much as STIX and MAEC are doing.

If I recall correctly (and please weigh in here, good people of DC3!)
the primary motivation behind having a container object living in
CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're
calling them now across STIX, DFAX, and MAEC.

It's probably worth devoting the next TC working call to this topic,
since it's a critical question for STIX Indicators, Observations,
Sightings, not to mention the ongoing work of the CybOX SC and our
friends over at DC3.

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]









 

I do not think we need it to be required...  But then again, I am in favor of also moving the count field from Observation to Sighting.  For example, if I want to sight a Threat Actor or a Campaign, it does not really make sense to include an Observation that uses CybOX, since CybOX can not describe a person or an abstract concept like a Campaign.   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 Jun 29, 2016, at 13:01, Wunder, John A. < jwunder@mitre.org > wrote: One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require CybOX, however). Is that what we want? As a reminder, the use cases were:   1.          “I saw this Indicator” 2.          “I saw this Indicator 12 times between X time and Y time” 3.          “I saw this Indicator and here’s the specific observation of what I saw” 4.          “I saw this Campaign” 5.          (#2 and #3 for campaign)   In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?   John   From:   < cti@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Wednesday, June 29, 2016 at 11:25 AM To:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] CybOX Containers in STIX   All,   We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that, and the fact that discussion has died down,   I move that we open a ballot   to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.   Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings, where we get a lot of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this   priority one   on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend it reviewing the Observation and Sighting sections of the STIX TLOs document.   Observation:   https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj Sighting:   https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw   Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi   John   From:   Allan Thomson < athomson@lookingglasscyber.com > Date:   Friday, June 24, 2016 at 10:16 AM To:   Jordan, Bret < bret.jordan@bluecoat.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc:   Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, Wunder, John A. < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] CybOX Containers in STIX   +1   From:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Jordan, Bret < bret.jordan@bluecoat.com > Date:   Friday, June 24, 2016 at 5:41 AM To:   Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc:   Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, Wunder, John < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   Re: [cti] CybOX Containers in STIX   They can do that be referencing the Observations or other TLOs in STIX if they so desire.     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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:   I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   <graycol.gif> Jordan, Bret ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct From:   Jordan, Bret < bret.jordan@bluecoat.com > To:   Trey Darley < trey@kingfisherops.com > Cc:   John-Mark Gurney < jmg@newcontext.com >, Wunder, John A. < jwunder@mitre.org >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Date:   06/24/2016 09:30 AM Subject:   Re: [cti] CybOX Containers in STIX Sent by:   < cti@lists.oasis-open.org > We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work.   Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense.   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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com > wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. --   Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. --RFC 1925 [attachment signature.asc deleted by Jason Keirstead/CanEast/IBM]     Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Hi Bret, An observation can be attached to the campaign object to describe the evidence that let someone to determine the campaign was attributed to that threat actor. I forsee observations being attached to nearly all the objects to provide the 'raw data' that the producer used to come up with their assertion. I am still puzzled at why we need sightings to effectively be a specialised 'summary' relationship, and but I am willing to go with the community opinion on this. I do wonder why we can have multiple cybox objects within an observation, as well as multiple observations within a sighting. When do we use each one? When should we use the multiple objects within observation compared to when we should use multiple observations within the sighting? We should either pick one object to house the multiplicity, or at least provide guidance on which data should be put where. E.g. when should an observed cybox  object be put in the same observation, or within a different observation? Should someone do one observation a day with all their cybox objects in there? Same thing for sightings. Cheers Terry MacDonald Cosive On 30/06/2016 06:01, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote: I do not think we need it to be required...  But then again, I am in favor of also moving the "count" field from Observation to Sighting.  For example, if I want to sight a Threat Actor or a Campaign, it does not really make sense to include an Observation that uses CybOX, since CybOX can not describe a "person" or an abstract concept like a Campaign.   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 Jun 29, 2016, at 13:01, Wunder, John A. < jwunder@mitre.org > wrote: One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require CybOX, however). Is that what we want? As a reminder, the use cases were:   1.          “I saw this Indicator” 2.          “I saw this Indicator 12 times between X time and Y time” 3.          “I saw this Indicator and here’s the specific observation of what I saw” 4.          “I saw this Campaign” 5.          (#2 and #3 for campaign)   In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?   John   From:   < cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date:   Wednesday, June 29, 2016 at 11:25 AM To:   " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject:   Re: [cti] CybOX Containers in STIX   All,   We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that, and the fact that discussion has died down,   I move that we open a ballot   to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.   Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings, where we get a lot of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this   priority one   on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend it reviewing the Observation and Sighting sections of the STIX TLOs document.   Observation:   https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj Sighting:   https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw   Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi   John   From:   Allan Thomson < athomson@lookingglasscyber.com > Date:   Friday, June 24, 2016 at 10:16 AM To:   "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc:   Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject:   Re: [cti] CybOX Containers in STIX   +1   From:   " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com > Date:   Friday, June 24, 2016 at 5:41 AM To:   Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc:   Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, "Wunder, John" < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject:   Re: [cti] CybOX Containers in STIX   They can do that be referencing the Observations or other TLOs in STIX if they so desire.     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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:   I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   <graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct From:   "Jordan, Bret" < bret.jordan@bluecoat.com > To:   Trey Darley < trey@kingfisherops.com > Cc:   John-Mark Gurney < jmg@newcontext.com >, "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date:   06/24/2016 09:30 AM Subject:   Re: [cti] CybOX Containers in STIX Sent by:   < cti@lists.oasis-open.org > We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work.   Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense.   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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com > wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. --   Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]    

IIRC the reason count is on Observation rather than Sighting was that people wanted to have a count available on observations that weren’t tied to sightings. For example, to say that they
saw an IP address 100 times without it being a sighting of any particular indicator. So to avoid having two count fields it was put just on observation.
 
I do agree w/ Terry that the reason you would want to sight a campaign with an observation would be to provide what you actually saw that made you think you had seen the campaign. You wouldn’t
describe the campaign itself in CybOX, then, you would describe what you saw in cyber that made you create a sighting of it.
 
John
 

From:
Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, June 29, 2016 at 5:50 PM
To: Bret Jordan <bret.jordan@bluecoat.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



Hi Bret,
An observation can be attached to the campaign object to describe the evidence that let someone to determine the campaign was attributed to that threat actor. I forsee observations being attached to nearly all the objects to provide the 'raw data' that the
producer used to come up with their assertion.
I am still puzzled at why we need sightings to effectively be a specialised 'summary' relationship, and but I am willing to go with the community opinion on this.
I do wonder why we can have multiple cybox objects within an observation, as well as multiple observations within a sighting. When do we use each one? When should we use the multiple objects within observation compared to when we should use multiple observations
within the sighting? We should either pick one object to house the multiplicity, or at least provide guidance on which data should be put where. E.g. when should an observed cybox  object be put in the same observation, or within a different observation? Should
someone do one observation a day with all their cybox objects in there? Same thing for sightings.
Cheers
Terry MacDonald
Cosive

On 30/06/2016 06:01, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote:


I do not think we need it to be required...  But then again, I am in favor of also moving the "count" field from Observation to Sighting.  For example, if I want to sight a Threat Actor or a Campaign, it does not really make sense to include
an Observation that uses CybOX, since CybOX can not describe a "person" or an abstract concept like a Campaign.  







 


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 Jun 29, 2016, at 13:01, Wunder, John A. < jwunder@mitre.org > wrote:

 



One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require
CybOX, however). Is that what we want? As a reminder, the use cases were:


 


1.         “I saw this Indicator”


2.         “I saw this Indicator 12 times between X time and Y time”


3.         “I saw this Indicator and here’s the specific observation
of what I saw”


4.         “I saw this Campaign”


5.         (#2 and #3 for campaign)


 


In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?


 


John


 



From:  < cti@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date:  Wednesday, June 29, 2016 at 11:25 AM
To:  " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:  Re: [cti] CybOX Containers in STIX




 





All,


 


We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that,
and the fact that discussion has died down,  I move that we open a ballot  to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.


 


Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings,
where we get a lot of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this  priority one  on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend
it reviewing the Observation and Sighting sections of the STIX TLOs document.


 


Observation:  https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj


Sighting:  https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw


 


Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi


 


John


 



From:  Allan Thomson < athomson@lookingglasscyber.com >
Date:  Friday, June 24, 2016 at 10:16 AM
To:  "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc:  Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >,
"Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:  Re: [cti] CybOX Containers in STIX




 





+1


 



From:  " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com >
Date:  Friday, June 24, 2016 at 5:41 AM
To:  Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc:  Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, "Wunder, John" < jwunder@mitre.org >,
" cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:  Re: [cti] CybOX Containers in STIX




 





They can do that be referencing the Observations or other TLOs in STIX if they so desire.  








 



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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:



 




I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs.



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security     www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown 


<graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct

From:  "Jordan, Bret" < bret.jordan@bluecoat.com >
To:  Trey Darley < trey@kingfisherops.com >
Cc:  John-Mark Gurney < jmg@newcontext.com >,
"Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Date:  06/24/2016 09:30 AM
Subject:  Re: [cti] CybOX Containers in STIX
Sent by:  < cti@lists.oasis-open.org >


















We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never
actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work. 

Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense. 


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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com >
wrote:

On 23.06.2016 14:28:33, John-Mark Gurney wrote:



I will say that part of the reason that #2 was chosen at the F2F was
that there are use cases for other standards, like DFAX, where they
want to be able to reference the CybOX object directly. With #2, the
CybOX container now has a unique GUID that can be addressed, but as
was pointed out, this still doesn't prevent referncing the CybOX
data, as an implementation can refer to the GUID of the Observation
TLO.



This was the infamous Arglebargle discussion, which was both heated
and long. Option #2 was a hard-won compromise to support the needs of
DFAX as expressed by Eoghan Casey et al.

Personally, I'm happy to go with option #1 for all the reasons
elucidated by John and Allan but in consideration of the many hours of
debate that went into the option #2 compromise, we should reenter that
discussion with sensitivity.

From a technical perspective it is not clear to me why DFAX couldn't
define its own container for CybOX, much as STIX and MAEC are doing.

If I recall correctly (and please weigh in here, good people of DC3!)
the primary motivation behind having a container object living in
CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're
calling them now across STIX, DFAX, and MAEC.

It's probably worth devoting the next TC working call to this topic,
since it's a critical question for STIX Indicators, Observations,
Sightings, not to mention the ongoing work of the CybOX SC and our
friends over at DC3.

-- 
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] 








 











 

What about a threat actor.  ?? Bret  Sent from my Commodore 64 On Jun 29, 2016, at 6:44 PM, Wunder, John A. < jwunder@mitre.org > wrote: IIRC the reason count is on Observation rather than Sighting was that people wanted to have a count available on observations that weren’t tied to sightings. For example, to say that they saw an IP address 100 times without it being a sighting of any particular indicator. So to avoid having two count fields it was put just on observation.   I do agree w/ Terry that the reason you would want to sight a campaign with an observation would be to provide what you actually saw that made you think you had seen the campaign. You wouldn’t describe the campaign itself in CybOX, then, you would describe what you saw in cyber that made you create a sighting of it.   John   From: Terry MacDonald < terry.macdonald@cosive.com > Date: Wednesday, June 29, 2016 at 5:50 PM To: Bret Jordan < bret.jordan@bluecoat.com > Cc: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] CybOX Containers in STIX   Hi Bret, An observation can be attached to the campaign object to describe the evidence that let someone to determine the campaign was attributed to that threat actor. I forsee observations being attached to nearly all the objects to provide the 'raw data' that the producer used to come up with their assertion. I am still puzzled at why we need sightings to effectively be a specialised 'summary' relationship, and but I am willing to go with the community opinion on this. I do wonder why we can have multiple cybox objects within an observation, as well as multiple observations within a sighting. When do we use each one? When should we use the multiple objects within observation compared to when we should use multiple observations within the sighting? We should either pick one object to house the multiplicity, or at least provide guidance on which data should be put where. E.g. when should an observed cybox  object be put in the same observation, or within a different observation? Should someone do one observation a day with all their cybox objects in there? Same thing for sightings. Cheers Terry MacDonald Cosive On 30/06/2016 06:01, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote: I do not think we need it to be required...  But then again, I am in favor of also moving the "count" field from Observation to Sighting.  For example, if I want to sight a Threat Actor or a Campaign, it does not really make sense to include an Observation that uses CybOX, since CybOX can not describe a "person" or an abstract concept like a Campaign.     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 Jun 29, 2016, at 13:01, Wunder, John A. < jwunder@mitre.org > wrote:   One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require CybOX, however). Is that what we want? As a reminder, the use cases were:   1.         “I saw this Indicator” 2.         “I saw this Indicator 12 times between X time and Y time” 3.         “I saw this Indicator and here’s the specific observation of what I saw” 4.         “I saw this Campaign” 5.         (#2 and #3 for campaign)   In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?   John   From:  < cti@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date:  Wednesday, June 29, 2016 at 11:25 AM To:  " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject:  Re: [cti] CybOX Containers in STIX   All,   We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that, and the fact that discussion has died down,  I move that we open a ballot  to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.   Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings, where we get a lot of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this  priority one  on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend it reviewing the Observation and Sighting sections of the STIX TLOs document.   Observation:  https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj Sighting:  https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw   Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi   John   From:  Allan Thomson < athomson@lookingglasscyber.com > Date:  Friday, June 24, 2016 at 10:16 AM To:  "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc:  Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject:  Re: [cti] CybOX Containers in STIX   +1   From:  " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com > Date:  Friday, June 24, 2016 at 5:41 AM To:  Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc:  Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, "Wunder, John" < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject:  Re: [cti] CybOX Containers in STIX   They can do that be referencing the Observations or other TLOs in STIX if they so desire.     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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:   I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown  <graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct From:  "Jordan, Bret" < bret.jordan@bluecoat.com > To:  Trey Darley < trey@kingfisherops.com > Cc:  John-Mark Gurney < jmg@newcontext.com >, "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Date:  06/24/2016 09:30 AM Subject:  Re: [cti] CybOX Containers in STIX Sent by:  < cti@lists.oasis-open.org > We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work.  Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense.  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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com > wrote: On 23.06.2016 14:28:33, John-Mark Gurney wrote: I will say that part of the reason that #2 was chosen at the F2F was that there are use cases for other standards, like DFAX, where they want to be able to reference the CybOX object directly. With #2, the CybOX container now has a unique GUID that can be addressed, but as was pointed out, this still doesn't prevent referncing the CybOX data, as an implementation can refer to the GUID of the Observation TLO. This was the infamous Arglebargle discussion, which was both heated and long. Option #2 was a hard-won compromise to support the needs of DFAX as expressed by Eoghan Casey et al. Personally, I'm happy to go with option #1 for all the reasons elucidated by John and Allan but in consideration of the many hours of debate that went into the option #2 compromise, we should reenter that discussion with sensitivity. From a technical perspective it is not clear to me why DFAX couldn't define its own container for CybOX, much as STIX and MAEC are doing. If I recall correctly (and please weigh in here, good people of DC3!) the primary motivation behind having a container object living in CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're calling them now across STIX, DFAX, and MAEC. It's probably worth devoting the next TC working call to this topic, since it's a critical question for STIX Indicators, Observations, Sightings, not to mention the ongoing work of the CybOX SC and our friends over at DC3. --  Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]     

I sould say the same for threat actor or any other object.
You would want to sight a threat actor with an observation in order to provide what you actually saw that made you think you had seen the threat actor. You wouldn’t describe the threat actor itself in
CybOX, then, you would describe what you saw in cyber that made you create a sighting of it.
 

From:
"Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 30, 2016 at 7:29 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 




What about a threat actor.  ??


 


Bret 

Sent from my Commodore 64



On Jun 29, 2016, at 6:44 PM, Wunder, John A. < jwunder@mitre.org > wrote:



IIRC the reason count is on Observation rather than Sighting was that people wanted to have a count available on observations that weren’t tied to sightings. For example, to say that they
saw an IP address 100 times without it being a sighting of any particular indicator. So to avoid having two count fields it was put just on observation.
 
I do agree w/ Terry that the reason you would want to sight a campaign with an observation would be to provide what you actually saw that made you think you had seen the campaign. You wouldn’t
describe the campaign itself in CybOX, then, you would describe what you saw in cyber that made you create a sighting of it.
 
John
 

From:
Terry MacDonald < terry.macdonald@cosive.com >
Date: Wednesday, June 29, 2016 at 5:50 PM
To: Bret Jordan < bret.jordan@bluecoat.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] CybOX Containers in STIX


 



Hi Bret,
An observation can be attached to the campaign object to describe the evidence that let someone to determine the campaign was attributed to that threat actor. I forsee observations being attached to nearly all the objects to provide the 'raw data' that the
producer used to come up with their assertion.
I am still puzzled at why we need sightings to effectively be a specialised 'summary' relationship, and but I am willing to go with the community opinion on this.
I do wonder why we can have multiple cybox objects within an observation, as well as multiple observations within a sighting. When do we use each one? When should we use the multiple objects within observation compared to when we should use multiple observations
within the sighting? We should either pick one object to house the multiplicity, or at least provide guidance on which data should be put where. E.g. when should an observed cybox  object be put in the same observation, or within a different observation? Should
someone do one observation a day with all their cybox objects in there? Same thing for sightings.
Cheers
Terry MacDonald
Cosive

On 30/06/2016 06:01, "Jordan, Bret" < bret.jordan@bluecoat.com > wrote:


I do not think we need it to be required...  But then again, I am in favor of also moving the "count" field from Observation to Sighting.  For example, if I want to sight a Threat Actor or a Campaign, it does not really make sense to include
an Observation that uses CybOX, since CybOX can not describe a "person" or an abstract concept like a Campaign.  







 


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 Jun 29, 2016, at 13:01, Wunder, John A. < jwunder@mitre.org > wrote:

 



One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require
CybOX, however). Is that what we want? As a reminder, the use cases were:


 


1.         “I saw this Indicator”


2.         “I saw this Indicator 12 times between X time and Y time”


3.         “I saw this Indicator and here’s the specific observation
of what I saw”


4.         “I saw this Campaign”


5.         (#2 and #3 for campaign)


 


In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?


 


John


 



From:  < cti@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date:  Wednesday, June 29, 2016 at 11:25 AM
To:  " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:  Re: [cti] CybOX Containers in STIX




 





All,


 


We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that,
and the fact that discussion has died down,  I move that we open a ballot  to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.


 


Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings,
where we get a lot of very good comments after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this  priority one  on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend
it reviewing the Observation and Sighting sections of the STIX TLOs document.


 


Observation:  https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj


Sighting:  https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw


 


Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi


 


John


 



From:  Allan Thomson < athomson@lookingglasscyber.com >
Date:  Friday, June 24, 2016 at 10:16 AM
To:  "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc:  Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >,
"Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:  Re: [cti] CybOX Containers in STIX




 





+1


 



From:  " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com >
Date:  Friday, June 24, 2016 at 5:41 AM
To:  Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc:  Trey Darley < trey@kingfisherops.com >, John-Mark Gurney < jmg@newcontext.com >, "Wunder, John" < jwunder@mitre.org >,
" cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject:  Re: [cti] CybOX Containers in STIX




 





They can do that be referencing the Observations or other TLOs in STIX if they so desire.  








 



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 Jun 24, 2016, at 06:38, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:



 




I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs.



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security     www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown 


<graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct

From:  "Jordan, Bret" < bret.jordan@bluecoat.com >
To:  Trey Darley < trey@kingfisherops.com >
Cc:  John-Mark Gurney < jmg@newcontext.com >,
"Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Date:  06/24/2016 09:30 AM
Subject:  Re: [cti] CybOX Containers in STIX
Sent by:  < cti@lists.oasis-open.org >




















We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never
actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work. 

Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense. 


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 Jun 24, 2016, at 03:15, Trey Darley < trey@kingfisherops.com >
wrote:

On 23.06.2016 14:28:33, John-Mark Gurney wrote:



I will say that part of the reason that #2 was chosen at the F2F was
that there are use cases for other standards, like DFAX, where they
want to be able to reference the CybOX object directly. With #2, the
CybOX container now has a unique GUID that can be addressed, but as
was pointed out, this still doesn't prevent referncing the CybOX
data, as an implementation can refer to the GUID of the Observation
TLO.



This was the infamous Arglebargle discussion, which was both heated
and long. Option #2 was a hard-won compromise to support the needs of
DFAX as expressed by Eoghan Casey et al.

Personally, I'm happy to go with option #1 for all the reasons
elucidated by John and Allan but in consideration of the many hours of
debate that went into the option #2 compromise, we should reenter that
discussion with sensitivity.

From a technical perspective it is not clear to me why DFAX couldn't
define its own container for CybOX, much as STIX and MAEC are doing.

If I recall correctly (and please weigh in here, good people of DC3!)
the primary motivation behind having a container object living in
CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're
calling them now across STIX, DFAX, and MAEC.

It's probably worth devoting the next TC working call to this topic,
since it's a critical question for STIX Indicators, Observations,
Sightings, not to mention the ongoing work of the CybOX SC and our
friends over at DC3.

-- 
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] 









 











 

On 29.06.2016 15:25:59, Wunder, John A. wrote: > Observation: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj > Please remind me why the `cybox` field is optional on a STIX Observation. Seems like an Observation without a CybOX payload is pointless. > > Sighting: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw > Looks good to me. > Note that everything in the “cybox” key will be defined by the CybOX > specification. In CybOX, that type is currently defined here: > https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi > If we go with directly embedding CybOX in the STIX Observation, then that CybOX type definition will have to change. We may do away with the CybOX Container (née ArgleBargle) altogether but we should still define in CybOX what are the allowable top-level keys inside of a STIX Observation's `cybox` field; currently this would be: * `objects` => array of type cybox-object (optional) * `actions` => array of type cybox-action (optional) Does everyone agree that what is allowable inside the STIX Observation's `cybox` field gets defined over in CybOX land? -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925 Attachment: signature.asc Description: Digital signature

RE: CybOX being optional…the thought was that you might want to say you saw something (e.g. an indicator) 150 times without providing detailed CybOX for what you had actually seen. It was mainly for the sighting use case vs. the observation w/o sighting use case. I’ve noticed that our design approach for Observation/Sighting makes things consistent across like 4 different use cases, but the tradeoff is that when you look at it for any single one of those use cases it might appear to have some extra fields or weird features. IMO it’s probably a good thing (they all seem like important use cases) but it does mean we need to explain how it should work very well in documentation. John On 6/30/16, 3:52 AM, "Trey Darley" <trey@kingfisherops.com> wrote: On 29.06.2016 15:25:59, Wunder, John A. wrote: > Observation: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj > Please remind me why the `cybox` field is optional on a STIX Observation. Seems like an Observation without a CybOX payload is pointless. > > Sighting: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw > Looks good to me. > Note that everything in the “cybox” key will be defined by the CybOX > specification. In CybOX, that type is currently defined here: > https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi > If we go with directly embedding CybOX in the STIX Observation, then that CybOX type definition will have to change. We may do away with the CybOX Container (née ArgleBargle) altogether but we should still define in CybOX what are the allowable top-level keys inside of a STIX Observation's `cybox` field; currently this would be: * `objects` => array of type cybox-object (optional) * `actions` => array of type cybox-action (optional) Does everyone agree that what is allowable inside the STIX Observation's `cybox` field gets defined over in CybOX land? -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925

And we should carefully go through the workflows for these to make sure they do in fact work as we think we need them to work. 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 Jun 30, 2016, at 07:13, Wunder, John A. < jwunder@mitre.org > wrote: RE: CybOX being optional…the thought was that you might want to say you saw something (e.g. an indicator) 150 times without providing detailed CybOX for what you had actually seen. It was mainly for the sighting use case vs. the observation w/o sighting use case. I’ve noticed that our design approach for Observation/Sighting makes things consistent across like 4 different use cases, but the tradeoff is that when you look at it for any single one of those use cases it might appear to have some extra fields or weird features. IMO it’s probably a good thing (they all seem like important use cases) but it does mean we need to explain how it should work very well in documentation. John On 6/30/16, 3:52 AM, Trey Darley < trey@kingfisherops.com > wrote: On 29.06.2016 15:25:59, Wunder, John A. wrote: Observation: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj Please remind me why the `cybox` field is optional on a STIX Observation. Seems like an Observation without a CybOX payload is pointless. Sighting: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw Looks good to me. Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi If we go with directly embedding CybOX in the STIX Observation, then that CybOX type definition will have to change. We may do away with the CybOX Container (née ArgleBargle) altogether but we should still define in CybOX what are the allowable top-level keys inside of a STIX Observation's `cybox` field; currently this would be:  * `objects` => array of type cybox-object (optional)  * `actions` => array of type cybox-action (optional) Does everyone agree that what is allowable inside the STIX Observation's `cybox` field gets defined over in CybOX land? -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. --RFC 1925 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Yeah agreed, I had a side channel with Trey and we talked about how more examples/workflows would be really helpful. I can take some time today or tomorrow and put some together, this would
be a great topic to have settled soon.
 

From:
"Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 30, 2016 at 9:47 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX


 



And we should carefully go through the workflows for these to make sure they do in fact work as we think we need them to work.







 


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 Jun 30, 2016, at 07:13, Wunder, John A. < jwunder@mitre.org > wrote:

 


RE: CybOX being optional…the thought was that you might want to say you saw something (e.g. an indicator) 150 times without providing detailed CybOX for what you had actually seen. It was mainly for the sighting use case vs. the observation
w/o sighting use case.

I’ve noticed that our design approach for Observation/Sighting makes things consistent across like 4 different use cases, but the tradeoff is that when you look at it for any single one of those use cases it might appear to have some extra fields or weird features.
IMO it’s probably a good thing (they all seem like important use cases) but it does mean we need to explain how it should work very well in documentation.

John

On 6/30/16, 3:52 AM, "Trey Darley" < trey@kingfisherops.com > wrote:

On 29.06.2016 15:25:59, Wunder, John A. wrote:



Observation:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj


Please remind me why the `cybox` field is optional on a STIX
Observation. Seems like an Observation without a CybOX payload is
pointless.





Sighting:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw


Looks good to me.




Note that everything in the “cybox” key will be defined by the CybOX
specification. In CybOX, that type is currently defined here:
https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi


If we go with directly embedding CybOX in the STIX Observation, then
that CybOX type definition will have to change. We may do away with
the CybOX Container (née ArgleBargle) altogether but we should still
define in CybOX what are the allowable top-level keys inside of a STIX
Observation's `cybox` field; currently this would be:

 * `objects` => array of type cybox-object (optional)
 * `actions` => array of type cybox-action (optional)

Does everyone agree that what is allowable inside the STIX
Observation's `cybox` field gets defined over in CybOX land?

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925






 

Wunder, John A. wrote this message on Thu, Jun 30, 2016 at 13:13 +0000: > RE: CybOX being optional…the thought was that you might want to say you saw something (e.g. an indicator) 150 times without providing detailed CybOX for what you had actually seen. It was mainly for the sighting use case vs. the observation w/o sighting use case. Except that you can't/don't link an observation to an indicator... If we want to support sighting an indicator 150 times w/o the observation, we should add a count field to sighting.. IMO, we should make cybox required for Observation. -- John-Mark

Well Observations are linked to Indicator via Sighting, which in effect was just a relationship between the indicator and the observation. That’s why we have the array of observation_refs. We could always add count to Sighting as well, but then it would be included twice (on Sighting and on Observation). We would probably also need a start/end time on Sighting in that case to capture the timeframe in which the sightings were seen, which would add more duplication with Observation. The tradeoff seems to me to be whether we have fields that duplicate themselves in some cases (count, start, end on Sighting + Observation) or whether we require people include an observation sometimes just to capture count+start+end. I’ll put together some examples over the next few days to help us decide. John On 6/30/16, 3:47 PM, "cti@lists.oasis-open.org on behalf of John-Mark Gurney" <cti@lists.oasis-open.org on behalf of jmg@newcontext.com> wrote: Wunder, John A. wrote this message on Thu, Jun 30, 2016 at 13:13 +0000: > RE: CybOX being optional…the thought was that you might want to say you saw something (e.g. an indicator) 150 times without providing detailed CybOX for what you had actually seen. It was mainly for the sighting use case vs. the observation w/o sighting use case. Except that you can't/don't link an observation to an indicator... If we want to support sighting an indicator 150 times w/o the observation, we should add a count field to sighting.. IMO, we should make cybox required for Observation. -- 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