[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
|

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

Terry MacDonald-3
+100 John.

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | [hidden email]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>

Reply | Threaded
Open this post in threaded view
|

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

Shawn Riley
As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <[hidden email]> wrote:
+100 John.

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">+61 (407) 203 206 | [hidden email]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>


Reply | Threaded
Open this post in threaded view
|

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

Shawn Riley
Sorry, an I forgot.... Remember that while those videos use schema.org, we would use oasis.org/cti/stix or similar to point to our model vice pointing to schema.org. Thanks//spr

On Mon, Nov 23, 2015 at 6:42 PM, Shawn Riley <[hidden email]> wrote:
As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <[hidden email]> wrote:
+100 John.

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]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>



Reply | Threaded
Open this post in threaded view
|

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

Jordan, Bret
In reply to this post by Shawn Riley
I fully understand what JSON-LD is.  I just do not believe it will help us drive adoption.  In fact I think it will hinder adoption.  

I have yet to see or hear any network product / security product / open source security tool developer ask for JSON-LD.  What I do hear, as I walk the floor at RSA and Blackhat is every CTO and product manager asking "when are we going to support JSON".

Further, it is not really essential to convince this group on what JSON-LD is, it is however, necessary to convince and train every developer and product manager on the planet.  And I do not see that happening.  

Analyst use products built by vendors.  Those vendors are asking for JSON.  When they start asking for JSON-LD, then I am sure we will rev the standards to support it.   If we do not get adoption then all of this is for not.  

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 16:42, Shawn Riley <[hidden email]> wrote:

As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <[hidden email]> wrote:
+100 John.

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" class="">+61 (407) 203 206 | [hidden email]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>




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

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

Shawn Riley
I'm hopeful that developers will be gaining more experience with JSON-LD since Google announced their support for JSON-LD in January of this year.



More importantly, JSON-LD already has cross-platform availability:

Javascript

Python

PHP

Ruby

Java

C#

Go


On Mon, Nov 23, 2015 at 7:29 PM, Jordan, Bret <[hidden email]> wrote:
I fully understand what JSON-LD is.  I just do not believe it will help us drive adoption.  In fact I think it will hinder adoption.  

I have yet to see or hear any network product / security product / open source security tool developer ask for JSON-LD.  What I do hear, as I walk the floor at RSA and Blackhat is every CTO and product manager asking "when are we going to support JSON".

Further, it is not really essential to convince this group on what JSON-LD is, it is however, necessary to convince and train every developer and product manager on the planet.  And I do not see that happening.  

Analyst use products built by vendors.  Those vendors are asking for JSON.  When they start asking for JSON-LD, then I am sure we will rev the standards to support it.   If we do not get adoption then all of this is for not.  

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 16:42, Shawn Riley <[hidden email]> wrote:

As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <[hidden email]> wrote:
+100 John.

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]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>




Reply | Threaded
Open this post in threaded view
|

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

Jordan, Bret
I would love nothing more than to have so much demand for STIX via JSON-LD or Cap-n-Proto that we have to rev the specs to support it.  That would make me so happy.  

Let's do this in steps with a vision to become the best and most widely used solution for CTI.  

Having to rev the spec to support higher level ontologies or high throughput would be an amazing problem to have.  But first, we need vendor buy in.  Once we get that, we can move to the next level.

Bret 

Sent from my Commodore 64

On Nov 23, 2015, at 5:40 PM, Shawn Riley <[hidden email]> wrote:

I'm hopeful that developers will be gaining more experience with JSON-LD since Google announced their support for JSON-LD in January of this year.



More importantly, JSON-LD already has cross-platform availability:

Javascript

Python

PHP

Ruby

Java

C#

Go


On Mon, Nov 23, 2015 at 7:29 PM, Jordan, Bret <[hidden email]> wrote:
I fully understand what JSON-LD is.  I just do not believe it will help us drive adoption.  In fact I think it will hinder adoption.  

I have yet to see or hear any network product / security product / open source security tool developer ask for JSON-LD.  What I do hear, as I walk the floor at RSA and Blackhat is every CTO and product manager asking "when are we going to support JSON".

Further, it is not really essential to convince this group on what JSON-LD is, it is however, necessary to convince and train every developer and product manager on the planet.  And I do not see that happening.  

Analyst use products built by vendors.  Those vendors are asking for JSON.  When they start asking for JSON-LD, then I am sure we will rev the standards to support it.   If we do not get adoption then all of this is for not.  

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 16:42, Shawn Riley <[hidden email]> wrote:

As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <[hidden email]> wrote:
+100 John.

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
<a href="tel:%2B61%20%28407%29%20203%20206" value="&#43;61407203206" target="_blank">+61 (407) 203 206 | [hidden email]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>




Reply | Threaded
Open this post in threaded view
|

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

Shawn Riley

I'm glad that both the JSON camp and the JSON-LD camp will be given "the chance to make their argument with specific, concrete examples" before we vote.

On Nov 23, 2015 8:35 PM, "Jordan, Bret" <[hidden email]> wrote:
I would love nothing more than to have so much demand for STIX via JSON-LD or Cap-n-Proto that we have to rev the specs to support it.  That would make me so happy.  

Let's do this in steps with a vision to become the best and most widely used solution for CTI.  

Having to rev the spec to support higher level ontologies or high throughput would be an amazing problem to have.  But first, we need vendor buy in.  Once we get that, we can move to the next level.

Bret 

Sent from my Commodore 64

On Nov 23, 2015, at 5:40 PM, Shawn Riley <[hidden email]> wrote:

I'm hopeful that developers will be gaining more experience with JSON-LD since Google announced their support for JSON-LD in January of this year.



More importantly, JSON-LD already has cross-platform availability:

Javascript

Python

PHP

Ruby

Java

C#

Go


On Mon, Nov 23, 2015 at 7:29 PM, Jordan, Bret <[hidden email]> wrote:
I fully understand what JSON-LD is.  I just do not believe it will help us drive adoption.  In fact I think it will hinder adoption.  

I have yet to see or hear any network product / security product / open source security tool developer ask for JSON-LD.  What I do hear, as I walk the floor at RSA and Blackhat is every CTO and product manager asking "when are we going to support JSON".

Further, it is not really essential to convince this group on what JSON-LD is, it is however, necessary to convince and train every developer and product manager on the planet.  And I do not see that happening.  

Analyst use products built by vendors.  Those vendors are asking for JSON.  When they start asking for JSON-LD, then I am sure we will rev the standards to support it.   If we do not get adoption then all of this is for not.  

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 16:42, Shawn Riley <[hidden email]> wrote:

As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <[hidden email]> wrote:
+100 John.

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]
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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>




JA
Reply | Threaded
Open this post in threaded view
|

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

JA
-abstract-
Politics is saying what people want to hear
Business is saying people what you're offering is what they want/need
Science is giving people what they need (and maybe they didn't know they need)


On Tuesday, 24 November 2015, Shawn Riley <[hidden email]> wrote:

I'm glad that both the JSON camp and the JSON-LD camp will be given "the chance to make their argument with specific, concrete examples" before we vote.

On Nov 23, 2015 8:35 PM, "Jordan, Bret" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bret.jordan@bluecoat.com&#39;);" target="_blank">bret.jordan@...> wrote:
I would love nothing more than to have so much demand for STIX via JSON-LD or Cap-n-Proto that we have to rev the specs to support it.  That would make me so happy.  

Let's do this in steps with a vision to become the best and most widely used solution for CTI.  

Having to rev the spec to support higher level ontologies or high throughput would be an amazing problem to have.  But first, we need vendor buy in.  Once we get that, we can move to the next level.

Bret 

Sent from my Commodore 64

On Nov 23, 2015, at 5:40 PM, Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.riley@...> wrote:

I'm hopeful that developers will be gaining more experience with JSON-LD since Google announced their support for JSON-LD in January of this year.



More importantly, JSON-LD already has cross-platform availability:

Javascript

Python

PHP

Ruby

Java

C#

Go


On Mon, Nov 23, 2015 at 7:29 PM, Jordan, Bret <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bret.jordan@bluecoat.com&#39;);" target="_blank">bret.jordan@...> wrote:
I fully understand what JSON-LD is.  I just do not believe it will help us drive adoption.  In fact I think it will hinder adoption.  

I have yet to see or hear any network product / security product / open source security tool developer ask for JSON-LD.  What I do hear, as I walk the floor at RSA and Blackhat is every CTO and product manager asking "when are we going to support JSON".

Further, it is not really essential to convince this group on what JSON-LD is, it is however, necessary to convince and train every developer and product manager on the planet.  And I do not see that happening.  

Analyst use products built by vendors.  Those vendors are asking for JSON.  When they start asking for JSON-LD, then I am sure we will rev the standards to support it.   If we do not get adoption then all of this is for not.  

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 16:42, Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@GMAIL.COM&#39;);" target="_blank">shawn.p.riley@...> wrote:

As another effort to share knowledge about JSON-LD, there is a tutorial / learning page @ http://json-ld.org/learn.html

I'd recommend at least viewing the following 3 short videos to get an overview of JSON-LD, particularly the JSON-LD Compaction and Expansion video.  

On Mon, Nov 23, 2015 at 5:37 PM, Terry MacDonald <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> wrote:
+100 John.

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 | <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...
 

-----Original Message-----
From: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@... [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...] On Behalf Of Wunder, John A.
Sent: Tuesday, 24 November 2015 9:11 AM
To: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cory-c@modeldriven.com&#39;);" target="_blank">cory-c@...> 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: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@... [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...] On Behalf Of Kirillov, Ivan A.
> Sent: Monday, November 23, 2015 2:50 PM
> To: Trey Darley; Shawn Riley
> Cc: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...
> 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" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@... on behalf of <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;trey@soltra.com&#39;);" target="_blank">trey@...> 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
|

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 Wunder, John A.
On 23.11.2015 22:10:36, Wunder, John A. wrote:
>
> I know I would change my vote if it truly gets to the point where
> support JSON-LD is only a bit more work.
>

As would I. I have long supported the notion of semantic
representation. But now is the time for pragmatism and progress on the
refactoring effort.

>
> But let’s get this near-term win on simplicity and get a crapton of
> tools and data feeds out there supporting STIX.
>

Well-put, John, couldn't have said it better myself!

--
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
--
"No matter how hard you try, you can't make a baby in much less than 9
months. Trying to speed this up *might* make it slower, but it won't
make it happen any quicker." --RFC 1925

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

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

Trey Darley-3
On 24.11.2015 07:51:40, Trey Darley wrote:

> On 23.11.2015 22:10:36, Wunder, John A. wrote:
> >
> > I know I would change my vote if it truly gets to the point where
> > support JSON-LD is only a bit more work.
> >
>
> As would I. I have long supported the notion of semantic
> representation. But now is the time for pragmatism and progress on the
> refactoring effort.
>
Before anyone misconstrues my words, let me be clear. My vote on the
resolution at hand has been cast and I am *not* changing it. But the
measure is a non-binding vote. If, by the time we're nearing
completion of the ongoing refactoring effort, the JSON-LD crowd can
present us with a viable strawman, demonstrate in terms that the
*entire community* can *clearly understand* the value that a semantic
representation adds, *and* show that this added value can be achieved
without imposing a significant burden on implementers who are used to
JSON/JSON Schema, then I would be open to reconsidering the MTI
question.

Convincing the wider community is going to require a good deal more
work on the part of the JSON-LD folks than merely reposting the same
Slideshare links over and over again.

Meanwhile, we have been dickering around far too long. We're settling
this question today so we can move forward with more pressing matters.
Let us not allow idealistic visions of perfection to consign all our
hard efforts to obscurity.

--
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
|

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

Shawn Riley
Hi Trey,

I respectfully request you consider Richard Struse's suggestion, "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."

I believe we also have the support of the Enhanced Shared Situational Awareness (ESSA) lead so please give us the time to make our argument and present our specific, concrete examples to the community. 

If you aren't familiar with the ESSA, you can read about it here: https://www.us-cert.gov/essa

Thanks again for your willingness to collaborate and give us the time to make our argument.

Shawn

On Tue, Nov 24, 2015 at 3:40 AM, Trey Darley <[hidden email]> wrote:
On 24.11.2015 07:51:40, Trey Darley wrote:
> On 23.11.2015 22:10:36, Wunder, John A. wrote:
> >
> > I know I would change my vote if it truly gets to the point where
> > support JSON-LD is only a bit more work.
> >
>
> As would I. I have long supported the notion of semantic
> representation. But now is the time for pragmatism and progress on the
> refactoring effort.
>

Before anyone misconstrues my words, let me be clear. My vote on the
resolution at hand has been cast and I am *not* changing it. But the
measure is a non-binding vote. If, by the time we're nearing
completion of the ongoing refactoring effort, the JSON-LD crowd can
present us with a viable strawman, demonstrate in terms that the
*entire community* can *clearly understand* the value that a semantic
representation adds, *and* show that this added value can be achieved
without imposing a significant burden on implementers who are used to
JSON/JSON Schema, then I would be open to reconsidering the MTI
question.

Convincing the wider community is going to require a good deal more
work on the part of the JSON-LD folks than merely reposting the same
Slideshare links over and over again.

Meanwhile, we have been dickering around far too long. We're settling
this question today so we can move forward with more pressing matters.
Let us not allow idealistic visions of perfection to consign all our
hard efforts to obscurity.

--
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

Reply | Threaded
Open this post in threaded view
|

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

Trey Darley-3
On 24.11.2015 06:53:33, Shawn Riley wrote:
>
> I respectfully request you consider Richard Struse's suggestion, "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."
>

Hi, Shawn -

The email medium has its limitations. If I somehow rubbed you wrong, I
blame the medium. My intention was merely to be explicit and thereby
avoid confusion. ^_^

I fully agree with Rich's wise admonition.

--
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's never enough time. Thank you for yours." --Dan Geer

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

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 Cory Casanave
That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

Regards,
Ivan




On 11/23/15, 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>
Reply | Threaded
Open this post in threaded view
|

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

Cory Casanave
Ivan,
This is a discussion we should have. I am not opposed to well-formed OWL either, what is important is that we have a semantic description. What we have found in threat/risk is that in conceptual UML models we have 90% of the expressiveness of OWL in addition to being able to assert some things OWL is very bad at, such as the time, context and provenance of statements. Keep in mind we are using UML based on a specific profile for this purpose.

What concerns me more is statement like we should refactor first and then look at the models. Valid refactoring at a syntax level has gone wrong every time I have seen it as what your syntax means gets confused and inconsistent. This becomes a barrier for implementation and interoperability. Whatever the language of expression, the model should be where the concepts and their relationships are figured out - we can then come up with more or more syntax representations for it. Doing it upside down will not, IMHO, lead to a usable result or widespread adoption.

-Cory

-----Original Message-----
From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Tuesday, November 24, 2015 8:21 AM
To: Cory Casanave; Trey Darley; Shawn Riley
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

Regards,
Ivan




On 11/23/15, 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>
Reply | Threaded
Open this post in threaded view
|

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

Terry MacDonald-3

" Doing it upside down will not, IMHO, lead to a usable result or widespread adoption."

 

This comment is where I have a slight problem. The upside down development process may not be perfect, but it has worked 'well enough' up to this point.  OASIS CTI is the largest standards group that OASIS has had so far as I understand it, so STIX/TAXII/CybOX must be fairly useful and have reached a reasonable adoption even in its current bohemian state to have generated such interest.

 

STIX itself is IMHO empirical evidence that sometimes good enough is good enough.

 

That said, if there is a way that we can improve the model and the way we derive serializations without impacting implementers onerously, then I am very keen to see it.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; Shawn Riley <[hidden email]>
Cc: [hidden email]
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

Ivan,

This is a discussion we should have. I am not opposed to well-formed OWL either, what is important is that we have a semantic description. What we have found in threat/risk is that in conceptual UML models we have 90% of the expressiveness of OWL in addition to being able to assert some things OWL is very bad at, such as the time, context and provenance of statements. Keep in mind we are using UML based on a specific profile for this purpose.

 

What concerns me more is statement like we should refactor first and then look at the models. Valid refactoring at a syntax level has gone wrong every time I have seen it as what your syntax means gets confused and inconsistent. This becomes a barrier for implementation and interoperability. Whatever the language of expression, the model should be where the concepts and their relationships are figured out - we can then come up with more or more syntax representations for it. Doing it upside down will not, IMHO, lead to a usable result or widespread adoption.

 

-Cory

 

-----Original Message-----

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, November 24, 2015 8:21 AM

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: [hidden email]

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

 

That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

 

Regards,

Ivan

 

 

 

 

On 11/23/15, 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] [[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]> 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
|

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

Shawn Riley

Hi Folks,

There was another really good article discussing Object-Based Production (OBP) in the news. As some of you might be aware, I've been focused on applying Object-Based Production to cyber security / cyber threat intelligence since some of discussed this methodology at BlackHat 2010 in Vegas. It's the heart of what the Semantic eScience of Security paper was about and how it support the science of security core themes while modernizing analytic tradecraft. Here is a snippit of information about OBP and link to the article. 

Shawn

Object-based production is a concept being implemented as a whole-of-community initiative that fundamentally changes the way the IC organizes information and intelligence. Reduced to its simplest terms, OBP creates a conceptual “object” for people, places, and things and then uses that object as a “bucket” to store all information and intelligence produced about those people, places, and things. The object becomes the single point of convergence for all information and intelligence produced about a topic of interest to intelligence professionals. By extension, the objects also become the launching point to discover information and intelligence. Hence, OBP is not a tool or a technology, but a deliberate way of doing business.

While simple, OBP constitutes a revolutionary change in how the IC and the Department of Defense (DOD) organize information, particularly as it relates to discovery and analysis of information and intelligence. Historically, the IC and DOD organized and disseminated information and intelligence based on the organization that produced it. So retrieving all available information about a person, place, or thing was primarily performed by going to the individual repository of each data producer and/or understanding the sometimes unique naming conventions used by the different data producers to retrieve that organization’s information or intelligence about the same person, place, or thing. Consequently, analysts could conceivably omit or miss important information or erroneously assume gaps existed.

OBP aims to remedy this problem and increase information integration across the IC and DOD by creating a common landing zone for data that cross organizational and functional boundaries. Furthermore, this business model introduces analytic efficiency; it reduces the amount of time analysts spend organizing, structuring, and discovering information and intelligence across the enterprise. By extension, OBP can afford analysts more time for higher orders of analysis while reducing how long it takes to understand how new data relate to existing knowledge. A central premise of OBP is that when information is organized, its usefulness increases.

A concrete example best illustrates the organizing principle of OBP and how it would apply to the IC and DOD. Consider a professional baseball team and how OBP would create objects and organize information for all known people, places, and things associated with the team. At a minimum, “person” objects would be created for each individual directly associated with the team, including coaches, players, the general manager, executives, and so forth. As an example of person-object data, these objects would include characteristics such as a picture, height, weight, sex, position played, college attended, and so forth. The purpose is to create, whenever possible, objects distinguishable from other objects. This list of person-objects can be enduring over time and include current and/or past people objects or family or previous team relationships.

In a similar fashion, objects could be created for the physical locations associated with the team, including the stadium, training facility, parking lots, and players’ homes. The same could be done for “thing” objects associated with the team, such as baseballs, bats, uniforms, training equipment, team cars/buses/planes, and so forth.

With the baseball team’s objects established, producers could report information to the objects (for example, games, statistics, news for players, or stadium upgrades), which would serve as a centralized location to learn about activity or information related to the team. Also, relationships could be established between the objects to create groupings of objects that represent issues or topics. For example, a grouping of people-objects could be created to stand for the infield or outfield, coaching staff, or team executives. Tangential topics/issues such as “professional baseball players involved in charity” could be established as well. Events or activities (such as games) and the objects associated with them could also be described in this object-centric data construct. Moreover, the concept could expand to cover all teams in a professional baseball league or other professional sports or abstract concepts that include people, places, or things.

Similar to the example above, the IC and DOD will create objects for the people, places, things, and concepts that are the focus of intelligence and military operations. Topics could include South China Sea territorial disputes, transnational criminal organizations, Afghan elections, and illicit trade. Much like the sports example, IC and DOD issues have associated people, places, and concepts that could be objects for knowledge management.

Read the whole article here: https://www.govtechworks.com/transforming-defense-analysis/#gs.MnGchY0


On Tue, Nov 24, 2015 at 3:49 PM, Terry MacDonald <[hidden email]> wrote:

" Doing it upside down will not, IMHO, lead to a usable result or widespread adoption."

 

This comment is where I have a slight problem. The upside down development process may not be perfect, but it has worked 'well enough' up to this point.  OASIS CTI is the largest standards group that OASIS has had so far as I understand it, so STIX/TAXII/CybOX must be fairly useful and have reached a reasonable adoption even in its current bohemian state to have generated such interest.

 

STIX itself is IMHO empirical evidence that sometimes good enough is good enough.

 

That said, if there is a way that we can improve the model and the way we derive serializations without impacting implementers onerously, then I am very keen to see it.

 

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]

 

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; Shawn Riley <[hidden email]>
Cc: [hidden email]
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

Ivan,

This is a discussion we should have. I am not opposed to well-formed OWL either, what is important is that we have a semantic description. What we have found in threat/risk is that in conceptual UML models we have 90% of the expressiveness of OWL in addition to being able to assert some things OWL is very bad at, such as the time, context and provenance of statements. Keep in mind we are using UML based on a specific profile for this purpose.

 

What concerns me more is statement like we should refactor first and then look at the models. Valid refactoring at a syntax level has gone wrong every time I have seen it as what your syntax means gets confused and inconsistent. This becomes a barrier for implementation and interoperability. Whatever the language of expression, the model should be where the concepts and their relationships are figured out - we can then come up with more or more syntax representations for it. Doing it upside down will not, IMHO, lead to a usable result or widespread adoption.

 

-Cory

 

-----Original Message-----

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, November 24, 2015 8:21 AM

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: [hidden email]

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

 

That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

 

Regards,

Ivan

 

 

 

 

On 11/23/15, 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] [[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]> 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
|

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

Bush, Jonathan

Seems like a powerful concept Shawn.

 

This might be obvious, but is your hypothesis that JSON-LD is the enabling technology to make OBP happen?  Is that the ONLY way to implement OBP?

Also, I see that the concept started in the DoD.  How has the implementation of OBP gone there?  Has it been attempted (from an implementation perspective) outside of the DoD, in commercial land anywhere?

 

Sorry, probably too many questions at once…

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 AM
To: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

Hi Folks,

There was another really good article discussing Object-Based Production (OBP) in the news. As some of you might be aware, I've been focused on applying Object-Based Production to cyber security / cyber threat intelligence since some of discussed this methodology at BlackHat 2010 in Vegas. It's the heart of what the Semantic eScience of Security paper was about and how it support the science of security core themes while modernizing analytic tradecraft. Here is a snippit of information about OBP and link to the article. 

Shawn

Object-based production is a concept being implemented as a whole-of-community initiative that fundamentally changes the way the IC organizes information and intelligence. Reduced to its simplest terms, OBP creates a conceptual “object” for people, places, and things and then uses that object as a “bucket” to store all information and intelligence produced about those people, places, and things. The object becomes the single point of convergence for all information and intelligence produced about a topic of interest to intelligence professionals. By extension, the objects also become the launching point to discover information and intelligence. Hence, OBP is not a tool or a technology, but a deliberate way of doing business.

While simple, OBP constitutes a revolutionary change in how the IC and the Department of Defense (DOD) organize information, particularly as it relates to discovery and analysis of information and intelligence. Historically, the IC and DOD organized and disseminated information and intelligence based on the organization that produced it. So retrieving all available information about a person, place, or thing was primarily performed by going to the individual repository of each data producer and/or understanding the sometimes unique naming conventions used by the different data producers to retrieve that organization’s information or intelligence about the same person, place, or thing. Consequently, analysts could conceivably omit or miss important information or erroneously assume gaps existed.

OBP aims to remedy this problem and increase information integration across the IC and DOD by creating a common landing zone for data that cross organizational and functional boundaries. Furthermore, this business model introduces analytic efficiency; it reduces the amount of time analysts spend organizing, structuring, and discovering information and intelligence across the enterprise. By extension, OBP can afford analysts more time for higher orders of analysis while reducing how long it takes to understand how new data relate to existing knowledge. A central premise of OBP is that when information is organized, its usefulness increases.

A concrete example best illustrates the organizing principle of OBP and how it would apply to the IC and DOD. Consider a professional baseball team and how OBP would create objects and organize information for all known people, places, and things associated with the team. At a minimum, “person” objects would be created for each individual directly associated with the team, including coaches, players, the general manager, executives, and so forth. As an example of person-object data, these objects would include characteristics such as a picture, height, weight, sex, position played, college attended, and so forth. The purpose is to create, whenever possible, objects distinguishable from other objects. This list of person-objects can be enduring over time and include current and/or past people objects or family or previous team relationships.

In a similar fashion, objects could be created for the physical locations associated with the team, including the stadium, training facility, parking lots, and players’ homes. The same could be done for “thing” objects associated with the team, such as baseballs, bats, uniforms, training equipment, team cars/buses/planes, and so forth.

With the baseball team’s objects established, producers could report information to the objects (for example, games, statistics, news for players, or stadium upgrades), which would serve as a centralized location to learn about activity or information related to the team. Also, relationships could be established between the objects to create groupings of objects that represent issues or topics. For example, a grouping of people-objects could be created to stand for the infield or outfield, coaching staff, or team executives. Tangential topics/issues such as “professional baseball players involved in charity” could be established as well. Events or activities (such as games) and the objects associated with them could also be described in this object-centric data construct. Moreover, the concept could expand to cover all teams in a professional baseball league or other professional sports or abstract concepts that include people, places, or things.

Similar to the example above, the IC and DOD will create objects for the people, places, things, and concepts that are the focus of intelligence and military operations. Topics could include South China Sea territorial disputes, transnational criminal organizations, Afghan elections, and illicit trade. Much like the sports example, IC and DOD issues have associated people, places, and concepts that could be objects for knowledge management.

Read the whole article here: https://www.govtechworks.com/transforming-defense-analysis/#gs.MnGchY0

 

On Tue, Nov 24, 2015 at 3:49 PM, Terry MacDonald <[hidden email]> wrote:

" Doing it upside down will not, IMHO, lead to a usable result or widespread adoption."

 

This comment is where I have a slight problem. The upside down development process may not be perfect, but it has worked 'well enough' up to this point.  OASIS CTI is the largest standards group that OASIS has had so far as I understand it, so STIX/TAXII/CybOX must be fairly useful and have reached a reasonable adoption even in its current bohemian state to have generated such interest.

 

STIX itself is IMHO empirical evidence that sometimes good enough is good enough.

 

That said, if there is a way that we can improve the model and the way we derive serializations without impacting implementers onerously, then I am very keen to see it.

 

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]

 

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; Shawn Riley <[hidden email]>
Cc: [hidden email]
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

Ivan,

This is a discussion we should have. I am not opposed to well-formed OWL either, what is important is that we have a semantic description. What we have found in threat/risk is that in conceptual UML models we have 90% of the expressiveness of OWL in addition to being able to assert some things OWL is very bad at, such as the time, context and provenance of statements. Keep in mind we are using UML based on a specific profile for this purpose.

 

What concerns me more is statement like we should refactor first and then look at the models. Valid refactoring at a syntax level has gone wrong every time I have seen it as what your syntax means gets confused and inconsistent. This becomes a barrier for implementation and interoperability. Whatever the language of expression, the model should be where the concepts and their relationships are figured out - we can then come up with more or more syntax representations for it. Doing it upside down will not, IMHO, lead to a usable result or widespread adoption.

 

-Cory

 

-----Original Message-----

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, November 24, 2015 8:21 AM

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: [hidden email]

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

 

That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

 

Regards,

Ivan

 

 

 

 

On 11/23/15, 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] [[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]> 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>

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|

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

Shawn Riley
Hi Jonathan,

I'm not sure if you read another article I shared in the LinkedIn post at the start of this thread or in a follow up knowledge sharing article on OBP & ABI but it's worth reading since it's vendors discussing OBP. I thought the CTI vendors might relate better to hearing other vendors discuss OBP rather than hearing it from an old CTI analyst like myself. 

Organizing the Knowns  - http://www.kmimediagroup.com/gif/424-articles-gif/organizing-the-knowns/6361-organizing-the-knowns

I wrote another article on LinkedIn earlier this year to share knowledge about OBP & ABI as applied to cyber. Below is a section that I believe answers some of your questions. I'll put a link to the full article at the end of the couple paragraphs. 

Object-Based Production of Knowledge

In terms of Semantic eScience of Security, one might think of ontologies in OWL/RDF as acting as an Object Description Framework (ODF) that enables Object-Based Production of knowledge from each of the common language used in the Cybersecurity Measurement and Management Architecture. These objects are then mapped to the ontology that defines the conceptual semantic object model. The individual semantic object models for each data set (STIX, MAEC, CVE, etc.) are interconnected by a unifying object model.

Object-Based Production (OBP) works by representing these various pieces of data as ‘objects’ in order to gain greater insights about the nature of the object, the object’s attributes, the relationships or associations amongst objects, and observed activity. Through the modeling of data as objects, attributes, associations, and activities it becomes dramatically easier to understand and categorize objects, often through just an examination of its attributes.  It also helps in the identification of behaviors normally attributed to an object. In short, it represents and organizes the data in a manner similar to the way humans think about objects in the natural world.  This then enables a focus on the creation and organization of knowledge about what is known so organizations can to do a better job of discovering the unknown through a methodology known as Activity-Based Intelligence (ABI).

In order to get a complete description of an object, it may require multiple statements to be made where each statement describes a specific attribute or association of the object.  This collection of statements provides a description of an object and can be easily added to by just adding additional statements as new knowledge about the object is discovered. 
Source: https://www.linkedin.com/pulse/object-based-production-activity-based-intelligence-shawn-riley

It's also worth pointing out that OBP is exactly what Google has done to create the Google Knowledge Graph and what Facebook has done to create their Social Graph. It all requires semantic ontologies and the serialization formats to encode that semantic information when knowledge is shared. That is why Google has incorporated JSON-LD into its baseline and it is used when connecting things to the Google Knowledge Graph.  

We've been trying to apply this to cyber threat intelligence using STIX / CYBOX and it was the plan for this to happen with STIX 2.0 until the whole JSON direction sidetracked it to keep it on the legacy path instead of the new OBP path enabled by semantic ontologies and serializations. 

I don't want to overload anyone with information so have a look at the information I provided and please feel free to reach out with more questions. 

Best,
Shawn


On Wed, Nov 25, 2015 at 9:19 AM, Bush, Jonathan <[hidden email]> wrote:

Seems like a powerful concept Shawn.

 

This might be obvious, but is your hypothesis that JSON-LD is the enabling technology to make OBP happen?  Is that the ONLY way to implement OBP?

Also, I see that the concept started in the DoD.  How has the implementation of OBP gone there?  Has it been attempted (from an implementation perspective) outside of the DoD, in commercial land anywhere?

 

Sorry, probably too many questions at once…

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 AM
To: [hidden email]


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

 

Hi Folks,

There was another really good article discussing Object-Based Production (OBP) in the news. As some of you might be aware, I've been focused on applying Object-Based Production to cyber security / cyber threat intelligence since some of discussed this methodology at BlackHat 2010 in Vegas. It's the heart of what the Semantic eScience of Security paper was about and how it support the science of security core themes while modernizing analytic tradecraft. Here is a snippit of information about OBP and link to the article. 

Shawn

Object-based production is a concept being implemented as a whole-of-community initiative that fundamentally changes the way the IC organizes information and intelligence. Reduced to its simplest terms, OBP creates a conceptual “object” for people, places, and things and then uses that object as a “bucket” to store all information and intelligence produced about those people, places, and things. The object becomes the single point of convergence for all information and intelligence produced about a topic of interest to intelligence professionals. By extension, the objects also become the launching point to discover information and intelligence. Hence, OBP is not a tool or a technology, but a deliberate way of doing business.

While simple, OBP constitutes a revolutionary change in how the IC and the Department of Defense (DOD) organize information, particularly as it relates to discovery and analysis of information and intelligence. Historically, the IC and DOD organized and disseminated information and intelligence based on the organization that produced it. So retrieving all available information about a person, place, or thing was primarily performed by going to the individual repository of each data producer and/or understanding the sometimes unique naming conventions used by the different data producers to retrieve that organization’s information or intelligence about the same person, place, or thing. Consequently, analysts could conceivably omit or miss important information or erroneously assume gaps existed.

OBP aims to remedy this problem and increase information integration across the IC and DOD by creating a common landing zone for data that cross organizational and functional boundaries. Furthermore, this business model introduces analytic efficiency; it reduces the amount of time analysts spend organizing, structuring, and discovering information and intelligence across the enterprise. By extension, OBP can afford analysts more time for higher orders of analysis while reducing how long it takes to understand how new data relate to existing knowledge. A central premise of OBP is that when information is organized, its usefulness increases.

A concrete example best illustrates the organizing principle of OBP and how it would apply to the IC and DOD. Consider a professional baseball team and how OBP would create objects and organize information for all known people, places, and things associated with the team. At a minimum, “person” objects would be created for each individual directly associated with the team, including coaches, players, the general manager, executives, and so forth. As an example of person-object data, these objects would include characteristics such as a picture, height, weight, sex, position played, college attended, and so forth. The purpose is to create, whenever possible, objects distinguishable from other objects. This list of person-objects can be enduring over time and include current and/or past people objects or family or previous team relationships.

In a similar fashion, objects could be created for the physical locations associated with the team, including the stadium, training facility, parking lots, and players’ homes. The same could be done for “thing” objects associated with the team, such as baseballs, bats, uniforms, training equipment, team cars/buses/planes, and so forth.

With the baseball team’s objects established, producers could report information to the objects (for example, games, statistics, news for players, or stadium upgrades), which would serve as a centralized location to learn about activity or information related to the team. Also, relationships could be established between the objects to create groupings of objects that represent issues or topics. For example, a grouping of people-objects could be created to stand for the infield or outfield, coaching staff, or team executives. Tangential topics/issues such as “professional baseball players involved in charity” could be established as well. Events or activities (such as games) and the objects associated with them could also be described in this object-centric data construct. Moreover, the concept could expand to cover all teams in a professional baseball league or other professional sports or abstract concepts that include people, places, or things.

Similar to the example above, the IC and DOD will create objects for the people, places, things, and concepts that are the focus of intelligence and military operations. Topics could include South China Sea territorial disputes, transnational criminal organizations, Afghan elections, and illicit trade. Much like the sports example, IC and DOD issues have associated people, places, and concepts that could be objects for knowledge management.

Read the whole article here: https://www.govtechworks.com/transforming-defense-analysis/#gs.MnGchY0

 

On Tue, Nov 24, 2015 at 3:49 PM, Terry MacDonald <[hidden email]> wrote:

" Doing it upside down will not, IMHO, lead to a usable result or widespread adoption."

 

This comment is where I have a slight problem. The upside down development process may not be perfect, but it has worked 'well enough' up to this point.  OASIS CTI is the largest standards group that OASIS has had so far as I understand it, so STIX/TAXII/CybOX must be fairly useful and have reached a reasonable adoption even in its current bohemian state to have generated such interest.

 

STIX itself is IMHO empirical evidence that sometimes good enough is good enough.

 

That said, if there is a way that we can improve the model and the way we derive serializations without impacting implementers onerously, then I am very keen to see it.

 

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]

 

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; Shawn Riley <[hidden email]>
Cc: [hidden email]
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

Ivan,

This is a discussion we should have. I am not opposed to well-formed OWL either, what is important is that we have a semantic description. What we have found in threat/risk is that in conceptual UML models we have 90% of the expressiveness of OWL in addition to being able to assert some things OWL is very bad at, such as the time, context and provenance of statements. Keep in mind we are using UML based on a specific profile for this purpose.

 

What concerns me more is statement like we should refactor first and then look at the models. Valid refactoring at a syntax level has gone wrong every time I have seen it as what your syntax means gets confused and inconsistent. This becomes a barrier for implementation and interoperability. Whatever the language of expression, the model should be where the concepts and their relationships are figured out - we can then come up with more or more syntax representations for it. Doing it upside down will not, IMHO, lead to a usable result or widespread adoption.

 

-Cory

 

-----Original Message-----

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, November 24, 2015 8:21 AM

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: [hidden email]

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

 

That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

 

Regards,

Ivan

 

 

 

 

On 11/23/15, 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] [[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]> 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>

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Reply | Threaded
Open this post in threaded view
|

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

Shawn Riley

One other point, the Science of Cybersecurity paper I published and shared with the STIX community that discussed the "Semantic eScience of Security" platform was to show how these OBP & ABI methodologies could be used as a CTI platform. I know the science of security  stuff is not of interest to most of the STIX community but setting that aside, the rest of the paper and focus was on OBP & ABI as applied to CTI. 

Shawn

On Nov 25, 2015 9:37 AM, "Shawn Riley" <[hidden email]> wrote:
Hi Jonathan,

I'm not sure if you read another article I shared in the LinkedIn post at the start of this thread or in a follow up knowledge sharing article on OBP & ABI but it's worth reading since it's vendors discussing OBP. I thought the CTI vendors might relate better to hearing other vendors discuss OBP rather than hearing it from an old CTI analyst like myself. 

Organizing the Knowns  - http://www.kmimediagroup.com/gif/424-articles-gif/organizing-the-knowns/6361-organizing-the-knowns

I wrote another article on LinkedIn earlier this year to share knowledge about OBP & ABI as applied to cyber. Below is a section that I believe answers some of your questions. I'll put a link to the full article at the end of the couple paragraphs. 

Object-Based Production of Knowledge

In terms of Semantic eScience of Security, one might think of ontologies in OWL/RDF as acting as an Object Description Framework (ODF) that enables Object-Based Production of knowledge from each of the common language used in the Cybersecurity Measurement and Management Architecture. These objects are then mapped to the ontology that defines the conceptual semantic object model. The individual semantic object models for each data set (STIX, MAEC, CVE, etc.) are interconnected by a unifying object model.

Object-Based Production (OBP) works by representing these various pieces of data as ‘objects’ in order to gain greater insights about the nature of the object, the object’s attributes, the relationships or associations amongst objects, and observed activity. Through the modeling of data as objects, attributes, associations, and activities it becomes dramatically easier to understand and categorize objects, often through just an examination of its attributes.  It also helps in the identification of behaviors normally attributed to an object. In short, it represents and organizes the data in a manner similar to the way humans think about objects in the natural world.  This then enables a focus on the creation and organization of knowledge about what is known so organizations can to do a better job of discovering the unknown through a methodology known as Activity-Based Intelligence (ABI).

In order to get a complete description of an object, it may require multiple statements to be made where each statement describes a specific attribute or association of the object.  This collection of statements provides a description of an object and can be easily added to by just adding additional statements as new knowledge about the object is discovered. 
Source: https://www.linkedin.com/pulse/object-based-production-activity-based-intelligence-shawn-riley

It's also worth pointing out that OBP is exactly what Google has done to create the Google Knowledge Graph and what Facebook has done to create their Social Graph. It all requires semantic ontologies and the serialization formats to encode that semantic information when knowledge is shared. That is why Google has incorporated JSON-LD into its baseline and it is used when connecting things to the Google Knowledge Graph.  

We've been trying to apply this to cyber threat intelligence using STIX / CYBOX and it was the plan for this to happen with STIX 2.0 until the whole JSON direction sidetracked it to keep it on the legacy path instead of the new OBP path enabled by semantic ontologies and serializations. 

I don't want to overload anyone with information so have a look at the information I provided and please feel free to reach out with more questions. 

Best,
Shawn


On Wed, Nov 25, 2015 at 9:19 AM, Bush, Jonathan <[hidden email]> wrote:

Seems like a powerful concept Shawn.

 

This might be obvious, but is your hypothesis that JSON-LD is the enabling technology to make OBP happen?  Is that the ONLY way to implement OBP?

Also, I see that the concept started in the DoD.  How has the implementation of OBP gone there?  Has it been attempted (from an implementation perspective) outside of the DoD, in commercial land anywhere?

 

Sorry, probably too many questions at once…

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 AM
To: [hidden email]


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

 

Hi Folks,

There was another really good article discussing Object-Based Production (OBP) in the news. As some of you might be aware, I've been focused on applying Object-Based Production to cyber security / cyber threat intelligence since some of discussed this methodology at BlackHat 2010 in Vegas. It's the heart of what the Semantic eScience of Security paper was about and how it support the science of security core themes while modernizing analytic tradecraft. Here is a snippit of information about OBP and link to the article. 

Shawn

Object-based production is a concept being implemented as a whole-of-community initiative that fundamentally changes the way the IC organizes information and intelligence. Reduced to its simplest terms, OBP creates a conceptual “object” for people, places, and things and then uses that object as a “bucket” to store all information and intelligence produced about those people, places, and things. The object becomes the single point of convergence for all information and intelligence produced about a topic of interest to intelligence professionals. By extension, the objects also become the launching point to discover information and intelligence. Hence, OBP is not a tool or a technology, but a deliberate way of doing business.

While simple, OBP constitutes a revolutionary change in how the IC and the Department of Defense (DOD) organize information, particularly as it relates to discovery and analysis of information and intelligence. Historically, the IC and DOD organized and disseminated information and intelligence based on the organization that produced it. So retrieving all available information about a person, place, or thing was primarily performed by going to the individual repository of each data producer and/or understanding the sometimes unique naming conventions used by the different data producers to retrieve that organization’s information or intelligence about the same person, place, or thing. Consequently, analysts could conceivably omit or miss important information or erroneously assume gaps existed.

OBP aims to remedy this problem and increase information integration across the IC and DOD by creating a common landing zone for data that cross organizational and functional boundaries. Furthermore, this business model introduces analytic efficiency; it reduces the amount of time analysts spend organizing, structuring, and discovering information and intelligence across the enterprise. By extension, OBP can afford analysts more time for higher orders of analysis while reducing how long it takes to understand how new data relate to existing knowledge. A central premise of OBP is that when information is organized, its usefulness increases.

A concrete example best illustrates the organizing principle of OBP and how it would apply to the IC and DOD. Consider a professional baseball team and how OBP would create objects and organize information for all known people, places, and things associated with the team. At a minimum, “person” objects would be created for each individual directly associated with the team, including coaches, players, the general manager, executives, and so forth. As an example of person-object data, these objects would include characteristics such as a picture, height, weight, sex, position played, college attended, and so forth. The purpose is to create, whenever possible, objects distinguishable from other objects. This list of person-objects can be enduring over time and include current and/or past people objects or family or previous team relationships.

In a similar fashion, objects could be created for the physical locations associated with the team, including the stadium, training facility, parking lots, and players’ homes. The same could be done for “thing” objects associated with the team, such as baseballs, bats, uniforms, training equipment, team cars/buses/planes, and so forth.

With the baseball team’s objects established, producers could report information to the objects (for example, games, statistics, news for players, or stadium upgrades), which would serve as a centralized location to learn about activity or information related to the team. Also, relationships could be established between the objects to create groupings of objects that represent issues or topics. For example, a grouping of people-objects could be created to stand for the infield or outfield, coaching staff, or team executives. Tangential topics/issues such as “professional baseball players involved in charity” could be established as well. Events or activities (such as games) and the objects associated with them could also be described in this object-centric data construct. Moreover, the concept could expand to cover all teams in a professional baseball league or other professional sports or abstract concepts that include people, places, or things.

Similar to the example above, the IC and DOD will create objects for the people, places, things, and concepts that are the focus of intelligence and military operations. Topics could include South China Sea territorial disputes, transnational criminal organizations, Afghan elections, and illicit trade. Much like the sports example, IC and DOD issues have associated people, places, and concepts that could be objects for knowledge management.

Read the whole article here: https://www.govtechworks.com/transforming-defense-analysis/#gs.MnGchY0

 

On Tue, Nov 24, 2015 at 3:49 PM, Terry MacDonald <[hidden email]> wrote:

" Doing it upside down will not, IMHO, lead to a usable result or widespread adoption."

 

This comment is where I have a slight problem. The upside down development process may not be perfect, but it has worked 'well enough' up to this point.  OASIS CTI is the largest standards group that OASIS has had so far as I understand it, so STIX/TAXII/CybOX must be fairly useful and have reached a reasonable adoption even in its current bohemian state to have generated such interest.

 

STIX itself is IMHO empirical evidence that sometimes good enough is good enough.

 

That said, if there is a way that we can improve the model and the way we derive serializations without impacting implementers onerously, then I am very keen to see it.

 

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]

 

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>; Shawn Riley <[hidden email]>
Cc: [hidden email]
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

Ivan,

This is a discussion we should have. I am not opposed to well-formed OWL either, what is important is that we have a semantic description. What we have found in threat/risk is that in conceptual UML models we have 90% of the expressiveness of OWL in addition to being able to assert some things OWL is very bad at, such as the time, context and provenance of statements. Keep in mind we are using UML based on a specific profile for this purpose.

 

What concerns me more is statement like we should refactor first and then look at the models. Valid refactoring at a syntax level has gone wrong every time I have seen it as what your syntax means gets confused and inconsistent. This becomes a barrier for implementation and interoperability. Whatever the language of expression, the model should be where the concepts and their relationships are figured out - we can then come up with more or more syntax representations for it. Doing it upside down will not, IMHO, lead to a usable result or widespread adoption.

 

-Cory

 

-----Original Message-----

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, November 24, 2015 8:21 AM

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: [hidden email]

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

 

That doesn’t answer my question. You’re still not getting a true ontology - just various auto-generated schemas based on UML, which I have yet to see be proven as useful. My inclination that we really need to rebuild STIX/CybOX from the ground up in RDF/OWL, including on making sure that we have the right set of instances, datatype properties, object properties, etc. if we JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel that JSON schema offers the best value in the interim and will help driven adoption. Again, we can always revisit the JSON-LD question when we are ready.

 

Regards,

Ivan

 

 

 

 

On 11/23/15, 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] [[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]> 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>

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

JA
Reply | Threaded
Open this post in threaded view
|

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

JA
In reply to this post by Bush, Jonathan
XORCISM took a quite similar approach...
While one objective was to build a PoC to demonstrate and validate the
value, a "platform-dependent" PoC was built were:
- A Relational Database schema(s) (one way of materializing the UMLs)
is representing the "Ontology"
- The Database/Ontology was built based on (Common) Languages and Formats
- The technical interoperability is demonstrated/validated by tools
interacting with the Enumerations and the Database
- The tools are making use of an "API" where all the -Objects- can be
manipulated
- The "API" (Semantic Interoperability) was generated automatically
from the Database/Ontology, and so the Objects inherit from their
representation (constructs) found in the Common Languages/Models
- The Knowledge Repositories are directly stored in the Database
- The data stored in the Database are Making Security instantly Measurable

(Again, it's just a PoC.)

A better representation for the Ontology is possible.
BUT, all the advantages and benefits would be obtained, only, -IF-,
the "(structured) raw data" can be easily and 'directly' mapped with
the Ontology.
JSON alone does not allow this
JSON-LD could potentially
XML can
(with OWL/RDF)

Parts of the PoC: https://github.com/athiasjerome/XORCISM

PS: I found a lot of optimizations (and missing relationships) for the
current STIX (and other) Data Models while working on XORCISM...


2015-11-25 17:19 GMT+03:00 Bush, Jonathan <[hidden email]>:

> Seems like a powerful concept Shawn.
>
>
>
> This might be obvious, but is your hypothesis that JSON-LD is the enabling
> technology to make OBP happen?  Is that the ONLY way to implement OBP?
>
> Also, I see that the concept started in the DoD.  How has the implementation
> of OBP gone there?  Has it been attempted (from an implementation
> perspective) outside of the DoD, in commercial land anywhere?
>
>
>
> Sorry, probably too many questions at once…
>
>
>
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Shawn Riley
> Sent: Wednesday, November 25, 2015 6:51 AM
> To: [hidden email]
>
>
> Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is
> why...
>
>
>
> Hi Folks,
>
> There was another really good article discussing Object-Based Production
> (OBP) in the news. As some of you might be aware, I've been focused on
> applying Object-Based Production to cyber security / cyber threat
> intelligence since some of discussed this methodology at BlackHat 2010 in
> Vegas. It's the heart of what the Semantic eScience of Security paper was
> about and how it support the science of security core themes while
> modernizing analytic tradecraft. Here is a snippit of information about OBP
> and link to the article.
>
> Shawn
>
> Object-based production is a concept being implemented as a
> whole-of-community initiative that fundamentally changes the way the IC
> organizes information and intelligence. Reduced to its simplest terms, OBP
> creates a conceptual “object” for people, places, and things and then uses
> that object as a “bucket” to store all information and intelligence produced
> about those people, places, and things. The object becomes the single point
> of convergence for all information and intelligence produced about a topic
> of interest to intelligence professionals. By extension, the objects also
> become the launching point to discover information and intelligence. Hence,
> OBP is not a tool or a technology, but a deliberate way of doing business.
>
> While simple, OBP constitutes a revolutionary change in how the IC and the
> Department of Defense (DOD) organize information, particularly as it relates
> to discovery and analysis of information and intelligence. Historically, the
> IC and DOD organized and disseminated information and intelligence based on
> the organization that produced it. So retrieving all available information
> about a person, place, or thing was primarily performed by going to the
> individual repository of each data producer and/or understanding the
> sometimes unique naming conventions used by the different data producers to
> retrieve that organization’s information or intelligence about the same
> person, place, or thing. Consequently, analysts could conceivably omit or
> miss important information or erroneously assume gaps existed.
>
> OBP aims to remedy this problem and increase information integration across
> the IC and DOD by creating a common landing zone for data that cross
> organizational and functional boundaries. Furthermore, this business model
> introduces analytic efficiency; it reduces the amount of time analysts spend
> organizing, structuring, and discovering information and intelligence across
> the enterprise. By extension, OBP can afford analysts more time for higher
> orders of analysis while reducing how long it takes to understand how new
> data relate to existing knowledge. A central premise of OBP is that when
> information is organized, its usefulness increases.
>
> A concrete example best illustrates the organizing principle of OBP and how
> it would apply to the IC and DOD. Consider a professional baseball team and
> how OBP would create objects and organize information for all known people,
> places, and things associated with the team. At a minimum, “person” objects
> would be created for each individual directly associated with the team,
> including coaches, players, the general manager, executives, and so forth.
> As an example of person-object data, these objects would include
> characteristics such as a picture, height, weight, sex, position played,
> college attended, and so forth. The purpose is to create, whenever possible,
> objects distinguishable from other objects. This list of person-objects can
> be enduring over time and include current and/or past people objects or
> family or previous team relationships.
>
> In a similar fashion, objects could be created for the physical locations
> associated with the team, including the stadium, training facility, parking
> lots, and players’ homes. The same could be done for “thing” objects
> associated with the team, such as baseballs, bats, uniforms, training
> equipment, team cars/buses/planes, and so forth.
>
> With the baseball team’s objects established, producers could report
> information to the objects (for example, games, statistics, news for
> players, or stadium upgrades), which would serve as a centralized location
> to learn about activity or information related to the team. Also,
> relationships could be established between the objects to create groupings
> of objects that represent issues or topics. For example, a grouping of
> people-objects could be created to stand for the infield or outfield,
> coaching staff, or team executives. Tangential topics/issues such as
> “professional baseball players involved in charity” could be established as
> well. Events or activities (such as games) and the objects associated with
> them could also be described in this object-centric data construct.
> Moreover, the concept could expand to cover all teams in a professional
> baseball league or other professional sports or abstract concepts that
> include people, places, or things.
>
> Similar to the example above, the IC and DOD will create objects for the
> people, places, things, and concepts that are the focus of intelligence and
> military operations. Topics could include South China Sea territorial
> disputes, transnational criminal organizations, Afghan elections, and
> illicit trade. Much like the sports example, IC and DOD issues have
> associated people, places, and concepts that could be objects for knowledge
> management.
>
> Read the whole article here:
> https://www.govtechworks.com/transforming-defense-analysis/#gs.MnGchY0
>
>
>
> On Tue, Nov 24, 2015 at 3:49 PM, Terry MacDonald <[hidden email]> wrote:
>
> " Doing it upside down will not, IMHO, lead to a usable result or widespread
> adoption."
>
>
>
> This comment is where I have a slight problem. The upside down development
> process may not be perfect, but it has worked 'well enough' up to this
> point.  OASIS CTI is the largest standards group that OASIS has had so far
> as I understand it, so STIX/TAXII/CybOX must be fairly useful and have
> reached a reasonable adoption even in its current bohemian state to have
> generated such interest.
>
>
>
> STIX itself is IMHO empirical evidence that sometimes good enough is good
> enough.
>
>
>
> That said, if there is a way that we can improve the model and the way we
> derive serializations without impacting implementers onerously, then I am
> very keen to see it.
>
>
>
> Cheers
>
>
>
> Terry MacDonald
>
> Senior STIX Subject Matter Expert
>
> SOLTRA | An FS-ISAC and DTCC Company
>
> +61 (407) 203 206 | [hidden email]
>
>
>
>
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Cory Casanave
> Sent: Wednesday, 25 November 2015 2:03 AM
> To: Kirillov, Ivan A. <[hidden email]>; Trey Darley <[hidden email]>;
> Shawn Riley <[hidden email]>
> Cc: [hidden email]
> Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is
> why...
>
>
>
> Ivan,
>
> This is a discussion we should have. I am not opposed to well-formed OWL
> either, what is important is that we have a semantic description. What we
> have found in threat/risk is that in conceptual UML models we have 90% of
> the expressiveness of OWL in addition to being able to assert some things
> OWL is very bad at, such as the time, context and provenance of statements.
> Keep in mind we are using UML based on a specific profile for this purpose.
>
>
>
> What concerns me more is statement like we should refactor first and then
> look at the models. Valid refactoring at a syntax level has gone wrong every
> time I have seen it as what your syntax means gets confused and
> inconsistent. This becomes a barrier for implementation and
> interoperability. Whatever the language of expression, the model should be
> where the concepts and their relationships are figured out - we can then
> come up with more or more syntax representations for it. Doing it upside
> down will not, IMHO, lead to a usable result or widespread adoption.
>
>
>
> -Cory
>
>
>
> -----Original Message-----
>
> From: Kirillov, Ivan A. [mailto:[hidden email]]
>
> Sent: Tuesday, November 24, 2015 8:21 AM
>
> To: Cory Casanave; Trey Darley; Shawn Riley
>
> Cc: [hidden email]
>
> Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is
> why...
>
>
>
> That doesn’t answer my question. You’re still not getting a true ontology -
> just various auto-generated schemas based on UML, which I have yet to see be
> proven as useful. My inclination that we really need to rebuild STIX/CybOX
> from the ground up in RDF/OWL, including on making sure that we have the
> right set of instances, datatype properties, object properties, etc. if we
> JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel
> that JSON schema offers the best value in the interim and will help driven
> adoption. Again, we can always revisit the JSON-LD question when we are
> ready.
>
>
>
> Regards,
>
> Ivan
>
>
>
>
>
>
>
>
>
> On 11/23/15, 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>
>
>
>
>
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email in error, please
> notify us immediately and delete the email and any attachments from your
> system. The recipient should check this email and any attachments for the
> presence of viruses.  The company accepts no liability for any damage caused
> by any virus transmitted by this email.

This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/

123