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