Active Issue: IDable Construct Properties

Consensus

There is general agreement that top-level objects across CTI (STIX and CybOX) should extend from a common base class (have a common set of properties). This was agreed to at the face to face and has not been challenged. Discussion still remains to reach consensus on the common set of properties that should be on this common base class and what they should be named.

Consensus Properties

Property Name	Type	Description
id (required)	IDFormat	A globally unique identifier for this object
type (required)	String	The type of construct being represented. This is a fixed value for each top-level object, formatted as all lowercase with ‘-’ as a separator (e.g. attack-pattern). This is a serialization-based field and derives from the type of the construct in the model.
marking_refs (optional)	Array	The set of “Level 1” markings (see STIX specification) applied to this object.
structured_markings (optional)	Array	The set of “Level 2” markings (see STIX specification) applied to this object.
----controlled_structures (required)	Array	A list of path selection statements (e.g. JSONPath), rooted at the top-level object that structured_markings is contained in, that the marking_refs apply to.
----marking_refs (required)	Array	The list of markings that apply to the fields selected by controlled_structures.
external_ids (optional)	Array	A list of IDs from external contexts/systems
----id (required)	IDFormat	The external ID itself
----url (optional)	URL	A link to the construct in the external context/system.

Non-consensus Properties

Property Name	Type	Description	Consensus gap
language_version	VersionEnum	The release version of the language used to represent this construct	Their is not yet consensus on whether this property should be here.
created_at (required)	Timestamp	The time that the object with this ID was created	Specific name of property field
created_by_ref (optional)	String	The ID of the Identity Object that describes who created this Object. Please note this is not who produced the analysis of information referred to contained within the Object, but who actually created the Object itself.	Open question of whether this should be embedded here as an exception to the "one way of doing things" for relationships or if it should be captured as separate relationship
revision (optional - although required in some circumstances)	Integer	This field is ONLY used if the object is a revision of an original object. The original version of the object is not allowed to contain a revision field.	Open question that must be resolved by full discussion and consensus on the broader topic of Versioning
revoked (optional)	Boolean	This field identifies that all versions of the Object identified by the id field are ‘revoked’ and should be considered invalid. Only the producer of the information can revoke the object. The revoked field MUST only be used when a producer wishes to revoke some information they have shared previously. The revoked field MUST be accompanied by a revision field indicating this as the newest version. A revoked object cannot be ‘unprovoked’.	Open question that must be resolved by full discussion and consensus on the broader topic of Versioning
marking_definitions (optional)	Array	An array of 1 or more marking definitions. Each definition contains two fields used to apply markings (id and marking_type) and additional fields to define the marking itself.	Open question whether this property only exists on Package or on any IDable construct
----id (required)	IDFormat	A globally unique identifier for this marking definition.	Open question whether this property only exists on Package or on any IDable construct
----type (required)	data-marking	The type of construct this is.	Open question whether this property only exists on Package or on any IDable construct
----marking_type (required)	String	The type of marking this represents.	Open question whether this property only exists on Package or on any IDable construct
----(other fields to represent marking data)	Various	Used to represent the marking itself.	Open question whether this property only exists on Package or on any IDable construct
----marking_refs (required)	Array	The list of markings that apply to the fields selected by controlled_structures.
external_ids (optional)	Array	A list of IDs from external contexts/systems	The below sub-property is the only non-consensus item for external_ids
----source_tool_ref (optional)	String	An embedded reference to a Tool Object identifier for the system that the external ID is defined in.	It is an open question exactly what this property needs to be able to refer to: organization? context? tool?

Proposal #1 (Sean)

• “language_version” : I propose that this property should be on all IDable constructs to ensure that consumers know how to interpret it. It is very possible that a given Package could contain mixed-version content of either STIX or CybOX.
• “created_at” : I am fine with “created_at” property name
• “created_by_ref”: I do not agree that this property should be present. See Active Issue: Relating Source
• “revision” : I do not believe this field should be considered until the issue of Versioning has been fully discussed.
• “revoked” : I do not believe this field should be considered until the issue of Versioning has been fully discussed.
• “marking_definitions” : I believe that this property (and its sub-properties) must be present at both the Package and other IDable construct levels to support practical use of content where IDable construct instances may move about between Packages.
• “external_ids”/“source_tool_ref” : I do not agree that IDs are always defined within a system context. Sometimes they might be from a system but other times may be from an organization or a registry context (e.g. CVE, OSVDB, CWE, etc.). I propose that a more general property name such as “defining_context” makes much more sense.
  • Example:
    • “external_ids” : [{“id”: “CVE-2014-0160”, “defining_context”: “cve”, “url”: "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160”}]
    • “external_ids” : [{“id”: “2015051100987”, “defining_context”: “ACME Incident Tracker”}]

Proposal #2 (John)

• language_version : I would not include this. If we include it in STIX, it should be at the package level...mixing versions of STIX in the same package seems awful to me. Debatably, it could just be removed from STIX and represented by the transport, though I'm not really sure on that one.
• created_at : Only question I have here is...what is it used for, and do we need "modified_at"? If we can not include it, let's not include it.
• created_by_ref: Per the source proposal, I feel this is necessary to say who created this STIX construct.
• revision : Discuss when we discuss versioning.
• revoked : Discuss when we discuss versioning.
• marking_definitions : I don't think we need to have marking definitions at both the package level and the object level. If you need to mark an object you should send it in a package. If you want to move it around, move the marking definitions around with it. This type of duplication should be avoided.
• external_ids/source_tool_ref : My proposal on this is actually totally different. I think we should rename external_ids to references. It would be used to represent any other representation of this construct: paper PDFs information was pulled from, the construct in an external system, etc. Each reference would consist of:
  • type: The type of reference. Either: "external-representation" or "derived-source".
  • created_by_ref: Pointing to the identity of the source for this reference
  • url (optional, unless name is omitted): URL for the reference
  • name (optional, unless url is omitted): Name of the reference.

It would essentially be a bibliography.