CybOX Design: Relationships vs. Embedded Objects
One of the biggest existing issues with CybOX that leads to multiple ways of producing semantically identical content is with regards to the inconsistent design around how CybOX Objects are related. What this boils down to that there are two different ways that CybOX Objects can be related - directly inside of another Object, or via an explicit Object Relationship.
To help illustrate, here are examples of existing implementations of each approach:
- Direct embedding: For characterizing the partitions that exist on a disk, the Disk Object imports and uses the Disk Partition Object in its
Partition_Listfield. - Object relationships: Using the Process Object to characterize processes that were spawned by or parents of an existing process, one must an Object Relationship with values of
Child_OfandParent_Of, respectively. There is no field with an embedded Object for this purpose.
As previously mentioned, this inconsistency in CybOX design can lead to cases where two users of CybOX can create semantically identical but syntactically different CybOX content. As an example, let's look at how two users may create valid content for characterizing a particular partition that exists on a disk.
User A chooses to use the embedded Disk Partition Object via the Partition_List field.
<Disk>
<Partition_List>
<Partition>
<Device_Name>Part.1</Device_Name>
</Partition>
</Partition_List>
</Disk>
User B is more familiar with CybOX Object Relationships, and seeing that the Partition_List field is optional, choose to use an Object Relationship (with a "Contains" value), which is completely valid per the CybOX schema.
<Disk>
<Related_Objects>
<Related_Object>
<Properties xsi:type="DiskPartitionObj:DiskPartitionObjectType">
<Device_Name>Part.1</Device_Name>
</Properties>
<Relationship>Contains</Relationship>
</Related_Object>
</Related_Objects>
</Disk>
Given that Object Relationships can be defined for ANY Object, this issue is really scoped around the CybOX Objects that embed other Objects. Accordingly, the diagram below helps illustrate this (as of CybOX v2.1) - each dashed arrow (- - - >) represents an Object that embeds another in one of its fields.
The table below provides more detail about each embedded object:
Given that explicit relationships between CybOX are one of its key components, there are two possible solutions to making their representation and expression more consistent:
- Removing all embedded Objects and allowing for relationship expression solely through Object Relationships.
- A hybrid approach, where a few select Objects are still related by being embedded, while the vast majority are related through explicit Object Relationships.
Our current preference is option 2, the hybrid approach, as we feel that option 1 would make certain common relationships excessively verbose without much benefit in the way of added consistency, and would also make certain objects empty when defined. For instance, imagine needing to relate an IP Address as part of a Socket Address:
{
"objects":[{"id":"object-1",
"type":"IPAddress",
"value":"192.168.0.1"},
{"id":"object-2",
"type":"SocketAddress"}],
"relationships":[{"id":"relationship-1",
"source":"object-2",
"target":"object-1",
"value":"hasAddress"}]
}
The goal of the hybrid approach is to relate CybOX Objects exclusively using Object Relationships, with the exception of a few commonly used/related Objects which will remain embedded. Based on the existing set of embedded Objects, the following rationale would be reasonable:
- Any "atomic" Objects that are currently embedded will remain embedded. These are exclusively networking-related and include the following:
- Address
- URI
- Port
- Socket Address
- Hostname
- Domain Name
- All other Objects (with some exceptions - see below) that are currently embedded would be related through newly defined Object Relationships, and their existing usage and corresponding fields would be deprecated.
- Exceptions/corner cases would include places where the semantics of a relationship would be lost or degraded if defined solely through an Object Relationship. For instance, the Windows Task Object may have multiple task "items", each of which may generate an Email Message. It would be difficult to accurately relate multiple such Email Messages to their corresponding task item(s) without vastly complicating the Object Relationship structure.
- Any new Objects defined in the future will follow this above pattern.
The upside of this approach is two-fold:
- It makes the expression of relationships between Objects much more consistent (one way of doing things)
- It reduces the dependencies in the CybOX Objects, making them easier to manage and update in the future
Accordingly, this would result in the following set of embedded Objects:
We propose the following notional set of Object relationships to replace those expressed via embedded Objects. New relationships (i.e. those not existing in the current ObjectRelationshipVocab) are italicized.
| Parent Object | Embedded Object | Field(s) | Relationship |
|---|---|---|---|
| Disk | Disk Partition | PartitionListType/Partition | Contains |
| DNS Cache | DNS Record | DNSCacheEntryType/DNS_Entry | Contains |
| DNS Query | DNS Record | DNSResourceRecordsType/Resource_Record | N/A - this depends on whether the DNS Query Object will be split up into a Query/Response pairing. |
| Network Connection | HTTP Session | Layer7ConnectionsType/HTTP_Session | Part Of |
| Network Connection | DNS Query | Layer7ConnectionsType/DNS_Query | Part Of |
| Network Route | Network Route Entry | NetworkRouteEntriesType/Network_Route_Entry | Contains |
| Network Subnet | Network Route Entry | RoutesType/Route | Contains |
| Process | Network Connection | NetworkConnectionListType/Network_Connection | Initiated |
| Windows Event | Windows Handle | WindowsEventObjectType/Handle | Referenced By |
| Windows Filemapping | Windows Handle | WindowsFilemappingObjectType/Handle | Referenced By |
| Windows Hook | Windows Handle | WindowsHookObjectType/Handle | Referenced By |
| Windows Hook | Library | WindowsHookObjectType/Hooking_Module | Defined In |
| Windows Mailslot | Windows Handle | WindowsMailslotObjectType/Handle | Referenced By |
| Windows Mutex | Windows Handle | WindowsMutexObjectType/Handle | Referenced By |
| Windows Pipe | Windows Handle | WindowsPipeObjectType/Handle | Referenced By |
| Windows Prefetch | Windows Volume | VolumeType/VolumeItem | Executed From |
| Windows Prefetch | Device | VolumeType/DeviceItem | Executed From |
| Windows Process | Windows Handle | WindowsProcessObjectType/Handle_List | Used |
| Windows Process | Memory | MemorySectionListType/Memory_Section | Used |
| Windows Process | Windows Thread | WindowsProcessObjectType/Thread | Created |
| Windows Registry Key | Windows Handle | WindowsRegistryKeyObjectType/Handle_List | Referenced By |
| Windows Semaphore | Windows Handle | WindowsSemaphoreObjectType/Handle | Referenced By |
| Windows System | Windows Handle | WindowsSystemObjectType/Open_Handle_List | Referenced By |
| Windows Thread | Windows Handle | WindowsThreadObjectType/Handle | Referenced By |
| Windows Waitable Timer | Windows Handle | WindowsWaitableTimerObjectType/Handle | Referenced By |
- This would place an additional burden on the CybOX content producer to understand how to construct relationships
- This could substantially increase the size of the Object Relationship Vocabulary, also placing a burden on the content producer to understand which relationships are valid between which objects. However, this second issue is something that can likely be resolved through proper documentation.