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]


I would love all three to use the same format.  I think that would be super neat.  Especially if it was JSON. :) :) :) :)  .  I just do not want to artificially limit the protocol based on needs higher up the application stack.  

For the record, I see the TAXII APIs decompressing and de-encapsulating the "data" and handing it off to a STIX / CybOX application further up the stack.  Now I know we are not building an MTA, but if you think about TAXII in the terms of the way Postfix was built an architected by IBM, I see a lot of really neat parallels for TAXII.  


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 Sep 15, 2015, at 11:35, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:

Aharon – I think that John was indeed suggesting that this discussion be done at the CTI level, rather than in the subcommittees :)

I do completely agree that STIX and CybOX should have the same MTI on account of CybOX being a major dependency for STIX. As far as TAXII, it does seem reasonable that it could have its own set of requirements that drive the selection of a particular MTI that differs from that of CybOX and STIX. However, if this were to happen, and given that TAXII will still likely be used as a transport for STIX-packaged data, it seems like it would force TAXII users to have the ability to parse/generate two different formats. My view is that this seems like it could be a tough selling point and has the potential to drive away adoption; instead, we should look at the requirements of STIX, CybOX and TAXII as a whole selecting an MTI and choose a format that best meets them, while recognizing that a one-size-fits-all solution is unlikely and compromises will need to be made.

-Ivan

From: <cti@lists.oasis-open.org> on behalf of Aharon Chernin
Date: Tuesday, September 15, 2015 at 1:01 PM
To: John Wunder, "cti@lists.oasis-open.org"
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]

John, I agree with your points. I also agree that all CTI standards should have the same default binding. Given that, shouldn’t we have these discussions in the main CTI group vs our individual sub committees? 

Aharon

From: <cti@lists.oasis-open.org> on behalf of "Wunder, John A."
Date: Tuesday, September 15, 2015 at 12:02 PM
To: "cti@lists.oasis-open.org"
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]

Hi everyone,

In an effort to come to some agreement on this topic and move forward I attempted to summarize a bunch of points that I think I saw general agreement on. I ran these points by a bunch of my MITRE co-workers (Sean Barnum, Mark Davidson, John Wunder, Ivan Kirillov, and Jon Baker) and they all agreed both with the points themselves and that there was general (not complete) agreement on the points.
 
1. It makes sense to have a single binding specification be “mandatory to implement” (MTI).
2. We should allow for the development of any number of other binding specifications that the community would find useful given sufficient interest.
3. All of these binding specifications will be driven off of a single high-level model.
4. Both the high-level model and each binding specification should be formalized as CTI work products.
5. The python-* APIs developed by DHS/MITRE would only support the MTI binding specification. Obviously, support for other bindings (or alternative versions of the MTI format bindings) could be developed by others.
6. We need more discussion over what the MTI format should be. There’s a lot of support for JSON but we haven’t seen a lot of concrete discussion of requirements and trade-offs.
7. We should start the work to identify the single MTI format now in order to get some informal consensus soon so that going forward we can focus our efforts on improving the data model.
8. All of these agreements that we reach on format in the near-term are informal and if a substantive requirement is identified later in the data modeling work (or even outside of that) that changes the analysis we can revisit the decision.

There wasn't a lot of list discussion on this, but in my opinion in order to ensure best compatibility among the OASIS CTI specs the MTI format should be consistent across STIX, CybOX, and TAXII.
 
So my proposal is that over the next few weeks, let’s have an in-depth discussion at the TC level about what the single MTI format should be. We can talk about our requirements and why we prefer one or the other, discuss the trade-offs of each, put together some examples, and hopefully hear from some more people. Once we have rough consensus (note: not complete agreement), we’ll document the entire discussion (requirements, trade-offs, examples, final decision) on the wiki and move on. If the topic comes up again, we refer people to the wiki. Once the time comes to formalize the MTI decision (ie. we’re preparing a release of STIX, TAXII, and/or CybOX) we review the analysis to see if it’s still valid against our updated requirements and, if so, go with that. If not, revisit it with those new improved requirements in mind.

As many people have said, format is not the most pressing topic we have to deal with. This path will allow us to get some closure on it near-term and move on to the more important work of improving the model.

What do you think?

John

=== snipped a massive amount of previous discussion about format(s) ===

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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