← Prev in month
← Prev in thread
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 Bundle: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 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 Type Name: indicator-label-ov Status: Review MVP : Yes This is part of an open vocabulary and the following table contains the suggested values for the label field on the Indicator TLO. Label Value Description anomalous-activity Indicator describes unexpected, or unusual activity that may not necessarily be malicious or indicate compromise. This may include reconnaissance like behavior such as port scans or version identification, network behaviour anomalies, and asset and/or user behavioural anomalies. anonymization Indicator describes suspected anonymization tools or infrastructure (proxy, TOR, VPN, etc.). benign Indicator describes activity that is not suspicious or malicious in and of itself, but when combined with other activity may indicate suspicious or malicious behavior. compromised Indicator describes assets that are suspected to be compromised. malicious-activity Indicator describes patterns of suspected malicious objects and/or activity. attribution Indicator describes patterns of behavior that indicate attribution to a particular threat actor or campaign. ?5.1.? Bundle Type Name: bundle Status: Review MVP : Yes 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 Property Name Type Description type (required) string Indicates that this object is a STIX Bundle. The value of this field MUST be bundle id (required) identifier An identifier for this bundle. The id field for the bundle is designed to help tools that may need it for processing, but tools are not required to store or track it. Consuming tools should not rely on the presence of this field. spec_version (required) spec-version-enum The release version of the language specification used to represent this construct attack_patterns (optional) list of type attack-pattern Specifies a set of one or more Attack Patterns. campaigns (optional) list of type campaign Specifies a set of one or more Campaigns. courses_of_action (optional) list of type course-of-action Specifies a set of one or more Courses of Action that could be taken in regard to one of more cyber threats . identities (optional) list of type identity Specifies a set of one or more identities of individuals or organizations. indicators (optional) list of type indicator Specifies a set of one or more cyber threat Indicators. malware (optional) list of type malware Specifies a set of one or more Malware TTPs. marking_definitions (optional) list of type marking-definition Specifies a set of one or more Marking Definitions. observations (optional) list of type observation Specifies a set of one or more cyber observations. relationships (optional) list of type relationship Specifies a set of one or more relationships between TLOs. reports (optional) list of type report Specifies a set of one or more reports. sightings (optional) list of type sighting Specifies a set of one or more sightings. threat_actors (optional) list of type threat-actor Specifies a set of one or more Threat Actors. ?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 Status: Review MVP : Yes 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: version (required) number The version property indicates the version of this object. This field’s value MUST be an integer (whole number) greater than or equal to 1 and less than or equal to 999,999,999. Higher numbers indicate later versions of the object. Object creators MUST increase the revision number ( SHOULD increment it by exactly 1) when creating a new version of an object. created_time (required) timestamp The created_time property represents the time at which the first version of this object was created. The object creator SHOULD use the time it deems most appropriate as the time the object was created. The created_time property SHOULD be the same across all versions of the object unless the created_time was corrected by some version. modified_time (required) timestamp The modified_time property represents the time that this particular version of the object was created. The object creator SHOULD use the time it deems most appropriate as the time this version of the object was created. The modified_time for a given object version MUST be greater than or equal to the created_time . revoked (optional) boolean The revoked property indicates whether the object series has been revoked. Revoked objects are no longer considered worthwhile intelligence. Revoking an object is permanent; future versions of the object with this id MUST NOT be created. version_comment (optional) string A comment outlining why the new version of this object was created. 6.5.? Object-Level Markings Status: Review MVP : Yes 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: object_marking_refs (optional) list of type identifier The list of data-marking objects to be applied to this object.
← Prev in month
← Prev in thread