OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[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


I wanted to talk process-wise about these two comments.

 

I’ll treat them both as objections to unanimous consent. So, unless the objections are withdrawn, that means that controlled-vocab, vocab-ext, open-vocab, and attack-pattern have all failed unanimous consent. So for each of those topics, as well as any future topics, as a community we need to decide whether to have a further discussion and potentially make a change (accept the comment) or whether to have a ballot to accept the section as-is. Please give it some thought and let the list know what you think. Keep in mind our timeline: if we want to make July MVP we need to keep moving and probably need to decide within the next few days.

 

John

 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, June 22, 2016 at 6:40 PM
To: Terry MacDonald <terry.macdonald@cosive.com>, Dave Cridland <dave.cridland@surevine.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
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

 

Unless CAPEC becomes part of the OASIS group of standards and everyone endorses CAPEC’s use in the standard, I’m not sure how we can make it a SHOULD. That also implies that interoperability will test the should condition and we cant mandate that.

 

Suggest we stick with may.

 

allan

 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, June 22, 2016 at 3:01 PM
To: Dave Cridland <dave.cridland@surevine.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>
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

 

For the many various reasons that we've discussed over the past few months, I an fine with both open and closed vocabs.

I am wondering if we should change the MAY in the CAPEC section of the attack pattern object into a SHOULD. I'm just worried that if we don't have a 'standard' vocab for the attack pattern  external references then it will be more difficult to match things.

It would be amazing if the CAPEC team could create a STIX attack pattern object for each CAPEC entry.... then we'd each use the same object. Is it worth us talking to the CAPEC team.

Cheers
Terry MacDonald
Cosive

On 23/06/2016 3:24 AM, "Dave Cridland" <dave.cridland@surevine.com> wrote:

Comments inline

 

On 22 June 2016 at 15:54, Wunder, John A. <jwunder@mitre.org> wrote:

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.

 

 

I think Vocabulary could be improved.

 

1) The relationship between "Controlled Vocabulary", "Open Vocabulary", and "Vocabulary Extension" confuses me a little bit. I'm not sure we need, or should have, all three.

 

2) You almost certainly don't mean "lowercase".

 

Expanding these:

 

(1)

 

"Open Vocabulary" has a Suggested Vocabulary, but you can use any value that's a legal "literal". Aside from "literal" meaning, to me, an arbitrary string, this seems reasonable so far.

 

"Controlled Vocabulary" has a Specified Vocabulary, so one MUST pick one of those. But, all Controlled Vocabularies have a extension field to contain other values.

 

On the face of it, a controlled-vocab and an open-vocab are identical, except that open-vocab's extension is via arbitrary and uncontrolled random identifiers which may clash, and controlled-vocab has a mandatory extension which can only *further* specify a vocabulary element.

 

Thus if open-vocab didn't exist, we could replace all instances of it with a controlled-vocab where the Specified Vocabulary included a reserved value "other", allowing the only specification to be within a vocab-ext instead. The vocab-ext type is namespaced, so won't clash.

 

Summary:

 

I think open-vocab is surplus to requirements, and removing it would make Open Vocabularies more safely extended.

 

(2)

 

I'm really hoping that Section TODO doesn't merely say "all lowercase with dashes to seperate words". The term "lowercase" is meaningless in some scripts, and I've a feeling it varies depending on locale in some cases. I suspect you may mean "ASCII lowercase letters and dash". You may wish to include ASCII digits there. In Section TODO it ought to enumerate the codepoint ranges in full.

 

The rest of these look fine.

 

​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.

--

Dave Cridland

phone  +448454681066

skype  dave.cridland.surevine

age removed by sender. Surevine

Participate | Collaborate | Innovate

Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND

If you think you have received this message in error, please notify us.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]