STIX 2.0 Proposal1 : Extend core constructs from a single base class (#148) - STIXProject/specifications GitHub Wiki

Issue Summary

Currently all core "IDable" constructs (often referred to as "top-level objects" in STIX are defined separately with each one redefining the same set of basic shared properties. This leads to unnecessary complexity, parsing uncertainty and maintainability issues.

Proposed Solution

Define a new single base class for core "IDable" constructs specifying the set of shared properties and have each core "IDable" construct class be defined as an extension from the base class.

This lends simplicity and maintainability to the data model but would not be visible in serialized instance content other than all such constructs consistently sharing the same base properties. This should also make parsing such structures much more straightforward as you always know what to expect.

Set of shared properties

  • Id
  • Timestamp
  • Language_Version
  • Revision
  • External_IDs
  • Marking_Definitions
  • Marking_Refs
  • Structured_Markings

List of properties explicitly not shared on the base class

  • Idref (this solution presumes that issue #201 will be resolved to deprecate embedded nesting of IDable constructs within each other thus eliminating the need for the idref property)
  • Title and Description (not applicable to all IDable constructs and so will be captured in a DescribableProperties class that describable constructs will derive from in addition to from the IDableConstruct class.
  • Confidence (not applicable to all IDable constructs and so will be added only to those appropriate)
  • Information_Source (presumes that issue #233 will be resolved to abstract Source to its own IDable construct level, that issue #291 will be resolved to abstract relationships to their own IDable construct level and that issue #201 will be resolved to deprecate embedded nesting of IDable constructs within each other. Thus information source for each IDable construct will be asserted via a relationship to a Source instance rather than as a direct property of the IDable construct.)

List of core "IDable" constructs

The below list presumes that issue #386 will be resolved to remove the abstract base types for current "top-level" objects obviating them being included in this list.

(bold entries are currently existing "IDable constructs"; italic entries are new "IDable constructs" depending on acceptance of other issue proposals)

CybOX IDable constructs as envisioned by applying this set of proposals to CybOX for 3.0 (this list is not asserted as complete):

  • Package
  • Observation
  • Event
  • Action
  • Object
  • Relationship (and a set of sub-class relationships)
  • Location

Actions:

  • Create a new IDableConstruct class in stixCommon with properties for the shared properties listed above
  • Create new VersionType enumeration in stixCommon with a single literal of "stix-2.0"
  • Modify each IDableConstruct class (e.g. Indicator) identified above by making them specializations of the IDableConstruct class or contextual specialization thereof (e.g. Identity) and removing any property definitions that are redundant with the shared properties defined on the IDableConstruct class

Significantly simplifies the model, yields much greater consistency and removes a TON of redundant property specifications.

Proposed Model

IDableConstruct class with shared properties

Set of IDable constructs and their specialization/inheritance chains

Examples

Example #1: simple TTP

Example #2: simple indicator

Example #3: simple Related_TTP relationship from the Indicator to the TTP

JSON Schema Serialization snippets

Example #1: simple TTP

{
	"id": "example:ttp-6796e1db-a84d-4017-87d5-cdebfe4303be",
	"type": "malware-instance",
	"timestamp": { "value" : "2015-12-21T19:59:11.000000+00:00" },
	"title": "Sakurel Malware"
}

Example #2: simple Indicator

{
	"id": "example:ind-b8e37090-5d62-45a1-ac2e-a88601b08432",
	"type": "indicator",
	"timestamp": { "value" : "2015-12-21T19:59:11.000000+00:00" },
	"title": "Sakurel Malware",
	"indicator_expression": "this would be an observable pattern for a particular file hash using the new CybOX patterning language under consideration",
	"indicator_type": [
		{
			"value": "File Hash Watchlist",
			"vocab": "indicator-type-vocab-1.1"			
		}
	]
}

Example #3: simple Related_TTP relationship from the Indicator to the TTP

{
	"id": "example:rel-fd81e9fb-5c3b-4922-9307-dd226079c00f",
	"type": "related-ttp",
	"timestamp": { "value" : "2015-12-21T19:59:12.000000+00:00" },
	"confidence": {
		"value": {
			"value": "High",
			"vocab": "high-medium-low-vocab-1.0"
		}
	},
	"from" : "example:ind-b8e37090-5d62-45a1-ac2e-a88601b08432",
	"to": "example:ttp-6796e1db-a84d-4017-87d5-cdebfe4303be",
	"relationship_nature": {
		"value": "Indicated TTP"
	}
}

JSON Serialization example snippets

Open Questions

  • Should Timestamp be required?
  • Should Language_Version be required?
  • Should data markings be applicable for all IDable constructs or only at STIX "top-level" core constructs (Indicator, TTP, etc.)?