CybOX Common Refactoring for Consistency

[ikiril01]

CybOX Common currently defines the following:

• The abstract base type for defined CybOX Objects (ObjectPropertiesType)
• Types that are used exclusively in CybOX Core (e.g., MeasureSourceType)
• Types that specify base datatypes (e.g., StringObjectPropertyType) for Object properties
• Types for context-specific properties (e.g., Layer4ProtocolType, SIDType) of specific Objects
• Relatively generic types used across multiple Objects (e.g., HashType)

Therefore, it's not clear what CybOX Common is truly "common" to, making it so that CybOX Common and Core seemingly serve similar purposes, especially since Core imports many components of Common. Accordingly, it may make sense to merge Common into Core, for the purpose of simplicity and to make maintenance easier.

[sbarnum]

I would not agree that Common and Core serve similar purposes.

Core specifies the core structure classes/types for CybOX (around Observables, Events, Actions, Objects and how they interrelate). This is specifically separated from the Object property specifications for appropriate modularity.

Common specifies the set of common classes/types that are used across the core structures and/or across multiple Object property specifications.

If you are specifying a set of Object properties you will want to include a set of common types within your scope but really do not need the core language structure classes/types at all.

This separation seems very logical to me and I would suggest that throwing Core and Common together would actually make maintenance harder rather than easier.

[jonathanbaker]

What is the benefit for the specification, UML model, and json representation?

Remember this resource on XML Schema: http://www.xfront.com/ZeroOneOrManyNamespaces.html

If we were to redo the XML schemas for CybOX down the road, i could see using the Chameleon Namespace Design for the types defined in common. I think that this would reduce namespace clutter and still give us all the benefits of having a collection of types that can be used across schemas.

[ikiril01]

All good points!

At least at a high level, my view is that both CybOX Core and Common define types used in CybOX instances, and both have always been revved and versioned together (effectively serving as one schema). Accordingly, merging them will have the following benefits:

• The dependency on CybOX Common from CybOX Core will be removed, leaving only a single CybOX Core schema. This is beneficial from a maintenance standpoint, in that any revisions will be done to CybOX Core, and we don't need to worry about revving CybOX Core only because one of the types it pulls in from CybOX Common was updated.
• Any additions of new types will be done only in CybOX Core (no need to determine whether it belongs in CybOX Common).

To provide some more context from my perspective, I think a large part of this issue stems from the diverse range of types found in CybOX Common, some which are "common" to various parts of CybOX. I've updated the title accordingly.

Anyhow, I think CybOX Common currently defines the following:

• The abstract base type for defined CybOX Objects (ObjectPropertiesType)
• Types that are used exclusively in CybOX Core (e.g., MeasureSourceType)
• Types that specify base datatypes (e.g., StringObjectPropertyType) for Object properties
• Types for context-specific properties (e.g., Layer4ProtocolType, SIDType) of specific Objects
• Relatively generic types used across multiple Objects (e.g., HashType)

Given this, it's hard to see any consistent pattern in the types of structures defined in CybOX Common, so it begs the question as what it's truly "common" to. If wanted to keep this granular approach, I think it would make the most sense to move any types that are used exclusively in CybOX Core there, and then break up Common into the following:

• Objects common - the types that are common to all Objects
• Context-specific common - one for each class of Objects as necessary, e.g., NetworkArtifactCommon, DiskArtifactCommon, WindowsArtifactCommon, etc.

My concern with this approach is that it adds extra schemas and extra dependencies that may make it more difficult to rev and manage CybOX components in the future. For example, an Object may now have a dependency on Objects Common and multiple context-specific Commons. However, it may be useful to have this granularity in terms of adding and managing classes of Objects, as changes shouldn't need to be made to Core and Objects Common.

[ikiril01]

To @jonathanbaker's point, perhaps the organization of these types is a moot point, as our next serialization (for CybOX 3.0) is going to be JSON/JSON Schema, which fundamentally uses a "chameleon-like" approach (with no namespaces). That is, any defined JSON object can be pulled in and used from a JSON schema file as necessary [1].

[1] http://spacetelescope.github.io/understanding-json-schema/structuring.html#reuse