OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

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


Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)


These are great questions!

How will the JSON (or RDF) serialization work with the XML-based extensions we use now?
How will JSON (and RDF) handle digital signatures?

In terms of time to produce the schemas, it took me about an hour to put together the examples (schema + content) that I posted a few days ago. They were against a small part of STIX. I would estimate it’s like 60 hours to produce the STIX/CybOX schemas plus (since this is a manual mapping) 60 hours to review. Assuming we develop an RDF-based high-level model you could almost certainly automate that, though. And of course if you go with RDF serialization this process is essentially free.

John

> On Oct 9, 2015, at 12:21 PM, Jerome Athias <athiasjerome@GMAIL.COM> wrote:
> 
> do someone could provide a cost/time estimation regarding the
> translation of STIX (and the other used schemas, including extensions,
> e.g. CybOX, MAEC, or CVE, CAPEC, CIQ...) into JSON schemas?
> would JSON could easily transport XML chunks?
> 
> is there a JSON mechanism to cover a requirement related to
> signature/encryption for data objects somehow like XMLDSIG/XAdES?
> 
> 2015-10-09 18:58 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>:
>> There needs to be one and only one on-the-wire serialization for the default
>> case which is probably 90+% maybe as high as 95+% of the market.  There will
>> also need to be an option for an additional on-the-wire serialization to
>> support super high bandwidth conditions where something like Protobuf or
>> Cap-n-Proto would be the logical choice.  If we do NOT have a default
>> serialization that everyone can just use and it just works (think DLNA for
>> security tools) then all of this is for not and we might as well go back to
>> our day jobs.
>> 
>> To be clear:
>> 
>> 1) We need a high level format like UML to represent the data model.  I
>> personally like UML as it is something that data modelers can live with and
>> developers / implementers can still use and understand.  It also does not
>> require massively expensive modeling tools to look at or understand.
>> 
>> 2) We need a very expressive and yet intuitive data model that is easy to
>> understand but allows rich documentation of threats, their relationships,
>> and sightings.
>> 
>> 3) I personally do not believe we need a strict serialization binding from
>> the model to the on-the-wire format.  A binding between UML and
>> JSON+JSONSchema is where we need to go.
>> 
>> 4) My proposal is and has been:  UML Data Model with JSON+JSONSchema
>> serialization with the option of Protobuf/Cap-n-Proto as a secondary
>> serialization.
>> 
>> 
>> 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 Oct 9, 2015, at 09:30, Shawn Riley <shawn.p.riley@GMAIL.COM> wrote:
>> 
>> I'm confused then. If the community is perfectly happy with an RDF/OWL w/UML
>> data model then that is all that is needed to use the RDF serializations. It
>> seems then the argument is creating additional JSON / JSONSchema on the wire
>> format in addition to the RDF serializations?  Or is the community saying we
>> are ok with having an RDF/OWL w/ UML data model but you will prohibit the
>> community from using any of the existing RDF serializations designed to be
>> used with the data model?
>> 
>> On Fri, Oct 9, 2015 at 11:14 AM, Wunder, John A. <jwunder@mitre.org> wrote:
>>> 
>>> I haven’t seen anybody suggest not having an abstract data model (either
>>> via RDF, UML, or something else). Bret in particular has been careful to
>>> maintain that we will base any serialization on a high-level model.
>>> 
>>> The question we’re tackling now is whether the on-the-wire MTI format
>>> should be something tied directly to RDF, like JSON-LD, or something that's
>>> indirectly tied to the high-level model via a binding specification, like
>>> JSON with JSONSchema. Both approaches allow for an RDF-based analysis, it’s
>>> just a question of whether an RDF-based serialization format is the best
>>> approach for sharing data between tools when not all of them will want to do
>>> RDF.
>>> 
>>> FWIW I’m waiting to see what Cory’s examples look like.
>>> 
>>> John
>>> 
>>> On Oct 9, 2015, at 10:55 AM, Shawn Riley <shawn.p.riley@GMAIL.COM> wrote:
>>> 
>>> I just don't see why some here are moving away from the original plan of
>>> moving from XML to an abstract data model like RDF. We had face to face
>>> discussions on the topic and it's been discussed repeatedly since STIX
>>> launched. The whole reason some have been promoting STIX internationally and
>>> across the community was because this was the future direction. I certainly
>>> don't want to throw away the last 4 years of work on CTI in RDF and the
>>> significant advancement in analytic tradecraft it brings. I don’t see why
>>> this should be positioned as an either-or decision. The desires of those
>>> wanting simple JSON serializations should be fully possible within an
>>> RDF-based modeling approach while still enabling us to support moving
>>> forward the state of the practice for cyber threat analysts. Please help me
>>> understand why after more than 4 years of discussing this transition from
>>> XML to an RDF-based modeling approach that we now have people pushing to
>>> move the CTI effort in another direction?
>>> 
>>> On Thu, Oct 8, 2015 at 12:14 PM, Jacobsen, Jasen W. <jasenj1@mitre.org>
>>> wrote:
>>>> 
>>>> Note that the JSON they provide is JSON-LD.
>>>> http://docs.publishmydata.com/developers/105_resource_formats.html
>>>> And they provide a JavaScript example of accessing the JSON-LD:
>>>> http://docs.publishmydata.com/developers/121_example_javascript_filtered_resources.html
>>>> 
>>>> Good resource. Thanks for sharing.
>>>> 
>>>> - Jasen.
>>>> 
>>>> From: <cti-users@lists.oasis-open.org> on behalf of Shawn Riley
>>>> <shawn.p.riley@gmail.com>
>>>> Date: Thursday, October 8, 2015 at 11:28 AM
>>>> To: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
>>>> Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was:
>>>> MTI Binding)
>>>> 
>>>> I wanted to share a link (below) to a blog which talks about RDF
>>>> serialization formats and while this isn't STIX specific it does use real
>>>> world data from http://opendatacommunities.org/ which is the UK Department
>>>> for Communities and Local Government's official Linked Open Data website. As
>>>> I'm sure everyone is aware both the USA and UK governments have been
>>>> champions of RDF for several years now and continue to push for open data to
>>>> made available in RDF.
>>>> 
>>>> http://blog.swirrl.com/articles/rdf-serialisation-formats/   <--NOTE this
>>>> is from 2012 before the JSON-LD development but it should help those looking
>>>> for more RDF data then the US Government's 7000+ RDF open data sets.
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 



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