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:
1.11. Report
Type Name: report | Status: Review MVP: Yes |
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
STIX TLO Common Properties |
type, id, created_by_ref, created_time, revision, modified_time, revoked, revision_comment, confidence, object_markings_refs, granular_markings |
Property Name | Type | Description |
type (required) | string | The value of this field MUST be report |
title (required) | string | A name or short description used to identify this Report. |
description (optional) | string | A description that provides the recipient with context about this Report potentially including its purpose and its key characteristics. |
labels (required) | list of typeopen-vocab | This field is an open vocabulary that specifies the intended purposes or uses of this report. This is an open vocabulary and SHOULD contain a value from the report-intent-ov vocabulary. |
published (optional) | timestamp | The date that this report object was officially published. |
published_precision(optional) | timestamp-precision | The precision of the published field. |
report_contains_refs(required) | list of type identifier | Specifies the objects that are in this Report. |
1.11.2. Relationships
There are no uninherited default relationships defined between this object and other objects.
STIX TLO Common Relationships |
duplicate-of, related-to |
1.11.3. Examples
REMOVED DUE TO LENGTH
1.1. Attack Pattern
Type Name: attack-pattern | Status: Review MVP: Yes |
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
STIX TLO Common Properties |
type, id, created_by_ref, revision, created_time, modified_time, revoked, revision_comment, object_markings_refs, granular_markings |
Property Name | Type | Description |
type (required) | string | The value of this field MUST be attack-pattern |
title (required) | string | A name or short description used to identify this Attack Pattern. |
description(optional) | string | A description that provides the recipient with context about this Attack Pattern potentially including its purpose and its key characteristics. |
kill_chain_phases(optional) | list of type kill-chain-phase | The list of kill chain phases for which this attack pattern is used. |
external_references (optional) | list of typeexternal- reference | A list of external-reference objects which refer to non-STIX information. |
1.1.2. Source Relationships
These are the default relationships defined between the Attack Pattern object and other objects.
STIX TLO Common Relationships |
duplicate-of, related-to |
Kind of Relationship | Target | Description |
suggested-coa | course-of-action | Relationship to potential courses of action to prevent or remediate this attack. |
used-against | identity/target | Relates the attack pattern to a target identity if known |
uses-tool | tool, malware | Relates the attack pattern to tools that are used to perform malicious behavior identified in the attack pattern |
involved-in | incident | Relates the attack pattern to an incident occurrence |
1.1.3. Destination Relationships
Kind of Relationship | Source | Description |
indicates | indicator | Relates the indicator to the threat that it indicates. For example, you can send a relationships that points from an Indicator to some Attack Pattern with a value of "indicates". What that means is if you see that indicator it indicates that you might have been attacked by that type of attack pattern to the level of confidence expressed in the relationship. |
evidence-of | observation | Relates the attack pattern to an Observation providing evidence that backs up the assertions provided in this Object. |
uses | campaign | Relates the attack pattern to a Campaign that uses it. |
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
Type Name: campaign | Status: Review MVP: Yes |
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
STIX TLO Common Properties |
type, id, created_by_ref, revision, created_time, modified_time, revoked, revision_comment, object_markings_refs, granular_markings |
Property Name | Type | Description |
type(required) | string | The value of this field MUST be campaign |
title(required) | string | A name or short description used to identify this Campaign. |
description(optional) | string | A description that provides the recipient with context about this Campaign potentially including its purpose and its key characteristics. |
aliases(optional) | list of typestring | Alternative names used to identify this campaign |
motives(optional) | list of typeopen-vocab | The reason, motivation, or purpose this Campaign is being used by a Threat Actor. This is an open vocabulary and SHOULD contain a value from the motivation-ov vocabulary. |
objectives(optional) | list of typestring | The goal or intended effect of this campaign. This will provide greater granularity of the specific objectives. A list is used to clearly delineate multiple objectives. |
severity(reserved) | RESERVED | RESERVED FOR FUTURE USE |
1.2.2. Source Relationships
These are the relationships defined between the Campaign Object and other objects.
STIX TLO Common Relationships |
duplicate-of, related-to |
Kind of Relationship | Target Type | Description |
attributed-to | threat-actor | Relates the Campaign to a Threat Actor that is associated with this Campaign. |
uses | malware, attack-pattern, tool | Relates the Campaign to the malware, tools, and attack patterns that it uses. |
1.2.3. Destination Relationships
These are the relationships defined between other objects and the Campaign Object.
Kind of Relationship | Source Type | Description |
indicates | indicator | If you see a certain Indicator for example, that could indicate/mean that there is a certain Campaign running against you, to the level of confidence expressed in the relationship. |
evidence-of | observation | Relates the Observation to a Campaign providing the evidence that backs up the assertion that this campaign was seen. This observation is evidence of this campaign. |
3.11. Open Vocabulary
Type Name: open-vocab | Status: Review MVP: Yes |
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
Type Name: controlled-vocab | Status: Review MVP: Yes |
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
Type Name: vocab-ext | Status: Review MVP: Yes |
Open Questions:
- Can this just be a simple string field?
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.
Property Name | Type | Description |
value (required) | string | Arbitrary value or value from an alternate vocabulary. |
vocab (optional) | string | Name or location of alternate vocabulary. |
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",
},
...
}
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
Type Name: string | Status: Review MVP: Yes |
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
Type Name: external-reference | Status: Review MVP: Yes |
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
Property Name | Type | Description |
source (required) | string | The source within which the external-reference is defined (system, registry, organization, etc.) |
description (optional) | string | A human readable description |
url (optional) | url | A URL reference to an external resource. |
external_id (optional) | string | An identifier for the external reference content. |
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",
}
]
...
}
An external-reference to Mandiant’s APT1 report document
{
...
"external_references": [
{
"source": "Mandiant",
"description": "APT1 report",
}
]
...
}
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",
}
],
...
}
3.5. Kill Chain Phase
Type Name: kill-chain-phase | Status: Review MVP: Yes |
The kill-chain-phase represents a phase in a kill chain.
Property Name | Type | Description |
kill_chain_name(required) | string | The name of the kill chain. The values in this field SHOULD conform to the style guidelines for string literals [add reference]. |
phase_name(required) | string | The name of the phase in the kill chain. The suggested values for this field SHOULD correspond to the appropriate vocab for phase names for the given kill_chain_name, if one exists, and SHOULD conform to the style guidelines for string literals [add reference]. |
3.5.1. Examples
{
...
"kill_chain_phases": [
{
"kill_chain_name": "kill-chain-foo",
"phase_name": "phase-foo"
}
],
...
}