RE: Proposal for simple CybOX objects

["Kemp, David P" <dpkemp@nsa.gov>]

That is not a good analogy.

STIX and TAXII have references that can be used to create mesh graphs, where paths through the graph are unbounded.  With two exceptions (file and process), CybOX references are all terminals with a maximum depth of 1 or 2.
The longest possible reference chain or embedding depth is 2: network-connection -> ipv4-address -> mac-address.
All other objects that contain references (windows-registry-key, ipv4/6-address, and email-message) have a max depth of 1.   The attached spreadsheet illustrates CybOX objects and their relationships.

A CybOX ipv4-address-object could be constructed without using either references or embedding by defining an optional mac_address property instead of referencing/embedding mac-address-object.   There can be no philosophical objection to a mac_address property; it has the same effect on graph traversal as the value property containing the IP address.   This is the identical approach taken in artifact-object - it has a url property instead of either embedding or referencing url-object.  My position is that embedding a mac-address-object is equivalent to using a mac_address property - it has no effect on graph traversal.

I have withdrawn my suggestion that CybOX have a blanket approach to embedding vs. referencing.  References are entirely appropriate for file and process objects.

But I still suggest that references be replaced with embeddings (or direct-value properties) in:
 * windows-registry-key-object,
 * ipv4-address-object,
 * ipv6-address-object, and
 * network-connection-object.

Dave


-----Original Message-----
From: Mates, Jeffrey CIV DC3\DCCI [mailto:Jeffrey.Mates@dc3.mil]
Sent: Wednesday, August 17, 2016 4:12 PM
To: Kemp, David P <dpkemp@nsa.gov>; 'Kirillov, Ivan A.' <ikirillov@mitre.org>; cti-cybox@lists.oasis-open.org
Subject: RE: Proposal for simple CybOX objects

STIX, CybOX and TAXII are all closely related.  As such any system that supported TAXII style queries must necessarily store data in a manner that follows the data structures found in the other two formats.  In STIX 1 this meant allowing arbitrary access to every amount of depth in your structure, which was painful to say the least even more so when combined with some of the structural components of a query.

In STIX 1 a TAXII query took into account the structure of the STIX document so the query could ask for all elements with a Description field that were of type Indicator.  They could also ask for all Files with the MD5 X that were part of an Indicator that was also part of a larger Indicator.  Since I haven't seen the proposed query specifications for TAXII 2 my assumption is that it will be similar or possibly support the patterning syntax found in STIX, which also would be affected by a nested CybOX structure.

All of this leads me to be strongly opposed to nesting in addition to the goal of having one way to do things to preserve consistency.

Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335

Attachment: cybox3-references.xlsx
Description: cybox3-references.xlsx