Can you speak to what you see as the current obstacles for supporting JSON as a complete binding? Is it the security marking etc?
From: <[hidden email]> on behalf of "Jordan, Bret"
Date: Thursday, August 20, 2015 at 3:30 PM
To: "[hidden email]", "[hidden email]"
Subject: EXTERNAL: [cti-users] Re: [STIX] STIX in JSON
Great question Chris, and very timely.
As many of you know, I have been beating the drum for JSON support for a long time, nearly 18 months now. I seem to get several private emails a week from the community asking about it. Even Facebook is using JSON for their ThreatExchange platform.
Where we stand today, to the best of my knowledge is:
1) STIX 1.2.1 will be ratified with OASIS using the current XML binding as the only reference implementation. However, the STIX team as always maintained that you can do your own reference implementation. And to that end several companies and groups have done just that.
2) There is support in the current Python APIs for a to_dict() to make it JSON. I believe Soltra is using this on the back side as they store their STIX data in JSON format. However, this to_dict() it is not a standardized form of JSON. It was just put together by the developer of the API and some of the constructs are more XMLized JSON.
3) Several vendors and startups are doing their own STIX based JSON implementations for all of the reasons I have brought up in the past. Intelworks is one of the few that have made public announcements about it. The rest are still not public and thus I can not speak about them.
4) JSON based TAXII is done and the specification can be found here . I worked on this specification with lots of people and it has gone through several revisions in the TAXII community. I even have fully working APIs for JSON based TAXII.
5) I am hoping that for STIX 2.0, we can have an official JSON binding for STIX that everyone can use. But in the mean time, I would contact Intelworks and do what they are doing. My project, FreeSTIX  is going to follow what Intelworks has done.
Everyone in this community that would like to see a JSON based STIX implementation should speak up.
From a JSON standpoint it is not really that difficult to make the conversion, especially on the STIX side of the house, I have done it and others have done it. JSON even supports schema validation for those interested in that (schema validation works today for JSON TAXII). CybOX will be a bit harder to do, but with the clean up and simplification that Ivan and Trey are working on, this should be possible as well. Imagine how much easier CybOX would be to deal with in JSON... :)
The only other problem I see is with the way data markings are currently done. However, you could argue that this problem exists outside of JSON and that XPath is nearly impossible to work with in code. To solve this problem I have proposed that we look at making data markings a top level object that can just be referenced by the elements that need it. This should solve the 95% use case. For the rest, those with very elaborate data markings, we will need to make sure they are taken care of.
I believe that adopting JSON will lower the cost of entry for vendors, product managers, and developers to the point where we will get across the chasm and go mainstream with STIX. From what I heard at RSA and Blackhat as I walked the floor and talked with vendors (CEOs, CVOs, CTOs) is that, "if we only had JSON support we would be more willing to adopt STIX".
I envision a day when there are hundreds or thousands of apps on the various APP stores that support cyber threat intelligence and at least 15-20 new startups all dealing with CTI and my "SoC of the future". I think we can make it happen. We just need to lower the cost of entry and give the product managers and developers what they want, which is clear when they tell me "can I have anything but XML".
So I push for JSON.
signature.asc (859 bytes) Download Attachment
I have to second this statement: "that XPath is nearly impossible to work with in code". We are using Java which has fantastic Xml support but combining JAXB and xpaths has been tedious.
I think that having XPath within the data is one of the oddities of the model that binds it to an XML implementation. Json has an equivalent of json path in some tools but using the concept of path within the model when everything else in the STIX model uses references. I think the easiest implementation would be to just remove the Controlled_Structure element all together. Let it apply to the node it belongs to (package, report, or indicator).
BrightPoint Security, formerly Vorstack
On Thu, Aug 20, 2015 at 4:14 PM, Jordan, Bret <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|