[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Motion to accept Report, Attack Pattern, Campaign, Controlled Vocabulary, Open Vocabulary, Vocabulary Extension, String, External References, and Kill Chain Phase as Consensus
Wow, that’s a lot! Keep in mind that these approvals only apply to those sections, so approving “External References” just means that the definition for External Reference in the linked
section is good, it doesn’t say anything about how External References are used in TLOs (we’re still discussing that). Similarly, vocabularies like Report Intent are still being defined but we can approve Report without having finished that. Finally, as we
move forward with new relationships, the decision on external references, and other things, the definitions for Report, Attack Pattern, and Campaign TLOs might change. The editors will ensure that if we require any substantive changes we’ll make a new motion
and, when it makes sense, include modifications to existing sections in new motions. With that all said: I move that the STIX SC accept by unanimous consent the
Report, Attack Pattern, Campaign, Controlled Vocabulary, Open Vocabulary, Vocabulary Extension, String, External Reference,
and Kill Chain 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/29, assuming this gets a second
today) we don’t hear any substantive (non-editorial) objections we will move these sections from REVIEW to CONSENSUS status. As usual, 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 the nature of the change. Thanks! John --- Links to live text: Attack Pattern:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.axjijf603msy Open Vocabulary:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.karbmftow040 Controlled Vocabulary:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.p3wopl5f335f
Vocabulary Extension:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.unxln2mb2aza
External Reference:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.cez46v5quobo Kill Chain Phase:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.i4tjv75ce50h
1.11. Report
The report object references a set of TLOs that are related and form a report, like the DBIR or APT1 reports. For example, a threat report by an intel provider discussing the techniques used by a threat actor would be represented with this TLO.
1.11.1. Properties
1.11.2. Relationships There are no uninherited default relationships defined between this object and other objects.
1.11.3. Examples
REMOVED DUE TO LENGTH
1.1. Attack Pattern
Attack pattern is a STIX TLO that captures information about techniques attackers use to carry out attacks. It can describe general attack patterns (e.g., phishing) or specific (e.g., phishing as used by XYZ Campaign). The external_references field MAY be used to provide one or more attack pattern identifiers, such as a CAPEC ID. The source field of the external ID MUST be set to capec when specifying a CAPEC identifier. The external_id field MUST be formatted as CAPEC-[id].
1.1.1. Properties
1.1.2. Source Relationships These are the default relationships defined between the Attack Pattern object and other objects.
1.1.3. Destination Relationships
1.1.4. Examples { "type": "attack-pattern", "id": "attack-pattern--0c7b5b88-8ff7-4a4d-aa9d-feb398cd0061", "revision": 1, "created_time": "2016-05-12T08:17:27.000000Z", "modified_time": "2016-05-12T08:17:27.000000Z", "title": "Spear Phishing", "description": "...", "external_references": [ { "source": "capec", "id": "CAPEC-49"} ] }
1.2. Campaign
The Campaign object is used to describe a pattern of malicious activity by one or more threat actors with a particular intent over a period of time. It may also include a set of incidents, usually occurring over a discrete time frame which have shared properties or objectives. For example, a campaign would be used to describe a banking criminal’s attack against the customers of ACME Bank in the United States in 2015.
1.2.1. Properties
1.2.2. Source Relationships These are the relationships defined between the Campaign Object and other objects.
1.2.3. Destination Relationships These are the relationships defined between other objects and the Campaign Object.
3.11. Open Vocabulary
An open vocabulary is a string field that provides a list of suggested values, without constraining producers from extending those values. The list of suggested values is known as the suggested vocabulary. The value of an open-vocab field MAY be a value from the suggested vocabulary or any other value. Values that are not from the value list SHOULD conform to the naming pattern defined for all literals contained in Section TODO [add reference]: all lowercase, with dashes “-” to separate words.
3.11.1. Examples Example In this example the field indicator labels is an open vocabulary, which means any string value is valid, however, one should use a value from the suggested vocabulary.. { ..., "labels": ["malicious-activity"] ... }
3.12. Controlled Vocabulary
A controlled vocabulary is a string field that defines a list of allowable values; these allowable values are said to be the specified vocabulary. The value of a controlled-vocab field MUST be a value from the specified vocabulary. Controlled vocabulary fields will also have an optional companion “extension” field, of type vocab-ext, that can be used to provide an additional value that is not in the specified vocabulary. The key name for the extension field will be [vocabulary_field_name]_ext. The [vocabulary_field_name]_ext extension field is only intended to provide further specification for the controlled-vocab field in a custom vocabulary and therefore MUST NOT be present unless the controlled-vocab field is also present. In cases where the controlled-vocab field is a list, the [vocabulary_field_name]_ext extension field will also be a list. There is no correspondence between items in these lists: all items in the controlled-vocab field are considered independent from all items in the [vocabulary_field_name]_ext field.
3.12.1. Examples Example – Controlled vocabulary In this example the field cti_type is a controlled vocabulary, which means that only values present in the specified vocabulary are valid. { ... "cti_type": "malware", ... }
3.13. Vocabulary Extension
Open Questions:
Each controlled-vocab field also supports an extension point to support additional or external vocabularies. The key name for the extension point (of vocab-ext type) is [vocabulary_field_name]_ext. Producers MUST populate a value in the main controlled-vocab field when using this extension field. Values in the value field SHOULD conform to the naming pattern defined for all literals contained in Section 2.4.1: all lowercase, with dashes “-” to separate words.
3.13.1. Examples Example – Custom controlled vocabulary with defined vocabulary fallback / default value In this example the field cti_type is a controlled vocabulary; however, it has been overridden through the use of a custom controlled vocabulary, with a fallback / default value from the defined vocabulary. { ..., "cti_type": "malware", "cti_type_ext": { "value": "memory scraping malware", "vocab": "https://stix.oasis.org/vocab-ext/malware-vocab-ext-v1" }, ... } Example – Controlled vocabulary with undefined arbitrary string value but with a defined vocabulary fallback / default value In this example the field cti_type is a controlled vocabulary; however, it has been overridden to allow an arbitrary string value that is not part of the defined vocabulary or any other vocabulary, with a fallback / default value from the defined vocabulary. { ..., "cti_type": "malware", "cti_type_ext": { "value": "memory scraping malware" }, ... }
3.8. String
The
string data type represents arbitrary-length text strings of Unicode characters. The JSON MTI serialization uses the JSON string type, which mandates the UTF-8 encoding to support Unicode.
3.8.1. Examples
{ ... "title": "The Black Vine Cyberespionage Group", ... }
3.2. External Reference
External references are used to describe pointers to information represented outside of STIX. For example, an incident could use an external reference to
indicate an ID for that incident in an external database or a report could use references to represent source material.
3.2.1. Properties
3.2.2. Requirements
·
At least one of
external_id,
url, and
description fields
MUST be present
3.2.3. Examples
A external-reference from the CAPEC repository { ... "external_references": [ { "source": "capec", "external_id": "CAPEC-550" } ] ... } A external-reference from the CAPEC repository with URL { ... "external_references": [ { "source": "capec",
"external_id": "CAPEC-550",
"url": "http://capec.mitre.org/data/definitions/550.html" } ] ... } An external-reference to Mandiant’s APT1 report document { ... "external_references": [ { "source": "Mandiant", "description": "APT1 report",
"url": "http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf" } ] ... } An external-reference to a VERIS entry { ... "external_references": [ { "source": "veris", "external_id": "00C84D6A-CDB8-4A5B-A1A6-0D75A65274D7" } ] ... } An external-reference to a Jira item { ... "external_references": [ { "source": "jira", "external_id": "TAB-1370", "url":
https://issues.oasis-open.org/browse/TAB-1370" } ], ... }
3.5. Kill Chain Phase
The
kill-chain-phase represents a phase in a kill chain.
3.5.1. Examples
{ ... "kill_chain_phases": [ { "kill_chain_name": "kill-chain-foo",
"phase_name": "phase-foo" } ], ... } |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]