Re: [cti] CybOX Containers in STIX

["Wunder, John A." <jwunder@mitre.org>]

Yeah agreed, I had a side channel with Trey and we talked about how more examples/workflows would be really helpful. I can take some time today or tomorrow and put some together, this would be a great topic to have settled soon.

 

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 30, 2016 at 9:47 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX

 

And we should carefully go through the workflows for these to make sure they do in fact work as we think we need them to work.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director 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." 

 

On Jun 30, 2016, at 07:13, Wunder, John A. <jwunder@mitre.org> wrote:

 

RE: CybOX being optional…the thought was that you might want to say you saw something (e.g. an indicator) 150 times without providing detailed CybOX for what you had actually seen. It was mainly for the sighting use case vs. the observation w/o sighting use case.

I’ve noticed that our design approach for Observation/Sighting makes things consistent across like 4 different use cases, but the tradeoff is that when you look at it for any single one of those use cases it might appear to have some extra fields or weird features. IMO it’s probably a good thing (they all seem like important use cases) but it does mean we need to explain how it should work very well in documentation.

John

On 6/30/16, 3:52 AM, "Trey Darley" <trey@kingfisherops.com> wrote:

On 29.06.2016 15:25:59, Wunder, John A. wrote:

Observation: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj

Please remind me why the `cybox` field is optional on a STIX
Observation. Seems like an Observation without a CybOX payload is
pointless.

Sighting: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw

Looks good to me.

Note that everything in the “cybox” key will be defined by the CybOX
specification. In CybOX, that type is currently defined here:
https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi

If we go with directly embedding CybOX in the STIX Observation, then
that CybOX type definition will have to change. We may do away with
the CybOX Container (née ArgleBargle) altogether but we should still
define in CybOX what are the allowable top-level keys inside of a STIX
Observation's `cybox` field; currently this would be:

 * `objects` => array of type cybox-object (optional)
 * `actions` => array of type cybox-action (optional)

Does everyone agree that what is allowable inside the STIX
Observation's `cybox` field gets defined over in CybOX land?

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