Re: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]

> 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, I have asked the same question to myself. I like the “mandatory” default format option as it keeps me from having to debate single format vs multiple format within the group. Personally, I would really enjoy a single format.

  I also ask the group, are there any widely adopted standards that use multiple data exchange formats?

  Aharon
From:  < 
> on behalf of Jason Keirstead
Date:  Wednesday, September 16, 2015 at 8:06 AM
To:  "Grobauer, Bernd"
Cc:  "  ", "  "
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

"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" < 
>
To:
"  " <  >, "  " < 
>
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:
< 
>

  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?