[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Motion to accept Report, Attack Pattern, Campaign, Controlled Vocabulary, Open Vocabulary, Vocabulary Extension, String, External References, and Kill Chain Phase as Consensus
Allan, Thanks for your comments! It’s great having you reading over these. Changes we made are below. In terms of moving forward: let’s talk through the open topics, and I would encourage everyone to review this list to make sure you’re OK with the changes. If we’re able to resolve these
by tomorrow though I think it’s fair to keep moving forward with the motions. Allan if you want to have a call tomorrow that would work for me, or we could just do it over e-mail/slack. Also, I wanted to point out that the relationships in these sections are going to be pretty fluid as we define new objects and add relationships based on them. Going forward, I’d like to
consider relationships out of scope for these approvals and just focus on the definitions and property tables. Then, when we finish the TLOs, we can go through and make sure the relationships are correct, complete, and consistent all at once. John Attack Pattern -
Removed relationships that were to/from other TLOs that aren’t MVP=YES w/ definitions (ACCEPTED) -
Corrected a relationship verb from “uses-tool” to “uses” since it pointed to both tool and malware (ACCEPTED) -
Corrected language in the attack-pattern relationships (ACCEPTED IN PRINCIPLE – used different language, but still clarified it) -
Rejected change to campaign relationship that was correct as-is. It was in destination relationships, so campaign “uses” attack-pattern is correct. (REJECTED) Campaign -
Responded to one comment, on Campaign Aliases. (OPEN) Report -
Replied to comment on report with a suggestion (ACCEPTED IN PRINCIPLE - OPEN) -
Suggestion to make labels optional was accepted. Previously was required. (ACCEPTED) External References -
Accepted a comment that we should add a reference to a specification for URLs (ACCEPTED) Kill Chain -
Open comment on the design pattern for lower-case-dash (OPEN) String -
Editorial change to refer to string as “a string” rather than “an arbitrary-length string” (ACCEPTED) Vocab Ext -
Removed an extraneous open question (not based on comment, just something we noticed) From:
Allan Thomson <athomson@lookingglasscyber.com> John – I have reviewed the documents and added comments/suggestions to the documents. However, I would suggest moving forward with these objects provided that the comments are addressed. From a process perspective I’m not sure if that means consent or not but I generally
agree to move forward. allan From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> 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]