-
Notifications
You must be signed in to change notification settings - Fork 7
CTI Consensus Items
This was discussed at the face to face and subsequently achieved good consensus. A complete writeup is available in the CTI Common Pre-Draft Specification, but the agreed-upon format is:
[construct-type]--[UUIDv4]
IDs were also made required for all top-level objects.
The discrete timestamp format will be RFC3339 where the timezone specification is required and the timezone MUST be UTC. A precision field will accompany many timestamp fields that will indicate whether the precision is second, minute, hour, day, month, year. A complete writeup is available in the CTI Common Pre-Draft Specification.
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.
As a sub-issue, one of the fields that was agreed to is External_IDs, which is a list of identifiers to the content in external resources.
A proposed set of fields is available in the CTI Common Pre-Draft Specification.
Relationships will be split out of the other top-level objects and will become a new top-level object. Relationships would default to being open such that any IDable construct could be related to any other IDable construct. This was discussed at the face to face, encountered no objections, and has had no objections since.
The full writeup and a proposed set of fields is available in the CTI Common Pre-Draft Specification.
At the face to face there was consensus that general relationships (with no additional properties beyond standard relationships) would not be subclassed. There was agreement, though not a full definition, that relationships with additional properties would also not be subclassed and would use extended properties as originally outlined by the CybOX co-chairs for object properties.
In other words, the type field of a relationship will always be "relationship". If certain relationship types (e.g. affected assets, or COA taken) require additional properties they will do that via an extended properties section that has not been fully defined.
The full writeup and a proposed set of fields is available in the CTI Common Pre-Draft Specification.
At the face to face, there was general consensus that an is_directional flag on relationships was important. There was also a note that this flag may be hardcoded by certain relationship values ("indicated-ttp" is always uni-directional). It was also agreed that the field should be required.
[JW: I have heard from one person that they have questions about this field and, in particular, whether it should be required.]
There's also still the major open issue of defining all of the relationships, though that's up to the individual STIX/CybOX SCs.
This field is a part of the relationship object in the CTI Common Pre-Draft Specification.
A simpler approach to controlled vocabularies was proposed and generally accepted at the face to face. Each vocabulary will be "open" or "closed".
For "closed" vocabularies, the default field (e.g. "status") will be restricted to a default vocabulary. An additional "extension" field (e.g. "status_ext") will allow for the use of custom vocabularies or single custom values.
For "open" vocabularies, the default field will be an unrestricted string allowing single custom values. Those using custom vocabularies will use the "extension" field as they do for closed vocabularies.
This writeup will be included in the CTI Common Pre-Draft Specification.
A two-tier approach for applying data markings has been discussed on the list and has tentative agreement. The tiers are: tier one, which supports marking at the object and package level; tier two, which supports marking at the field level via JSONPath.
The major remaining item is to develop a reference implementation for data markings, in particular tier two.
A complete writeup is available in the [CTI Common Pre-Draft Specification](https://docs.google.com/document/d/1FM-ojdKeaC-3mhf2v1FfXY0Q-s0uCiSDG80tDh23k3E/edit).
At the face-to-face there was a brief discussion of separating out the information source from each of the top-level objects so it can easily be referenced. This was agreed upon and there have been no objections.
It still remains to be decided how top-level objects will reference information sources. One proposal (twigs, separate proposal not created yet) has that happening via an embedded created_by_ref field, another (proposed by Sean) has it done by a top-level relationship. This topic has not been discussed.
The fields present on Source are also yet to be discussed and agreed upon (though obviously would include identity fields).
At the face to face, it was agreed that with the move to top-level relationships the report object should have the object lists removed and become simple metadata (title, description). Other top-level objects would be placed "in" the report via relationships.
In STIX 1.2, all top-level objects had a Short_Description field. There was general consensus at the face to face that this should be removed, with no objections since then.
This will be reflected in the STIX Pre-Draft Specification.
In STIX 1.x, all top-level objects extended from an "empty" base type. This was done to reduce coupling and promote extensibility. At the face to face, this issue was briefly discussed and the consensus was that they should be removed. Each top-level object will be defined as a single concrete implementation.
This will be reflected in the STIX Pre-Draft Specification.
TTP as an independent top-level object will be deprecated and split into its various pieces, each of which represents a type of TTP and will become a new top-level object derived from a common abstract base type (to enable relationships to any type of TTP). These may inherit a core set of TTP properties, though that has not been discussed. The new objects are: malware, attack pattern, exploit, victim targeting, malicious_infrastructure, persona, and malicious_tool.
This was agreed to at the face to face and has not been challenged. It will be reflected in the STIX Pre-Draft Specification.
Like TTP, Exploit Target as an independent top-level object will be deprecated and split into its various pieces, each of which represents a type of Exploit Target and will become a new top-level object derived from a common abstract base type (to enable relationships to any type of Exploit Target). These may inherit a core set of Exploit Target properties, though that has not been discussed. The new objects are: configuration, vulnerability, and weakness.
This was agreed to at the face to face and has not been challenged. It will be reflected in the STIX Pre-Draft Specification.
List container types in the data model and XML serialization will be removed. The JSON MTI format will use arrays.
This was agreed to at the face to face and there have not been further objections. It will be reflected in the STIX Pre-Draft Specification.
In CybOX 2.x, objects properties used types defined as data type-specific constraints on string in order to support patterning. At the face to face, it was proposed and generally agreed upon that with the splitting of patterns out of instances these pattern-focused string types would be removed. It still remains to be discussed what sort of primitive types will be leveraged for object properties and how they will be defined.
There is consensus on splitting up the existing Object into multiple "atomic" Objects. At the face-to-face, we also discussed the required use of CIDR notation for IP addresses and decided to ease the restriction for non-range specifications; accordingly, single IP addresses are also allowed to be specified (with implicit /32 or /128 CIDR blocks).
As discussed at the face-to-face, we seemed to reach consensus on the approach of using extensions versus subclasses in structuring the CybOX Object hierarchy. However, there are still some open questions, such as how we should handle extensions that may overlap in their properties (if this is a likelihood).
There is consensus on the overall approach of having a File Object with a "base" set of properties and then various context-specific extensions. At the face-to-face, we also briefly discussed the concept of merging other "file-like" Objects into the File, such as the Socket and Pipe, but the consensus seemed to be that this wasn't critical for the 3.0 release and something we should consider at a later date.