Skip to content

STIX 2.0 Proposal7 : Make Observable structure align with other components (#160)

sbarnum edited this page Dec 23, 2015 · 3 revisions

Issue Summary

The Observable "top-level" construct is unique in that it is based directly on a CybOX type rather than a STIX native type like the other "top-level" constructs. This means that it lacks many of the key properties common to other "top-level" constructs which enable things like versioning.

Proposed

Have Observables implemented as a STIX-native type derived from IDableConstructType.

  • Create new "observable" package/namespace
  • Create new cyboxObservationType class in "observable" package/namespace as specialization of both IDableConstructType and CYBOX:cybox_core:ObservableType. Once CybOX is refactored to utilize IDableConstructType as a common basis for its IDable constructs the specialization relationship between IDableConstructType and cyboxObservationType can be removed as the IDableConstructType properties will then derive from CYBOX:cybox_core:ObservableType.

Proposed Model

Examples

Example #1: simple observation of a file with a particular hash

JSON Serialization example snippets

Example #1:

The below example snippet envisions numerous refactoring changes to CybOX similar to and driven by the set of proposals in the STIX 2.0 Round 1 Strawman (e.g. deriving form IDableConstruct, relationships as separate objects, no embedding of IDable content). Actual details of how this will end up in CybOX will be decided as these issues are taken up within the CybOX SC

{
	"id": "example:obj-fa7de07b-ee02-4773-8cac-fa7161a7f998",
	"type": "file-object-observation",
	"timestamp": { "value" : "2015-12-21T22:45:12.000000+00:00" },
	"title": "Suspicious File",
	"hashes": [
		{
			"type": "md5",
			"hash_value": "3773a88f65a5e780c8dff9cdc3a056f3",
		}
	]
}

JSON Schema Serialization snippets

Open Questions

Clone this wiki locally