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


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


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