I'd like to offer a few thoughts, specifically on the TAXII / Message Queueing topic. The short version is that I'd like to make protocol/format decisions later on when we know our requirements better.
Bret and I have been kicking some ideas around with the TAXII Subcommittee, and one compelling option for the future of TAXII is the idea of message queuing. However, discussions have been largely at the application behavior level and not at the protocol/format level beyond saying "XYZ is an option".
My opinion is that most application behavior can be implemented using almost any protocol and format combination [1][2]. The choice tends to be about certain features (e.g., schema validation, as Trey mentions) and scalability/performance/ease-of-use. There is also work to do within the TAXII Subcommittee to determine whether a message queuing type of behavior is indeed the path we want to take - we do not (today) have that consensus in the TAXII Subcommittee.
So I like Trey's suggestions and I think we should be tracking these proposals. At least for TAXII, I'd like to wait on protocol/format discussions until we know a little more about where we want to go and what we want to do.
Thank you.
-Mark
[1]
https://www.ietf.org/rfc/rfc1149.txt[2]
https://en.wikipedia.org/wiki/IP_over_Avian_Carriers-----Original Message-----
From:
cti@lists.oasis-open.org [
mailto:cti@lists.oasis-open.org] On Behalf Of Trey Darley
Sent: Monday, July 27, 2015 11:13 AM
To:
cti@lists.oasis-open.orgSubject: [cti] Regarding Bret Jordan's three proposals
[Proposal - Simplify Data Model]
I wholeheartedly agree that we should simplify the data models and take a hard look at optional versus mandatory fields. Ivan and I listed this as one of our top priorities for CybOX 3.0 and have already been discussing possible approaches.
[Proposal - Single Binding]
I agree up to a point, however I'm remain unconvinced that using JSON for the actual *spec* is workable, given that there's no standard mechanism for expressing a JSON schema.
[#2 Proposal - Change binding to JSON]
As I clearly stated on this list 15 July, neither the decision about changing our data representation/serialization scheme nor the question of moving our transport mechanism (TAXII) from HTTP to a queuing system should be taken in a vacuum. Instead, two small working groups should be established (one for serialization, one for transport). These working groups should be given a short list of candidates, given clear criteria by which to evaluate them, and a reasonably short deadline by which to present the pros and cons of each and make a recommendation to the entire CTI community, which should then be put to an up/down vote.
I motion that the establishment of these two working groups be put to a vote at the next general CTI community call. Furthermore, I suggest that the transport working group examine the advantages and disadvantages of moving to AMQP, 0MQ, or remaining with an HTTP-based transport mechanism. The data representation working group should examine the advantages and disadvantages of JSON, Cap'n Proto, or remaining with an XML-based data structure.
Do not misunderstand me, I am not against making radical changes! To the contrary! But there were reasons why MITRE selected the technical standards they did at the time all this got started, there are advantages and disadvantages to every choice, and we should make the final decision on the basis of *evidence* rather than rhetoric.
I've been watching these recurring debates for a couple of years now. Let's establish these working groups, give them 8 weeks to investigate, take a decision, and move on to more important questions!
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php