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] Thoughts on STIX and some of the other threads on this list [formats discussion]


RE Schema, JSON Schema exists and is codified in an IETF draft RFC - http://json-schema.org/.

RE Automated Tooling - as I stated previously in this discussion - I myself do not have much faith in the output of any automated tooling from a high level model into a language binding that would be of sane enough quality that it could be codified as a standard.

Such generated bindings are always fraught with problems, because it is extremely difficult, in fact close to impossible, to define a high level model that can seamlessly translate between different data interchange formats, unless you either (a) don't care at all what that binding looks like, or (b) purposely curate your high level model so that the binding output looks proper in your MTI implementation... in which case, you are not really making a true high level model at all and are instead just using it as an instruction set for a code generator.

This is the root problem with this approach of using a high level model to make an MTI binding, instead of simply codifying "one true format". Its making a lot of extra work for what I see as little real gain in practice (are any vendors going to ever actually implement any of these other bindings? Very unlikely in my opinion.)

I've never seen a widely implemented RFC that had multiple different types of possible bindings in it (XML, JSON, other) for a data interchange format standard. Is there an example of this? I'd like to see how it was approached.

-
Jason Keirstead
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


Inactive hide details for "Grobauer, Bernd" ---2015/09/16 06:42:05 AM---Hi, here is a little picture that captures some of the "Grobauer, Bernd" ---2015/09/16 06:42:05 AM---Hi, here is a little picture that captures some of the concepts contained in John's email

From: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com>
To: "jwunder@mitre.org" <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/09/16 06:42 AM
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]
Sent by: <cti@lists.oasis-open.org>





Hi,

here is a little picture that captures some of the concepts contained in John's email
(I have added something I call 'translations' to the picture, because I think we may need them):




The questions below have been touched upon here and there in various emails on the various lists:
I feel it is important to restate them in a structured way, so that we consider them all when choosing
HLM and MTI binding:


1) What is our requirement on how the 'derive from' relation comes about?
Do we require an automated or semi-automated
process? We are talking about very sizable models, so a completely manual process will pose some challenges.


My current feeling is that if no HLM-MTI-pair with an at least semi-automated process can be found, then the
nature of the HLM is documentation rather than 'ground truth' and we should think twice about spending
effort for a HLM which we then transform by hand into a binding. Without an HLM, the MTI-binding
would have to serve as HLM, as is the case with XSD in the pre-OASIS MITRE standards.


2) What is our requirement on how the MTI binding is actually defined?
I would argue that some kind of schema definition is required and "definition by code" is not sufficient.

So, with XML we have XSD. It seems there are schema-definition schemes for JSON, but I do not
know how powerful/stable/universally-accepted these are, nor what the status regarding item 3) below is.


3) How much automated support for deriving an API for the MTI binding do we require?
Obviously, we need APIs to produce/consume content in the binding(s). Especially for the MTI,
we should think about how much automated support we require for producing an API for a given binding.

Currently, MITRE's STIX/CybOX APIs are based on automated mechanisms that turn XSDs into
Python code for parsing and generating XML conforming to the XSD. Given the size of the models
we are contemplating, writing an API from scratch might be quite a bit of effort.


4) What are our requirements regarding translations between the MTI binding and alternative bindings?

Without some kind of executable translation between two bindings, there is a danger that
the standard becomes fragmented, because a system supporting one binding may not be able
to interpret data that is available in some other binding.


Of course, this problem could be solved "by policy", stating that each OASIS-CTI-compatible system
must support the MTI binding (thus forcing the implementors who work with an alternative binding
to also implement a translation fromt/to the MTI), but the danger remains that we suddenly
have systems that exclusively speak an alternative binding. So maybe there should be a requirement
that an "official" alternative binding must be supported by a reference implementation that translates from/to

that binding into the MTI binding?






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