They can do that be referencing the Observations or other TLOs in STIX if they so desire.
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I 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,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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]
|