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: CybOX Containers in STIX


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



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