[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Motion to accept Bundle, Object Markings, Versioning, and Indicator Labels as Consensus
All, We’ve made a lot of progress recently on finalizing some concepts, and in the absence of any other discussion on them I’d like to move forward. With that in mind… I motion that the STIX SC accept by unanimous consent the
Bundle, Object Markings, Versioning, and Indicator Labels text contained in the STIX pre-draft specifications and duplicated below, and that the SC allow the STIX editors to move these sections to CONSENSUS status. If after a period
of 5 business days (by 6/14) we don’t hear any substantive (non-editorial) objections we will move these sections from REVIEW to CONSENSUS. Feel free to object to any item individually. If we get any objections we can either work through them and make another motion for unanimous consent or we can open a ballot, depending
on the type of discussion and nature of the change. Also, note that for the “Bundle” approval our intent is to keep the list of TLOs in that property list up to date. So as, for example, we figure out how to represent malware/malicious-tool we will keep bundle
up to date with that current list of TLOs. Links to live text: Indicator Label:
https://docs.google.com/document/d/13TuudUtGur9d68VewJW2t_mdEWkpdorNMZDZHCeqAEU/edit#heading=h.a50wvo4z81ef
Versioning:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.rye5q2hkacu (and the version, created_time, modified_time, revoked, and version_comment fields in the TLO Common Properties section) Object Markings:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.f3dx2rhc3vl (and the object_marking_refs field in the TLO Common Properties section) Thanks everyone, John ---
1.6. Indicator Label
This is part of an open vocabulary and the following table contains the suggested values for the label field on the Indicator TLO.
5.1. Bundle
A
bundle is a wrapper object used to group a collection of TLOs together to enable them to be transported
within or outside of a TAXII connection. A bundle is not a standard TLO itself and is only used
to group STIX objects for transportation. It can be thought of as an envelope, enabling the delivery of the objects it contains. It does not have any of the TLO properties other than the
type,
id, and
spec_version fields and should not be treated as a persistent object.
5.1.1. Properties
5.1.2. Relationships
NONE. This object is not a TLO and cannot have any relationships to it or from it.
5.1.3. Examples
{ "type": "bundle", "spec_version": "2.0”, "indicators": [ { "type": "indicator", "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f", "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff", "created_time": "2016-04-29T14:09:00.123456Z", "revision": 1, "modified_time: "2016-04-29T14:09:00.123456Z", "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779123"], "title": "Poison Ivy Malware", "description": "This file is part of Poison Ivy", "pattern": "file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3'" } ], "marking_definitions": [ { "type": "marking-definition", "id": "marking-definition--089a6ecb-cc15-43cc-9494-767639779123", "created_time": "2016-02-19T09:11:01Z", "definition_type": "tlp", "definition": { "tlp": "GREEN" } } ] }
6.4. Versioning
STIX content is versioned using the
version,
version_comment,
revoked,
created_time, and
modified_time properties. See the properties table in section
TODO [add reference] for full definitions and normative usage of the individual properties; this section describes the broader
versioning process and normative rules for performing versioning and revocation. STIX objects can be versioned in order to update, add, or remove information. All STIX representations of objects are actually representations of a version
of that object, identified in the version field. Higher values in the
version field indicate later versions of the object. STIX Objects have a single object creator: only the entity
that generates the id for the object and creates the first version is permitted to create subsequent versions.
Only the object creator (the entity that generated the id field of the object) is permitted to create new versions
of a STIX object. Producers other than the object creator MUST NOT create new versions of that object. Individual versions of STIX Objects are immutable: representations of a given version of an object (identified by the object's
id and its
version)
MUST, in all representations, always have the same set of properties and the same values for each property. In order to change the value of any property, or to add or remove properties, the
version number
MUST be increased to indicate a new version. Objects can also be revoked, which is an indication that they are no longer considered worthwhile intelligence. As with issuing a new version, only the
object creator (the entity that generated the id field of the object) is permitted to create new versions of a
STIX object). A value of true in the
revoked field indicates that an object has been revoked. Revocation is permanent: once an object is marked as revoked,
later versions of that object MUST NOT be created. The change to the revoked field to indicate that an object is revoked is an update to object, and therefore the revoked object
MUST have an updated version and
modified_time.
6.4.1. Versioning Timestamps
Non-Normative Section There are two timestamps used to indicate when STIX Objects were created and modified:
created_time and
modified_time. The
created_time field indicates the time the first version of the object was created. The
modified_time field indicates the time the current version of the object (indicated by the value of the
version field) was created. For both
created_time and
modified_time, object creators may use any time that best represents when they want to say the object was created
and modified. Some creators might use the time the representation was created in their own database; other creators might use the time the object was first shared externally, and others might use a user-tunable value.
6.4.2. New Version or New Object?
Non-Normative Section Eventually an implementation will encounter a case where a decision must be made regarding whether a change is a version of an existing object or is different
enough that it is a new object. This is generally considered a data quality problem and therefore this specification does not provide any normative text. However, to assist implementers and promote consistency across implementations, some rules of thumb are provided. Any time a change indicates a
material change to the meaning of the object (say, a different malware or a different actor), a new object with a different
id should be used. The creator should also think about references to the object when deciding if a change is material.
If the change would invalidate the references to the object, then the change is material and a new object
id should be used.
6.4.3. Examples
Examples cut to keep this e-mail focused on normative text, see document. Excerpt from TLO Common Properties of properties relevant to versioning:
6.5. Object-Level Markings
Data markings provide the ability for producers to convey to consumers how they
may use and share the marked data that they receive. Object-level data markings define how markings are applied to TLOs. Object-level markings are contained in the
object_marking_refs field, which is an optional list of ID references (of type
identifier) that resolve to objects of type
marking-definition. The markings referenced by the
object_marking_refs field and defined in the
marking-definition object apply to that TLO and all of its fields. If an ID reference to a
marking-definition is unable to be resolved, consumers processing that TLO
MUST reject it.
6.5.1. Precedence
Within the
object_marking_refs
list, markings
of the same type that appear later in the list override markings appearing earlier in the list. Markings of different types do not override each other. For example, a TLP marking appearing at position 3 in the list overrides a TLP marking appearing at
position 2, but not a copyright marking appearing at position 1. The marking definition extensions, which define how data is marked using a particular approach (e.g., TLP), define the behavior when one marking overrides
another.
6.5.2. Interoperability
Producers
MAY create object-level data markings. Producers MUST ensure that all markings they do create comply with the functional and data marking requirements defined in this document. Consumers
MUST be aware of object-level data markings contained in the object_marking_refs field. Consumers that are
unable to comply with the object-level data markings rules defined in this section
MUST reject all TLOs that contain the object_marking_refs field.
6.5.3. Examples
This example marks the indicator with the marking definition referenced by the ID. { ... "type": "indicator", "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235", "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779123"], ... } Excerpt from TLO Common Properties of properties relevant to object markings:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]