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


Thanks for working with us on this Dave, I definitely appreciate that you’re willing to compromise and help us move forward.

 

We need to figure out what to do for a persistent STIX 2.0 issue tracker to make sure we don’t lose track of the points you’re making below. I think we need to get a new github repo set up in the OASIS namespace and we could use that, or we could use the OASIS JIRA, but for the time being I’ve added them to the old STIXProject specifications tracker and tagged them as something to be migrated.

 

https://github.com/STIXProject/specifications/issues/88

 

John

 

From: Dave Cridland <dave.cridland@surevine.com>
Date: Friday, June 24, 2016 at 2:39 PM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Terry MacDonald <terry.macdonald@cosive.com>, Bret Jordan <bret.jordan@bluecoat.com>
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

 

John,

Reading through these notes, it's clear that the exact idea has been discussed. I'll withdraw my comments, but at the same time toss these (non-blocking) ideas out. If anyone feels they're worth discussing (and haven't been raised previously), great, otherwise please ignore them - don't hold a ballot for the sake of it.

a) It seems that the expectation is that most vocab fields would start out as open, and later be closed if we gain implementation/deployment experience with them. Keeping the two types essentially the same feels like this might smooth the process. (But maybe it's just "hard" anyway).

b) It's not clear that an additional suggested vocabulary item can be added to an open-vocab safely; but given they're entirely unvalidated perhaps this doesn't matter.

Note that both these points aren't relevant to the MVP, per se - they're to do with maintaining interoperability during the evolution of the MVP subsequent to production deployment. Smooth upgrades are always desirable.

Dave.

On 24 Jun 2016 17:55, "Wunder, John A." <jwunder@mitre.org> wrote:

Dave,

 

Sure, it was discussed on a working call. Notes are here: https://www.oasis-open.org/apps/org/workgroup/cti/download.php/58209/OASIS-CTI-TC_WorkingSession_May24_2016.pdf

 

John

 

From: Dave Cridland <dave.cridland@surevine.com>
Date: Thursday, June 23, 2016 at 7:51 PM
To: Bret Jordan <bret.jordan@bluecoat.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Terry MacDonald <terry.macdonald@cosive.com>
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

 

Do you have pointers to these discussions? I'd prefer not to rake over old ground, but I'm finding it difficult to imagine what those arguments could have been.

On 23 Jun 2016 19:31, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

That is what we had before, however, after a lot of debate and discussion, we decided to go this route....  

 

An "open-vocabulary" is just a string field that is somewhat known so it has some suggested values.  You do not need to use the suggested items at all if you do not want to.  More importantly, the field is not used for validation. 

 

A "controlled-vocabulary" is an actual vocabulary where the values are well known or well understood.  This field can be used in validation checks.  The "vocabulary-extension" option is a way to extend this controlled vocabulary to another well known and well defined vocabulary. 

 

So while they both share the term "vocabulary" one is a vocabulary and one is a string field with suggested values. 

 

 

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jun 23, 2016, at 00:46, Dave Cridland <dave.cridland@surevine.com> wrote:

 


On 22 Jun 2016 23:01, "Terry MacDonald" <terry.macdonald@cosive.com> wrote:
>
> For the many various reasons that we've discussed over the past few months, I an fine with both open and closed vocabs.
>

So am I, of course. I'm merely suggesting that the semantics of an open vocab would appear to be better served by the model and syntax of the controlled vocab. The semantics are identical, except you'd get an authority to avoid a collision. Seems win-win to me. What do you think we lose?

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

I think well-known object instances (and identifiers for them) sound like an excellent notion. I lack the domain knowledge about conformance levels here, but I'd note that SHOULD essentially means MUST in all but edge cases. Did you mean that, or did you mean something weaker?

 



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