OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] CybOX Containers in STIX


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]