Re: [cti] Regarding Bret Jordan's three proposals

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

JSON-Schema is in the IETF draft stage (draft 4). I presume it will eventually become an RFC, but is not one yet.

-
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


"Jordan, Bret" ---2015/07/27 04:09:57 PM---And here are the specs: http://json-schema.org/latest/json-schema-core.html <http://json-schema.org/

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Aharon Chernin <achernin@soltra.com>
Cc: "Davidson II, Mark S" <mdavidson@MITRE.ORG>, Trey Darley <trey@soltra.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/07/27 04:09 PM
Subject: Re: [cti] Regarding Bret Jordan's three proposals
Sent by: <cti@lists.oasis-open.org>

---

And here are the specs:

http://json-schema.org/latest/json-schema-core.html

http://json-schema.org/latest/json-schema-validation.html



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 Jul 27, 2015, at 13:08, Bret Jordan <bret.jordan@bluecoat.com> wrote:

This is what we are using for JSON TAXII today, http://json-schema.org/

I think Intelworks is using for their JSON based STIX too.


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 Jul 27, 2015, at 13:01, Aharon Chernin <achernin@soltra.com> wrote:

Is there an international standards way to perform JSON validation yet?

Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | achernin@soltra.com
www.soltra.com




---


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Monday, July 27, 2015 2:44 PM
To: Davidson II, Mark S
Cc: Trey Darley; cti@lists.oasis-open.org
Subject: Re: [cti] Regarding Bret Jordan's three proposals

I agree with this in regards to TAXII.. Also keep in mind that TAXII needs to be able to carry CTI other than just STIX, CybOX, and MAEC... I personally would like to see Facebook use TAXII to send their CTI... :)

For STIX, CybOX, and MAEC, serialization is very important and needs to be addressed soon... The requirements I give to this effort, basically the show-stoppers are:

1) It must be efficient in storage and on the wire

2) It must be easy to implement and understand in various languages, meaning there must be good solid support in C, C++, Objective-C, Python, Java, Android-JAVA, Ruby, PHP, _javascript_, Go, etc, etc

3) It must work really well on handhelds. Meaning, it has to be CPU and battery friendly for Android and iOS.

4) It must be friendly for the average web developer / app developer

5) Serialization must be fast or fast-enough and should be able to scale to a Billion pieces of CTI a day.



Options for serialization:

1) Do nothing. I personally think this is a bad idea and might just be the leak that sinks the ship.

2) Stip all of the name space cruft out of XML and really simplify it down, make it more JSON like.

3) JSON

4) Binary
4a) ProtoBuf
4b) Cap-n-Proto


JSON does have a good schema validation system.. We are using it today with JSON based 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 Jul 27, 2015, at 12:02, Davidson II, Mark S <mdavidson@MITRE.ORG> wrote:

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.org
Subject: [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

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]