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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Conformance Section


There was prior discussion on this and want to highlight this again here in very general terms. I don’t know that we ever reached consensus. 

 

I argue that we should not require a STIX or TAXII conformant product to support any functionality beyond its targeted use case/purpose.  Some standards handle this via Profiles, for example OASIS KMIP:

 

 

https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/58866/kmip-spec-v1.3-cs01.html

 

https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/58867/kmip-profiles-v1.3-cs01.html

 

 

2      Profiles

This document defines a list of KMIP Profiles. A profile may be standalone or may be specified in terms of changes relative to another profile. 

2.1 Profile Requirements

The following items SHALL be addressed by each profile.

1.     Specify the versions of the KMIP specification (protocol versions) that SHALL be supported

2.     Specify the list of objects that SHALL be supported

3.     Specify the list of Authentication Suites that SHALL be supported

4.     Specify the list of Attributes that SHALL be supported

5.     Specify the list of Operations that SHALL be supported

6.     Specify any additional message content that SHALL be supported

7.     Specify any other requirements that SHALL be supported

8.     For profiles other than the Baseline Client, Baseline Server and Complete Server the profile SHALL specify the mandatory test cases that SHALL be supported and MAY specify the optional test cases that MAY be supported by conforming implementations

2.2 Guidelines for other Profiles

Any vendor or organization, such as other standards bodies, MAY create a KMIP Profile and publish it.

1.     The profile SHALL be publicly available.

2.     The KMIP Technical Committee SHALL be formally advised of the availability of the profile and the location of the published profile.

3.     The profile SHALL meet all the requirements of section 2.1

4.     The KMIP Technical Committee SHOULD review the profile prior to publication.

 

 

Patrick Maroney

Office:  (856)983-0001

Cell:      (609)841-5104

 

 

President

Integrated Networking Technologies, Inc.

PO Box 569

Marlton, NJ 08053

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Friday, October 7, 2016 at 3:45 PM
To: John Wunder <jwunder@mitre.org>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Conformance Section

 

I like being it being explicit, as one of the big problems with reading things such as the old set of TAXII documents was the fact you had to move around on the document to find the complete set of things you needed to know about a single topic.

I prefer the idea of listing the objects and making it harder on us (the tc) rather than every one who reads the document.

Cheers
Terry MacDonald
Cosive

 

On 8 Oct. 2016 8:31 am, "Wunder, John A." <jwunder@mitre.org> wrote:

It’s just being explicit about defining names and granularity for features so you don’t have to interpret it from the document structure, which isn’t always intuitive. For example, it might not be clear to people that it’s meaningful to only support Object Markings and not Granular Markings (because they’re both in one Data Markings section, just like Bundle).

 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, October 7, 2016 at 3:10 PM
To: John Wunder <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Conformance Section

 

I just don't understand why we can't just eliminate the "Optional Features" section, and instead make these changes to the conformance clauses:

    1. It MUST support all features listed in Section 8.2, Mandatory Features.
    2. It MAY support any features described by this specification features listed in Section 8.3, Optional Features. Software supporting an optional feature MUST comply with the normative requirements of that feature.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


active hide details for "Wunder, John A." ---10/07/2016 03:35:15 PM---Ye"Wunder, John A." ---10/07/2016 03:35:15 PM---Yeah that’s probably a question I should have raised: what features are we missing? Right now we cov

From: "Wunder, John A." <jwunder@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 10/07/2016 03:35 PM
Subject: Re: [cti] Conformance Section
Sent by: <cti@lists.oasis-open.org>





Yeah that’s probably a question I should have raised: what features are we missing? Right now we cover:

- Markings (Object + Granular)
- Versioning
- All Objects / Relationships (via the conformance in Part 2)

o By extension, Patterning, which is required as part of Indicator (if you do Indicator, you have to do patterning)
o By extension, CybOX, which is required as part of Observed Data (if you do Observed Data, you need to do CybOX)
o By extension, types and vocabs due to normative statements in the objects that use them


Things we might be missing:

- Custom Properties / Custom Objects: We initially had this but removed it because we felt that there were no additional normative statements beyond those to conform to the types (i.e. from the STIX Producer and Consumer requirements). But maybe it should be added back as a Mandatory feature?
- Bundle: probably need to add this one now that I think about it. We could add it as an optional feature similar to Data Markings.
- What else?


John

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date:
Friday, October 7, 2016 at 2:17 PM
To:
John Wunder <jwunder@mitre.org>
Cc:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
Re: [cti] Conformance Section


OK RE #1 and #2

I am still confused on the mandatory vs. optional features section, because there are features that don't exist in either, which seem like they are in some form of conformance limbo?

IE - the wording around conformance states that IF you implement things listed as optional, you MUST follow the spec. OK... but, what if I implement something that is in the spec, but not listed as optional OR mandatory? Do I have to follow the spec then?

--
Sent from my mobile device, please excuse any typos.

Wunder, John A. --- Re: [cti] Conformance Section ---

From:

"Wunder, John A." <jwunder@mitre.org>

To:

"Jason Keirstead" <Jason.Keirstead@ca.ibm.com>

Cc:

cti@lists.oasis-open.org

Date:

Fri, Oct 7, 2016 2:17 PM

Subject:

Re: [cti] Conformance Section




Thanks for the review. In order:

- Good call, I fixed this. Should have referred to section 8.x.
- One problem we ran into is that it’s hard to define what it means to “consume” STIX. Some tools will consume it and stick it in a database, others will match indicators against log data, others might implement COAs or perform some analytics. Where we landed was that the conformance section should use the lowest common denominator, which is “not barf”. So, to answer your question, yes.
- The Optional Features section is there so we have named conformance terms for those features. Basically, it gives us a formal way of saying that you do “Object-Level Data Markings” in a way that you can’t if you just have it as a section in the document. Any cross-cutting feature that we support should have a conformance clause.


John

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date:
Friday, October 7, 2016 at 12:28 PM
To:
John Wunder <jwunder@mitre.org>
Cc:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
Re: [cti] Conformance Section

I have some questions on the clauses.

- Section 8, Producer, 5/6 - These refer to sections 10.2 and 10.3, that don't exist in the document.

- Section 8, Consumer, 1 - "
It MUST support parsing all required properties for the content that it consumes.". I am not sure what "parsing" means WRT conformance. I can parse a property in code, and throw it away - does that comply?

- Section 8.2 / 8.3 - Shouldn't the union of Mandatory features and Optional features comprise the entirety of features in the document? If not - why do we need an "optional features" section? Isn't anything that is not mandatory, optional by definition?



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


tive hide details for "Wunder, John A." ---10/07/2016 12:56:02 PM---Al"Wunder, John A." ---10/07/2016 12:56:02 PM---All, I got Allan, Mark, Bret, and Rich P. and we came up with another revision. I’m feeling pretty c

From:
"Wunder, John A." <jwunder@mitre.org>
To:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:
10/07/2016 12:56 PM
Subject:
Re: [cti] Conformance Section
Sent by:
<cti@lists.oasis-open.org>






All,


I got Allan, Mark, Bret, and Rich P. and we came up with another revision. I’m feeling pretty comfortable with the text so have pasted it into the RC3 documents. You can find it:


Part 1 (STIX Core) Conformance:
https://docs.google.com/document/d/1IcA5KhglNdyX3tO17bBluC5nqSf70M5qgK9nuAoYJgw/edit#heading=h.swto78n8l9sp
Part 2 (STIX Object) Conformance:
https://docs.google.com/document/d/1S5XhY6F5OT599b0OuHtUf8IBzFvNY8RysFHIj93DgsY/edit#heading=h.dnm4ez5y24uh

Please review and provide comments.


Jason, John-Mark…each individual document will need a conformance section, including Patterning. You guys might start thinking about how you want to draft conformance for patterning. I would take a look at we did for the two sections above and base something on that…our goal was to keep it fairly simple and lightweight and then rely on interop to build on top of that.


John


From:
<cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date:
Monday, October 3, 2016 at 2:30 PM
To:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
Re: [cti] Conformance Section


I added this text to the Playground so we can edit it:
https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.a4woj6cyyw4r

Please review and provide suggestions. Note that the ANY/ALL question is still open.


John


From:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date:
Monday, October 3, 2016 at 10:13 AM
To:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
[cti] Conformance Section


Hey everyone,


One of the major sections we need to finish before we move forward with 2.0 is the conformance section of the document. The conformance section describes what it means to be conformant with STIX and what terms you should use to describe those products.


To frame things a bit, an example conformance section from ebXML is attached. As you can see, they dictate what sections you need to conform to to be called a registry, a registry client, etc.


For us, the equivalent to those categories seems to be “STIX Producer” and “STIX Consumer”. Additionally, we’ll have tools that implement different sets of STIX objects (some tools will only do indicators, others will do some set of things, others will do everything). That to me suggests some kind of matrix:

- STIX Producer, STIX Consumer, or both
-
Which STIX objects you support


So you’d end up with some text like this:


---------------------------------

A producer is any tool that creates STIX content. An implementation is a conformant producer if it meets the following conditions:
1.
The content it creates is encoded as JSON and is conformant with the property tables and normative requirements within those tables for the content it creates
2.
Any STIX content it creates conforms to all applicable normative requirements in the sections for the content it creates

A consumer is any tool that receives STIX content for any purpose. An implementation is a conformant consumer if it meets the following conditions:

1.
It supports consuming data markings by conforming to all normative requirements in the data markings section
2.
It supports consuming versioned content by conforming to all normative requirements in the versioning section
3.
It supports consuming custom content by conforming to all normative requirements in the “customizing STIX” section (TODO: maybe not necessary, consumers are allowed to either ignore or throw an error if they get properties with custom content)

A producer or consumer may additionally claim conformance with one or more STIX Objects. Implementations may do so if:

1.
They support all normative requirements in the corresponding section
2.
If a producer, the objects of that type they create are conformant with the property table in that section (though they may contain custom properties per the normative requirements of that section).

A “STIX Producer” is any tool that can produce ____________ (TODO, see below)
A “STIX Consumer” is any tool that can consume ____________ (TODO, see below)

---------------------------------

One option is that to be called a “STIX Producer” you need to be able to create ALL objects defined in STIX. Tools that were not able to create all objects would just be called producers of those objects, but not STIX producers.


The other option is that to be called a “STIX Producer” you just need to be able to create SOME objects defined in STIX. Tools that create any STIX objects can be called STIX producers, and we could name another class (“Full STIX Producer”) for tools that create all objects, or just not give it a name.


We would also be allowed to create other classes…for example, STIX Indicator Sharing Producers might be required to produce indicators, relationships, sightings, and observed data. I would probably lean towards not doing that just yet though…can always be added in 2.1+ as we learn more.


So, a couple questions for everyone:

1. Does the rough direction I’ve outlined above make sense? Do you have any other ideas?
2.
Do you think we should make “STIX Producer/Consumer” mean a tool that creates/consumes ALL STIX objects, or a tool that creates/consumes SOME STIX objects?


Thanks,
John










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