[cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Trey Darley-3
On 22.11.2015 10:18:04, Shawn Riley wrote:
> https://www.linkedin.com/pulse/oasis-cti-stix-vote-json-yes-json-ld-shawn-riley

Shawn's post on LinkedIn mischaracterizes the resolution proposal.
Please everyone take the time to actually *read* the mail which went
out Friday [0] before formulating a judgement.

It is *not* the case that CTI vendors are attempting to hammer through
a decision on the MTI serialization. This is a *community-wide effort*
to progress beyond an interminable and unproductive debate which is
undermining the entire CTI effort.

A large number of prominent members of the community have come out in
support of the proposal already, including the overwhelming majority
of the TC co-chairs, the majority of the MITRE representatives, *and*
the majority of vendors participating in the OASIS CTI community.

Public endorsements to date include:

  * Aharon Chernin (Soltra)
  * Alexander Foley (Bank of America)
  * Bernd Grobauer (Siemens)
  * Bret Jordon (Blue Coat)
  * David Eilken (Soltra)
  * Ivan Kirillov (MITRE)
  * Jason Keirstead (IBM)
  * Joep Gommers (EclecticIQ)
  * John Anderson (Soltra)
  * John Wunder (MITRE)
  * Jon Baker (MITRE)
  * Jonathan Bush (Soltra)
  * Mark Davidson (MITRE)
  * Richard Struse (DHS)
  * Sergey Polzunov (EclecticIQ)
  * Terry MacDonald (Soltra)
  * Trey Darley (Soltra)
  * Wade Baker (ThreatConnect)
                               

*Nor* is it the case that we are ruling out standardizing a JSON-LD
CTI serialization schema *in future*. From the mail that went out
Friday:

<snip>
Likewise, the co-chairs recognize that there will be communities of
interest requiring alternative serialization formats (XML, protobufs,
JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
standardize these alternative representations to ensure
interoperabilitity. However, that work effort lies in the future.
First we must complete the task at hand.
</snip>

[0]: https://www.oasis-open.org/apps/org/workgroup/cti/email/archives/201511/msg00105.html

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"Every networking problem always takes longer to solve than it seems
like it should." --RFC 1925

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
I have not seen a single CISO or CTI Analyst endorsement. I do see the list of developers, engineers, etc. endorsements you provided. Thanks! I stand by my post.

Cheers,
Shawn

On Mon, Nov 23, 2015 at 4:06 AM, Trey Darley <[hidden email]> wrote:
On 22.11.2015 10:18:04, Shawn Riley wrote:
> https://www.linkedin.com/pulse/oasis-cti-stix-vote-json-yes-json-ld-shawn-riley

Shawn's post on LinkedIn mischaracterizes the resolution proposal.
Please everyone take the time to actually *read* the mail which went
out Friday [0] before formulating a judgement.

It is *not* the case that CTI vendors are attempting to hammer through
a decision on the MTI serialization. This is a *community-wide effort*
to progress beyond an interminable and unproductive debate which is
undermining the entire CTI effort.

A large number of prominent members of the community have come out in
support of the proposal already, including the overwhelming majority
of the TC co-chairs, the majority of the MITRE representatives, *and*
the majority of vendors participating in the OASIS CTI community.

Public endorsements to date include:

  * Aharon Chernin (Soltra)
  * Alexander Foley (Bank of America)
  * Bernd Grobauer (Siemens)
  * Bret Jordon (Blue Coat)
  * David Eilken (Soltra)
  * Ivan Kirillov (MITRE)
  * Jason Keirstead (IBM)
  * Joep Gommers (EclecticIQ)
  * John Anderson (Soltra)
  * John Wunder (MITRE)
  * Jon Baker (MITRE)
  * Jonathan Bush (Soltra)
  * Mark Davidson (MITRE)
  * Richard Struse (DHS)
  * Sergey Polzunov (EclecticIQ)
  * Terry MacDonald (Soltra)
  * Trey Darley (Soltra)
  * Wade Baker (ThreatConnect)


*Nor* is it the case that we are ruling out standardizing a JSON-LD
CTI serialization schema *in future*. From the mail that went out
Friday:

<snip>
Likewise, the co-chairs recognize that there will be communities of
interest requiring alternative serialization formats (XML, protobufs,
JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
standardize these alternative representations to ensure
interoperabilitity. However, that work effort lies in the future.
First we must complete the task at hand.
</snip>

[0]: https://www.oasis-open.org/apps/org/workgroup/cti/email/archives/201511/msg00105.html

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"Every networking problem always takes longer to solve than it seems
like it should." --RFC 1925

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Trey Darley-3
On 23.11.2015 06:16:18, Shawn Riley wrote:
> I have not seen a single CISO or CTI Analyst endorsement. I do see
> the list of developers, engineers, etc. endorsements you provided.
> Thanks! I stand by my post.
>

Sean -

OASIS is a democratic standards body. Decision-making is driven by the
consensus that emerges from OASIS members with voting rights. The
cti-users list is for random interested parties. The cti list is for
OASIS members with voting rights. If a CISO or CTI Analyst out there
cares deeply, it is incumbent upon them to join OASIS as a voting
member and make their voice heard as part of the democratic process.

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"There are only two hard things in Computer Science: cache
invalidation and naming things." --Phil Karlton

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
Since I have a few hundred CISOs and even more CTI analysts directly connected on LinkedIn they are being sent information directly to make them aware of this vote and the additional risk posed by moving to JSON. They deserve to be educated and notified.

It was the same list of developers who also agreed to listen to a JSON-LD presentation with real-world examples but have decided to push ahead and force the vote for JSON without giving the JSON-LD advocates the opportunity to present their case. 

Thanks,
Shawn

On Mon, Nov 23, 2015 at 6:23 AM, Trey Darley <[hidden email]> wrote:
On 23.11.2015 06:16:18, Shawn Riley wrote:
> I have not seen a single CISO or CTI Analyst endorsement. I do see
> the list of developers, engineers, etc. endorsements you provided.
> Thanks! I stand by my post.
>

Sean -

OASIS is a democratic standards body. Decision-making is driven by the
consensus that emerges from OASIS members with voting rights. The
cti-users list is for random interested parties. The cti list is for
OASIS members with voting rights. If a CISO or CTI Analyst out there
cares deeply, it is incumbent upon them to join OASIS as a voting
member and make their voice heard as part of the democratic process.

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"There are only two hard things in Computer Science: cache
invalidation and naming things." --Phil Karlton

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Aharon Chernin
I look forward to your CISO and analyst contacts actively engaging in the CTI community! 

Aharon

From: <[hidden email]> on behalf of Shawn Riley <[hidden email]>
Date: Monday, November 23, 2015 at 6:29 AM
To: Trey Darley <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Since I have a few hundred CISOs and even more CTI analysts directly connected on LinkedIn they are being sent information directly to make them aware of this vote and the additional risk posed by moving to JSON. They deserve to be educated and notified.

It was the same list of developers who also agreed to listen to a JSON-LD presentation with real-world examples but have decided to push ahead and force the vote for JSON without giving the JSON-LD advocates the opportunity to present their case. 

Thanks,
Shawn

On Mon, Nov 23, 2015 at 6:23 AM, Trey Darley <[hidden email]> wrote:
On 23.11.2015 06:16:18, Shawn Riley wrote:
> I have not seen a single CISO or CTI Analyst endorsement. I do see
> the list of developers, engineers, etc. endorsements you provided.
> Thanks! I stand by my post.
>

Sean -

OASIS is a democratic standards body. Decision-making is driven by the
consensus that emerges from OASIS members with voting rights. The
cti-users list is for random interested parties. The cti list is for
OASIS members with voting rights. If a CISO or CTI Analyst out there
cares deeply, it is incumbent upon them to join OASIS as a voting
member and make their voice heard as part of the democratic process.

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"There are only two hard things in Computer Science: cache
invalidation and naming things." --Phil Karlton

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
In reply to this post by Shawn Riley

Thanks Joep,

I understand JSON-LD is slightly more complex which is why the JSON-LD advocates have been working over the past month or two to simplify the format as much as possible while still enabling context to be encoded and unique IDs to be used. The plan was we would be allowed to present this to the community BEFORE any formal vote on the MTI format. Since this has now been bypassed and we are not being allowed to present our case we are just trying to make sure the CISOs and human CTI analysts across DHS, DoD, and our 2P community are aware of the pending vote.

Cheers,
Shawn

On Nov 23, 2015 7:39 AM, "Joep Gommers" <[hidden email]> wrote:
Hi Shawn, (Trey),

Thank you for this and earlier contributions on representing the analyst (human user’s) perspective. I think it is extremely valuable. As Aharon I’d be happy to support you in getting your readership and constituencies engaged more in the community – I’m with you that we often miss the analyst and user perspective.

I do want to add some nuance to what Trey is saying with regards to representation of CISO/CTI Analysts on the list. We, in whole, represent their interests. It is logical end-users don’t have the time and resources to be as involved as the vendors that will help the whole lot of them with their use-cases. We should be keeping their requirements in mind and vote on their behalf.

That said, the analyst/user in our (EclecticIQ) view isn’t really a user of STIX but rather systems using STIX to transport threat related information and using STIX to be inspired to model the domain of threat information – as to ensure alignment between systems that communicate with humans. The need to interpret STIX and “connect the dots” - irrespective of what STIX or its serialization format offer in terms of connectedness/relationships – is still an important part of any system supporting the analysts. I don’t believe that in the distributed way STIX is used that that requirement will ever go away. Additionally data mining and interpretations will continue to be required to connect-the-dots.

Vendors need to ensure they can serve the analysts use-cases and I think the road between analyst use-cases and serialization format is HUGE and there are many ways of meeting requirements. JSON-LD might be one of the technical implementations in which these use-cases could be met and might complicate others. JSON-LD does add significant complexity in certain areas. Equally, might help decrease it in others. I can’t oversee this Architecturally right this instance. I do feel consensus is far enough (which we’ll see if the case in the vote) to not re-open that debate. Hence my support of JSON right now.

For context; we spend significant resources to move into JSON and can certain say that moving further into something like JSON-LD would be a serious investment for implementors. So regardless so be considered carefully for STIX 3.0 and beyond.

All the best,
Joep





From: <[hidden email]> on behalf of Shawn Riley <[hidden email]>
Date: Monday, November 23, 2015 at 11:29 AM
To: Trey Darley <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Since I have a few hundred CISOs and even more CTI analysts directly connected on LinkedIn they are being sent information directly to make them aware of this vote and the additional risk posed by moving to JSON. They deserve to be educated and notified.

It was the same list of developers who also agreed to listen to a JSON-LD presentation with real-world examples but have decided to push ahead and force the vote for JSON without giving the JSON-LD advocates the opportunity to present their case. 

Thanks,
Shawn

On Mon, Nov 23, 2015 at 6:23 AM, Trey Darley <[hidden email]> wrote:
On 23.11.2015 06:16:18, Shawn Riley wrote:
> I have not seen a single CISO or CTI Analyst endorsement. I do see
> the list of developers, engineers, etc. endorsements you provided.
> Thanks! I stand by my post.
>

Sean -

OASIS is a democratic standards body. Decision-making is driven by the
consensus that emerges from OASIS members with voting rights. The
cti-users list is for random interested parties. The cti list is for
OASIS members with voting rights. If a CISO or CTI Analyst out there
cares deeply, it is incumbent upon them to join OASIS as a voting
member and make their voice heard as part of the democratic process.

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"There are only two hard things in Computer Science: cache
invalidation and naming things." --Phil Karlton

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Trey Darley-3
In reply to this post by Shawn Riley
On 23.11.2015 06:16:18, Shawn Riley wrote:
> I have not seen a single CISO or CTI Analyst endorsement. I do see
> the list of developers, engineers, etc. endorsements you provided.

Hey, Shawn -

You're making some pretty sweeping assumptions about the professional
backgrounds and qualifications of the people included on that list.

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"It is always something." --RFC 1925

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Kirillov, Ivan A.
In reply to this post by Trey Darley-3
To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan




On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

Best,
Shanw

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:
To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan




On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Terry MacDonald-3

Shawn,

 

I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.

 

I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.

 

My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <[hidden email]>
Cc: Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

 

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

 

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

 

Best,
Shanw

 

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan





On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
To be clear then you are advocating that the part of the community who have been working on ontologies for 4 years and who have shared the ontologies with the community just abandon these so we can start over and work on producing JSONSchemas so that we can turn around and reinvent the ontologies again down the road?  

On Mon, Nov 23, 2015 at 3:28 PM, Terry MacDonald <[hidden email]> wrote:

Shawn,

 

I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.

 

I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.

 

My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

<a href="tel:%2B61%20%28407%29%20203%20206" value="+61407203206" target="_blank">+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <[hidden email]>
Cc: Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

 

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

 

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

 

Best,
Shanw

 

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan





On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Barnum, Sean D.
In reply to this post by Terry MacDonald-3
So, Terry, it is not an either or. We can have a simple JSON representation for folks that want that. We can have that in a way that folks wanting something more capable like JSON-LD/RDF can have that at the same time and we can have this all derived from a consistent UML model and ontology. This is not academic. This is not long term big effort. We are VERY close to it now.

We have the ontology today. We have already demonstrated very simple auto generation of a full RDF/OWL ontology from the existing STIX UML model.
This UML model is the actual official spec for the language not any particular serialization (XML, JSON or otherwise).
The auto derived RDF/OWL ontology can then be used to derive out specific serializations including JSON-LD with specific JSON-Schema style that makes it almost completely “pure” JSON with a very minimal overhead.
Using this approach everything is consistent, well-formed, maintainable during refactorings/refinements and auto derivable.

I would suggest that it would make absolutely no sense at all to throw out what we have, start over trying to spec things directly in JSON and then attempt to reverse engineer from there.
Those of us working on the JSON-LD examples that folks asked for are very close to having something ready for people to look at. Most of our time so far has been spent working on finding ways to make the end JSON style be as simple and close to “pure” JSON as possible.
I think you will be pleasantly impressed with the option and its tradeoffs.

Please don’t think of this issue as an either or. It is both more and less simple than that.

sean

From: <[hidden email]> on behalf of Terry MacDonald <[hidden email]>
Date: Monday, November 23, 2015 at 3:28 PM
To: Shawn Riley <[hidden email]>, Steve Cell <[hidden email]>
Cc: Trey Darley <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn,

 

I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.

 

I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.

 

My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <[hidden email]>
Cc: Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

 

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

 

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

 

Best,
Shanw

 

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan





On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Terry MacDonald-3
In reply to this post by Shawn Riley

I am advocating that there are needs that the general info sec end users require that STIX is not currently offering. If the community feels that the fastest way to do this is to head down the JSON/JSON Schema path then I need to accept it. I don’t have enough expertise in RDF/OWL Ontologies to be able to be able to disagree with that.

 

I personally do not care what we develop the model in, just as long as we can make it more useful to our end users and enable them to better describe what they want to describe. My ultimate goal is to make it easy for end users to share and consume information that help them to defend themselves better.

 

I am very keen to see the output that Sean has mentioned in his recent post, as I would like everyone to be on the same page, but based on the past few years I expect pragmatism will need to prevail. Hopefully some concrete outputs will help people who aren’t RDF/OWL wizards understand the real value in the model.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | [hidden email]

 

 

From: Shawn Riley [mailto:[hidden email]]
Sent: Tuesday, 24 November 2015 7:41 AM
To: Terry MacDonald <[hidden email]>
Cc: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be clear then you are advocating that the part of the community who have been working on ontologies for 4 years and who have shared the ontologies with the community just abandon these so we can start over and work on producing JSONSchemas so that we can turn around and reinvent the ontologies again down the road?  

 

On Mon, Nov 23, 2015 at 3:28 PM, Terry MacDonald <[hidden email]> wrote:

Shawn,

 

I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.

 

I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.

 

My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

<a href="tel:%2B61%20%28407%29%20203%20206" target="_blank">+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <
[hidden email]>
Cc: Trey Darley <
[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

 

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

 

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

 

Best,
Shanw

 

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan





On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Shawn Riley
Terry,

We've been trying very hard to share helpful information with the community to provide knowledge that would help to educate people on things like JSON-LD and the new intelligence methodologies the ontologies enable.

Some examples of knowledge sharing to help people better understand the vision and long term goals...

Shawn 


Or the Object-Based Production and Activity-Based Intelligence articles with one showing the DoD view, one showing the IC view, and one showing the DoD/IC vendor view. 


On Mon, Nov 23, 2015 at 3:53 PM, Terry MacDonald <[hidden email]> wrote:

I am advocating that there are needs that the general info sec end users require that STIX is not currently offering. If the community feels that the fastest way to do this is to head down the JSON/JSON Schema path then I need to accept it. I don’t have enough expertise in RDF/OWL Ontologies to be able to be able to disagree with that.

 

I personally do not care what we develop the model in, just as long as we can make it more useful to our end users and enable them to better describe what they want to describe. My ultimate goal is to make it easy for end users to share and consume information that help them to defend themselves better.

 

I am very keen to see the output that Sean has mentioned in his recent post, as I would like everyone to be on the same page, but based on the past few years I expect pragmatism will need to prevail. Hopefully some concrete outputs will help people who aren’t RDF/OWL wizards understand the real value in the model.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

<a href="tel:%2B61%20%28407%29%20203%20206" value="+61407203206" target="_blank">+61 (407) 203 206 | [hidden email]

 

 

From: Shawn Riley [mailto:[hidden email]]
Sent: Tuesday, 24 November 2015 7:41 AM
To: Terry MacDonald <[hidden email]>
Cc: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; [hidden email]


Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be clear then you are advocating that the part of the community who have been working on ontologies for 4 years and who have shared the ontologies with the community just abandon these so we can start over and work on producing JSONSchemas so that we can turn around and reinvent the ontologies again down the road?  

 

On Mon, Nov 23, 2015 at 3:28 PM, Terry MacDonald <[hidden email]> wrote:

Shawn,

 

I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.

 

I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.

 

My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

<a href="tel:%2B61%20%28407%29%20203%20206" target="_blank">+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <
[hidden email]>
Cc: Trey Darley <
[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

 

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

 

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

 

Best,
Shanw

 

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan





On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

 

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Jordan, Bret
In reply to this post by Terry MacDonald-3
If we do not gain grater than 18-20% market share in the next year or so, this standard will fade away and will be replaced by YACS, regardless of how neat and prefect the model, ontology, or language is.  

The goal of STIX 2.0 SHOULD be first and foremost, how do we enable more products, software packages, and vendors to come on board and build support in their tools and software for STIX and TAXII????  

The model or language of STIX is important, but not the MOST important part, nor is it paramount that we do this in OWL or RDF.  Adoption is hands down, far and away, the most important thing.  Because if we do not get adoption, it really does not matter. 

Further, it will be a great problem to have, in a few years, if we have so many people using STIX and TAXII that we need to rev the standards to support X, Y, and Z.


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 Nov 23, 2015, at 13:53, Terry MacDonald <[hidden email]> wrote:

I am advocating that there are needs that the general info sec end users require that STIX is not currently offering. If the community feels that the fastest way to do this is to head down the JSON/JSON Schema path then I need to accept it. I don’t have enough expertise in RDF/OWL Ontologies to be able to be able to disagree with that.
 
I personally do not care what we develop the model in, just as long as we can make it more useful to our end users and enable them to better describe what they want to describe. My ultimate goal is to make it easy for end users to share and consume information that help them to defend themselves better.
 
I am very keen to see the output that Sean has mentioned in his recent post, as I would like everyone to be on the same page, but based on the past few years I expect pragmatism will need to prevail. Hopefully some concrete outputs will help people who aren’t RDF/OWL wizards understand the real value in the model.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | [hidden email]
 
 
From: Shawn Riley [[hidden email]] 
Sent: Tuesday, 24 November 2015 7:41 AM
To: Terry MacDonald <[hidden email]>
Cc: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
 
To be clear then you are advocating that the part of the community who have been working on ontologies for 4 years and who have shared the ontologies with the community just abandon these so we can start over and work on producing JSONSchemas so that we can turn around and reinvent the ontologies again down the road?  
 
On Mon, Nov 23, 2015 at 3:28 PM, Terry MacDonald <[hidden email]> wrote:
Shawn,
 
I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.
 
I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.
 
My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
<a href="tel:%2B61%20%28407%29%20203%20206" target="_blank" style="color: purple; text-decoration: underline;" class="">+61 (407) 203 206 | [hidden email]
 
 
From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <
[hidden email]>
Cc: Trey Darley <
[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
 
To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.
 
I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?
 
Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?
 
Best,
Shanw
 
On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:
To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan




On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Struse, Richard

All,

 

What I am hearing is that the model/ontology cadre believe that they can satisfy their desire/need for a formally-defined model in a way that satisfies implementers desire/need for simple and low-overhead (cognitive and otherwise) representations.  And that they can do this using JSON.

 

I would like to suggest that we all take a deep breath and give them the chance to make their argument with specific, concrete examples.  In the meantime, there is a ballot open that does not preclude model-driven approaches if the TC wants them.

 

Regards,

Rich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jordan, Bret
Sent: Monday, November 23, 2015 4:04 PM
To: Terry MacDonald
Cc: Shawn Riley; Ivan Kirillov; Trey Darley; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

If we do not gain grater than 18-20% market share in the next year or so, this standard will fade away and will be replaced by YACS, regardless of how neat and prefect the model, ontology, or language is.  

 

The goal of STIX 2.0 SHOULD be first and foremost, how do we enable more products, software packages, and vendors to come on board and build support in their tools and software for STIX and TAXII????  

 

The model or language of STIX is important, but not the MOST important part, nor is it paramount that we do this in OWL or RDF.  Adoption is hands down, far and away, the most important thing.  Because if we do not get adoption, it really does not matter. 

 

Further, it will be a great problem to have, in a few years, if we have so many people using STIX and TAXII that we need to rev the standards to support X, Y, and Z.

 

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 Nov 23, 2015, at 13:53, Terry MacDonald <[hidden email]> wrote:

 

I am advocating that there are needs that the general info sec end users require that STIX is not currently offering. If the community feels that the fastest way to do this is to head down the JSON/JSON Schema path then I need to accept it. I don’t have enough expertise in RDF/OWL Ontologies to be able to be able to disagree with that.

 

I personally do not care what we develop the model in, just as long as we can make it more useful to our end users and enable them to better describe what they want to describe. My ultimate goal is to make it easy for end users to share and consume information that help them to defend themselves better.

 

I am very keen to see the output that Sean has mentioned in his recent post, as I would like everyone to be on the same page, but based on the past few years I expect pragmatism will need to prevail. Hopefully some concrete outputs will help people who aren’t RDF/OWL wizards understand the real value in the model.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | [hidden email]

 

 

From: Shawn Riley [[hidden email]] 
Sent: Tuesday, 24 November 2015 7:41 AM
To: Terry MacDonald <[hidden email]>
Cc: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be clear then you are advocating that the part of the community who have been working on ontologies for 4 years and who have shared the ontologies with the community just abandon these so we can start over and work on producing JSONSchemas so that we can turn around and reinvent the ontologies again down the road?  

 

On Mon, Nov 23, 2015 at 3:28 PM, Terry MacDonald <[hidden email]> wrote:

Shawn,

 

I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.

 

I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.

 

My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

<a href="tel:%2B61%20%28407%29%20203%20206" target="_blank">+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <
[hidden email]>
Cc: Trey Darley <
[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.

 

I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?

 

Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?

 

Best,
Shanw

 

On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan





On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:


>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

 


smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Barnum, Sean D.
In reply to this post by Jordan, Bret
Again, you are painting a false dichotomy.

Targeting increased adoption in NO way precludes taking mature approaches to do it.

You have repeatedly asserted that the only way for us to achieve the increased adoption we desire is to utilize JSON as a simplification of implementation.
A JSON-LD approach IS JSON and would enable you to do pretty much everything you wish to do with “pure” JSON with a VERY minimal overhead that anyone wishing to do only “pure” JSON could simply ignore.

Simplicity and adoption can be pursued and achieved using mature and capable means. 

sean

From: <[hidden email]> on behalf of "Jordan, Bret" <[hidden email]>
Date: Monday, November 23, 2015 at 4:04 PM
To: Terry MacDonald <[hidden email]>
Cc: Shawn Riley <[hidden email]>, Steve Cell <[hidden email]>, Trey Darley <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

If we do not gain grater than 18-20% market share in the next year or so, this standard will fade away and will be replaced by YACS, regardless of how neat and prefect the model, ontology, or language is.  

The goal of STIX 2.0 SHOULD be first and foremost, how do we enable more products, software packages, and vendors to come on board and build support in their tools and software for STIX and TAXII????  

The model or language of STIX is important, but not the MOST important part, nor is it paramount that we do this in OWL or RDF.  Adoption is hands down, far and away, the most important thing.  Because if we do not get adoption, it really does not matter. 

Further, it will be a great problem to have, in a few years, if we have so many people using STIX and TAXII that we need to rev the standards to support X, Y, and Z.


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 Nov 23, 2015, at 13:53, Terry MacDonald <[hidden email]> wrote:

I am advocating that there are needs that the general info sec end users require that STIX is not currently offering. If the community feels that the fastest way to do this is to head down the JSON/JSON Schema path then I need to accept it. I don’t have enough expertise in RDF/OWL Ontologies to be able to be able to disagree with that.
 
I personally do not care what we develop the model in, just as long as we can make it more useful to our end users and enable them to better describe what they want to describe. My ultimate goal is to make it easy for end users to share and consume information that help them to defend themselves better.
 
I am very keen to see the output that Sean has mentioned in his recent post, as I would like everyone to be on the same page, but based on the past few years I expect pragmatism will need to prevail. Hopefully some concrete outputs will help people who aren’t RDF/OWL wizards understand the real value in the model.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | [hidden email]
 
 
From: Shawn Riley [[hidden email]] 
Sent: Tuesday, 24 November 2015 7:41 AM
To: Terry MacDonald <[hidden email]>
Cc: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
 
To be clear then you are advocating that the part of the community who have been working on ontologies for 4 years and who have shared the ontologies with the community just abandon these so we can start over and work on producing JSONSchemas so that we can turn around and reinvent the ontologies again down the road?  
 
On Mon, Nov 23, 2015 at 3:28 PM, Terry MacDonald <[hidden email]> wrote:
Shawn,
 
I like the idea of creating an Ontology, but I equally recognize the requirement to quickly provide users with more functionality so that they can do their jobs. We have a list of problems with the current version of STIX that experience has taught us over the last few years, and we have a real need to fix them in order to promote greater adoption of the STIX/TAXII/CybOX standards. The InfoSec community already thinks STIX is complicated, or else Facebook's ThreatExchange, OpenTPX wouldn't exist. We need to act quickly or else all our hard work will be for nought, no matter if STIX is based on an Ontology or not.
 
I would completely prefer an Ontology, as I think it will improve our ability to move to binary representations in the future, but I equally don't think that there is enough appetite within the community to do so as part of STIX v2.0. I am hopeful that we can yet again reverse engineer an Ontology from the JSON representation, and I figure as long as we do things in a standardized way throughout STIX we should be able to achieve that. If not, then we will need to wait until STIX v3.0.
 
My preference would always be to be able to do things logically and model things completely, but sometimes good enough is good enough.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
<a href="tel:%2B61%20%28407%29%20203%20206" target="_blank" style="color: purple; text-decoration: underline;" class="">+61 (407) 203 206 | [hidden email]
 
 
From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Tuesday, 24 November 2015 7:00 AM
To: Kirillov, Ivan A. <
[hidden email]>
Cc: Trey Darley <
[hidden email]>; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
 
To be fair, since part of the community has been advocating RDF/OWL2 ontologies since STIX v0.3 and we've had face to face discussions with the STIX community at Black Hat and RSA since 2013 about the ontologies. We do have complete sets of RDF/OWL2 ontologies for each of the standards (STIX, CYBOX, MAEC, CAPEC, CWE, CVE, etc) based on their current versions today. We provided links to these to demonstrate this wasn't just "academic" but real world. Here are links to them. https://github.com/DSIE/cyber-ontology  or  https://github.com/daedafusion/cyber-ontology.
 
I have not however seen complete JSONSchemas for each standard (STIX, CYBOX, MAEC, etc) based on the current versions. Can you please send links to the complete set of JSONSchemas for each of the standards?
 
Where was the voices calling for JSON in 2012, 2013 or 2014 when we were working on the semantic ontologies and sharing lessons learned with the community online and face to face?
 
Best,
Shanw
 
On Mon, Nov 23, 2015 at 2:50 PM, Kirillov, Ivan A. <[hidden email]> wrote:
To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan




On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD
>CTI serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Cory Casanave
In reply to this post by Kirillov, Ivan A.
Re: Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

JSON-LD, JSON-Schema, RDF Schema and XML Schema can all be produced, in a consistent form, from a well-structured UML model.

-Cory

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Kirillov, Ivan A.
Sent: Monday, November 23, 2015 2:50 PM
To: Trey Darley; Shawn Riley
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?

Regards,
Ivan




On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:

>*Nor* is it the case that we are ruling out standardizing a JSON-LD CTI
>serialization schema *in future*. From the mail that went out
>Friday:
>
><snip>
>Likewise, the co-chairs recognize that there will be communities of
>interest requiring alternative serialization formats (XML, protobufs,
>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>standardize these alternative representations to ensure
>interoperabilitity. However, that work effort lies in the future.
>First we must complete the task at hand.
></snip>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Wunder, John A.
I feel like I should weigh in on this since I put my name on the resolution and have spent some time looking into JSON-LD. Sorry for the length.

I can see the value in having RDF/OWL-based tools talk directly to each other. I don’t personally use those tools and don’t plan to start using those tools but I understand that others do and will want to use them with STIX.

At the same time, I think most people will use tools that are specifically developed for this domain. There will be python code or Java code or Ruby code behind them. These tools will be used by threat analysts and incident responders and CTOs to do their jobs. But, they will be coded by developers against the MTI specification of STIX.

The MTI format should optimize for the preponderance of usage, if possible making concessions for other approaches. The preponderance of usage is clearly in custom-developed tools and therefore the format should optimize for that. As I think the vote will show, these developers will want JSON (or XML or protobuf, but mostly JSON).

It’s true that JSON-LD is technically JSON and makes the RDF-based approach (to be honest) much more palatable. From my own investigations it does not go far enough. That said, if you’re on the fence you should wait to see what Sean, Shawn, Pat, and Cory produce. Maybe they got farther than I did and if so we should consider it. I know I would change my vote if it truly gets to the point where support JSON-LD is only a bit more work.

My last point…if you want to exchange RDF-based STIX data go ahead and do it! You can convert the UML into OWL and exchange that just like Cory is saying below. We could even standardize that as a non-MTI format and because everything is driven from the model you can losslessly convert.

Summary: let’s not burden the majority of people who are writing custom software. Developers are lazy and if the JSON-LD is even 10% more confusing or complicated than the regular JSON that can and will drive people away. The semantic tools will still be able to talk STIX with each other. With some minor massaging they can probably even consume data produced in “native” JSON. But let’s get this near-term win on simplicity and get a crapton of tools and data feeds out there supporting STIX.

John

> On Nov 23, 2015, at 4:32 PM, Cory Casanave <[hidden email]> wrote:
>
> Re: Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?
>
> JSON-LD, JSON-Schema, RDF Schema and XML Schema can all be produced, in a consistent form, from a well-structured UML model.
>
> -Cory
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Kirillov, Ivan A.
> Sent: Monday, November 23, 2015 2:50 PM
> To: Trey Darley; Shawn Riley
> Cc: [hidden email]
> Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
>
> To add to Trey’s point below, JSON-LD would be a much more logical choice if STIX and CybOX had native ontological (RDF/OWL) representations. While this is likely a direction we’re heading in, it’s not where we are at today. Given that, what is the value of JSON-LD in a UML-driven, XSD-derived representation?
>
> Regards,
> Ivan
>
>
>
>
> On 11/23/15, 4:06 AM, "Trey Darley" <[hidden email] on behalf of [hidden email]> wrote:
>
>> *Nor* is it the case that we are ruling out standardizing a JSON-LD CTI
>> serialization schema *in future*. From the mail that went out
>> Friday:
>>
>> <snip>
>> Likewise, the co-chairs recognize that there will be communities of
>> interest requiring alternative serialization formats (XML, protobufs,
>> JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to
>> standardize these alternative representations to ensure
>> interoperabilitity. However, that work effort lies in the future.
>> First we must complete the task at hand.
>> </snip>

123
Loading...