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

Shawn Riley
Just a quick reminder, the default way OBP with its semantic ontologies and serializations visualizes the OBP data is in a labeled directed-graph which is how humans think about data. The Soltra slide showing how human's visualize CTI data is a human drawn labeled directed-graph that is 99% identical to how the technology would present OBP data to humans. 




On Wed, Nov 25, 2015 at 11:01 AM, Jerome Athias <[hidden email]> wrote:
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
>
> <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 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/

Soltra slide - how humans view intelligence.PNG (145K) 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...

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

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <[hidden email]>
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <[hidden email]> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <[hidden email]>
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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

Terry MacDonald-3

With all due respect, I’ll wait until I can make an informed decision on the pluses and minuses of the JSON-LD approach once it’s been presented.

 

Any idea when that will be? Is it within the next two weeks or so? It will help me understand when we can finish this discussion, decide one way or the other, and move on

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: Shawn Riley [mailto:[hidden email]]
Sent: Thursday, 26 November 2015 6:51 AM
To: Terry MacDonald <[hidden email]>
Cc: [hidden email]; [hidden email]; Jonathan Bush (DTCC) <[hidden email]>
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <[hidden email]> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <[hidden email]>
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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
Hi Terry,

I'd check with Sean B. on the presentation as he has the lead on it. 

I noticed your from Soltra which supports the Financial Services Industry. I thought the below article might be of interest and resonate with those from the Financial Services Industry. 

5 Ways Semantic Technology Is Transforming the Financial Services Industry

Semantic search intuitively finds and connects relevant data across the enterprise. Innovation in this technology is helping organizations simplify and transform operations.


Best,
Shawn

On Wed, Nov 25, 2015 at 3:26 PM, Terry MacDonald <[hidden email]> wrote:

With all due respect, I’ll wait until I can make an informed decision on the pluses and minuses of the JSON-LD approach once it’s been presented.

 

Any idea when that will be? Is it within the next two weeks or so? It will help me understand when we can finish this discussion, decide one way or the other, and move on

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: Shawn Riley [mailto:[hidden email]]
Sent: Thursday, 26 November 2015 6:51 AM
To: Terry MacDonald <[hidden email]>
Cc: [hidden email]; [hidden email]; Jonathan Bush (DTCC) <[hidden email]>


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

 

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <[hidden email]> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <[hidden email]>
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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

Jordan, Bret
In reply to this post by Shawn Riley
The OASIS TC is currently voting on the MTI binding.  That vote should be finalized Friday December 4th.  If JSON wins, we will let this user group know so the vendors and groups that have been waiting can start writing code.


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 25, 2015, at 12:51, Shawn Riley <[hidden email]> wrote:

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <[hidden email]> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

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

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <[hidden email]>
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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" class="">+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.

 



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

Jordan, Bret
In reply to this post by Shawn Riley
You do not need JSON-LD or RDF or OWL to do this.  All you need is the IDREFs to connect all of the objects together.


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 25, 2015, at 09:14, Shawn Riley <[hidden email]> wrote:

Just a quick reminder, the default way OBP with its semantic ontologies and serializations visualizes the OBP data is in a labeled directed-graph which is how humans think about data. The Soltra slide showing how human's visualize CTI data is a human drawn labeled directed-graph that is 99% identical to how the technology would present OBP data to humans. 

<Soltra slide - how humans view intelligence.PNG>


On Wed, Nov 25, 2015 at 11:01 AM, Jerome Athias <[hidden email]> wrote:
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
>
> <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 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.

<Soltra slide - how humans view intelligence.PNG>
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/


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

Wunder, John A.
These formats will all represent the same data so if nothing else you can convert it on ingest into RDF/XML or JSON-LD or whatever else. The idea that this will prevent anyone from doing anything is wrong…it will make it easier to do certain things (write custom code) and harder to do other things (convert it into a format for ingest into an OWL-based tool).

John

On Nov 25, 2015, at 4:11 PM, Jordan, Bret <[hidden email]> wrote:

You do not need JSON-LD or RDF or OWL to do this.  All you need is the IDREFs to connect all of the objects together.


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 25, 2015, at 09:14, Shawn Riley <[hidden email]> wrote:

Just a quick reminder, the default way OBP with its semantic ontologies and serializations visualizes the OBP data is in a labeled directed-graph which is how humans think about data. The Soltra slide showing how human's visualize CTI data is a human drawn labeled directed-graph that is 99% identical to how the technology would present OBP data to humans. 

<Soltra slide - how humans view intelligence.PNG>


On Wed, Nov 25, 2015 at 11:01 AM, Jerome Athias <[hidden email]> wrote:
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
>
> <a href="tel:%2B61%20%28407%29%20203%20206" value="&#43;61407203206" class="">+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.

<Soltra slide - how humans view intelligence.PNG>
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/


Reply | Threaded
Open this post in threaded view
|

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

Obrst, Leo J.
In reply to this post by Shawn Riley

Just a clarification: “semantic ontologies” is redundant. “Ontologies” is fine.

 

I agree that providing structural models only just gets you so far. At some point you really should provide “semantic models”, i.e., ontologies. Whether now is right for you, you’ll have to decide.

 

I’m a bit peripheral to this current community, and so, hesitate to introduce argumentation noise, but understand the issues with OBP. As nearly everywhere, folks will try to promote and use the “lowest” (from syntactic to structural to semantic) models available (and the languages those models are represented in) because more people understand them (they think) and they are easier to implement (nearly always true).

 

Thanks,

Leo

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Wednesday, November 25, 2015 2:51 PM
To: Terry MacDonald <[hidden email]>
Cc: [hidden email]; [hidden email]; Jonathan Bush (DTCC) <[hidden email]>
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <[hidden email]> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <[hidden email]>
Cc: [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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 Wunder, John A.
These things just remember me when I had simple custom code manipulating CSV files 15 years ago, and that some was arguing for me to use XML...
I admit than I did not understand the benefit at that time to add "complexity" in my code and have to manipulate bigger files.
I guess if I was still lazy now I would use CSV and not JSON nor XML

On Thursday, 26 November 2015, Wunder, John A. <[hidden email]> wrote:
These formats will all represent the same data so if nothing else you can convert it on ingest into RDF/XML or JSON-LD or whatever else. The idea that this will prevent anyone from doing anything is wrong…it will make it easier to do certain things (write custom code) and harder to do other things (convert it into a format for ingest into an OWL-based tool).

John

On Nov 25, 2015, at 4:11 PM, Jordan, Bret <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;bret.jordan@BLUECOAT.COM&#39;);" target="_blank">bret.jordan@...> wrote:

You do not need JSON-LD or RDF or OWL to do this.  All you need is the IDREFs to connect all of the objects together.


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

Just a quick reminder, the default way OBP with its semantic ontologies and serializations visualizes the OBP data is in a labeled directed-graph which is how humans think about data. The Soltra slide showing how human's visualize CTI data is a human drawn labeled directed-graph that is 99% identical to how the technology would present OBP data to humans. 

<Soltra slide - how humans view intelligence.PNG>


On Wed, Nov 25, 2015 at 11:01 AM, Jerome Athias <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;athiasjerome@gmail.com&#39;);" target="_blank">athiasjerome@...> wrote:
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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...>:
> 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: <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 Shawn Riley
> Sent: Wednesday, November 25, 2015 6:51 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...
>
>
>
> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> 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 | <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 Cory Casanave
> Sent: Wednesday, 25 November 2015 2:03 AM
> To: Kirillov, Ivan A. <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...>; Trey Darley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;trey@soltra.com&#39;);" target="_blank">trey@...>;
> Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.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...
>
>
>
> 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:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...]
>
> Sent: Tuesday, November 24, 2015 8:21 AM
>
> To: Cory Casanave; 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...
>
>
>
> 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" <<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>
>
>
>
>
> 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.

<Soltra slide - how humans view intelligence.PNG>
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: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-subscribe@lists.oasis-open.org&#39;);" target="_blank">cti-users-subscribe@...
Unsubscribe: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-unsubscribe@lists.oasis-open.org&#39;);" target="_blank">cti-users-unsubscribe@...
Post: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...
List help: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-help@lists.oasis-open.org&#39;);" target="_blank">cti-users-help@...
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/


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 Jordan, Bret
This is unfortunately not true or not so simple.

On Thursday, 26 November 2015, Jordan, Bret <[hidden email]> wrote:
You do not need JSON-LD or RDF or OWL to do this.  All you need is the IDREFs to connect all of the objects together.


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

Just a quick reminder, the default way OBP with its semantic ontologies and serializations visualizes the OBP data is in a labeled directed-graph which is how humans think about data. The Soltra slide showing how human's visualize CTI data is a human drawn labeled directed-graph that is 99% identical to how the technology would present OBP data to humans. 

<Soltra slide - how humans view intelligence.PNG>


On Wed, Nov 25, 2015 at 11:01 AM, Jerome Athias <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;athiasjerome@gmail.com&#39;);" target="_blank">athiasjerome@...> wrote:
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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...>:

> 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: <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 Shawn Riley
> Sent: Wednesday, November 25, 2015 6:51 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...
>
>
>
> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> 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 | <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 Cory Casanave
> Sent: Wednesday, 25 November 2015 2:03 AM
> To: Kirillov, Ivan A. <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...>; Trey Darley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;trey@soltra.com&#39;);" target="_blank">trey@...>;
> Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.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...
>
>
>
> 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:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...]
>
> Sent: Tuesday, November 24, 2015 8:21 AM
>
> To: Cory Casanave; 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...
>
>
>
> 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" <<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>
>
>
>
>
> 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.

<Soltra slide - how humans view intelligence.PNG>
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: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-subscribe@lists.oasis-open.org&#39;);" target="_blank">cti-users-subscribe@...
Unsubscribe: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-unsubscribe@lists.oasis-open.org&#39;);" target="_blank">cti-users-unsubscribe@...
Post: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...
List help: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users-help@lists.oasis-open.org&#39;);" target="_blank">cti-users-help@...
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/

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 Jordan, Bret
For sure.
And those who are not happy with JSON will leave or "fork".
JSON-LD is offering a balance between JSON and XML.
I would be a defender of XML, but could be convinced to accept JSON-LD. But not just JSON.
But of course you don't need me

On Wednesday, 25 November 2015, Jordan, Bret <[hidden email]> wrote:
The OASIS TC is currently voting on the MTI binding.  That vote should be finalized Friday December 4th.  If JSON wins, we will let this user group know so the vendors and groups that have been waiting can start writing code.


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

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

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

 

 

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 Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...>
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...

 

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...> 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: <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 Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 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...

 

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> 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 | <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 Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...>; Trey Darley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;trey@soltra.com&#39;);" target="_blank">trey@...>; Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.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...

 

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. [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">mailto:ikirillov@...]

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

To: Cory Casanave; 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...

 

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" <<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@... [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">mailto: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+on+behalf+of+trey@soltra.com&#39;);" target="_blank">cti-users@... on behalf of 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>

 


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

Struse, Richard

Actually, we do need you - and everyone else. 

 

As I said before, I’m looking forward to seeing the specific, concrete examples that the proponents of JSON-LD have offered to show us.  Until then we are arguing about hypotheticals.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jerome Athias
Sent: Wednesday, November 25, 2015 9:18 PM
To: Jordan, Bret
Cc: Shawn Riley; [hidden email]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

For sure.

And those who are not happy with JSON will leave or "fork".

JSON-LD is offering a balance between JSON and XML.

I would be a defender of XML, but could be convinced to accept JSON-LD. But not just JSON.

But of course you don't need me


On Wednesday, 25 November 2015, Jordan, Bret <[hidden email]> wrote:

The OASIS TC is currently voting on the MTI binding.  That vote should be finalized Friday December 4th.  If JSON wins, we will let this user group know so the vendors and groups that have been waiting can start writing code.

 

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 25, 2015, at 12:51, Shawn Riley <<a href="javascript:_e(%7B%7D,'cvml','shawn.p.riley@GMAIL.COM');" target="_blank">shawn.p.riley@...> wrote:

 

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <<a href="javascript:_e(%7B%7D,'cvml','terry@soltra.com');" target="_blank">terry@...> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

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

 

 

From: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@... [mailto:<a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <<a href="javascript:_e(%7B%7D,'cvml','jbush@dtcc.com');" target="_blank">jbush@...>
Cc: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

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 <<a href="javascript:_e(%7B%7D,'cvml','jbush@dtcc.com');" target="_blank">jbush@...> 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: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@... [mailto:<a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...] On Behalf Of Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 AM
To: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...


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

 

 

 

-----Original Message-----
From: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@... [mailto:<a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <<a href="javascript:_e(%7B%7D,'cvml','ikirillov@mitre.org');" target="_blank">ikirillov@...>; Trey Darley <<a href="javascript:_e(%7B%7D,'cvml','trey@soltra.com');" target="_blank">trey@...>; Shawn Riley <<a href="javascript:_e(%7B%7D,'cvml','shawn.p.riley@gmail.com');" target="_blank">shawn.p.riley@...>
Cc: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...
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. [<a href="javascript:_e(%7B%7D,'cvml','ikirillov@mitre.org');" target="_blank">mailto:ikirillov@...]

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

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: <a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@...

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" <<a href="javascript:_e(%7B%7D,'cvml','cory-c@modeldriven.com');" 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,'cvml','cti-users@lists.oasis-open.org');" target="_blank">cti-users@... [<a href="javascript:_e(%7B%7D,'cvml','cti-users@lists.oasis-open.org');" target="_blank">mailto: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,'cvml','cti-users@lists.oasis-open.org');" 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,'cvml','cti-users@lists.oasis-open.org+on+behalf+of+trey@soltra.com');" target="_blank">cti-users@... on behalf of 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>

 


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.

 

 


smime.p7s (9K) Download Attachment
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 Terry MacDonald-3
Comments inline

On Wednesday, 25 November 2015, Terry MacDonald <[hidden email]> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’.

It's guaranteed to offer more interoperability and automation for cybersecurity, unless you can prove the opposite through an academic research paper. (Btw is the TC charter "must make implementation easy"?)

The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

Yes and no.

The relationship construct will save time and effort allowing us to represent and exchange relationships that are not defined in the current model.

But counterpart is that we could (and so will) see relationships between "fish and banana".

It's a lazy approach with pros and cons. 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

Again JSON-LD could be something acceptable between XML and JSON
It would offer the flexibility needed to use the data even if the model has weaknesses. 

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

When you want to build a cathedral you would not ask to see and visit at the design phase.
If you have faith in trusted people saying that they can build it and that it will be the state of the art maybe you would just ask for some draws. Some have that today
So please clarify "presentable"

Best regards

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...

 

 

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 Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...>
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...

 

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...> 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: <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 Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 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...

 

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> 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 | <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 Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...>; Trey Darley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;trey@soltra.com&#39;);" target="_blank">trey@...>; Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.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...

 

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. [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">mailto:ikirillov@...]

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

To: Cory Casanave; 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...

 

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" <<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@... [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">mailto: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+on+behalf+of+trey@soltra.com&#39;);" target="_blank">cti-users@... on behalf of 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>

 


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 Terry MacDonald-3
Let me come back to you before Monday

On Wednesday, 25 November 2015, Terry MacDonald <[hidden email]> wrote:

With all due respect, I’ll wait until I can make an informed decision on the pluses and minuses of the JSON-LD approach once it’s been presented.

 

Any idea when that will be? Is it within the next two weeks or so? It will help me understand when we can finish this discussion, decide one way or the other, and move on

 

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...

 

 

From: Shawn Riley [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.riley@...]
Sent: Thursday, 26 November 2015 6:51 AM
To: Terry MacDonald <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...>
Cc: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-stix@lists.oasis-open.org&#39;);" target="_blank">cti-stix@...; <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">cti-users@...; Jonathan Bush (DTCC) <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...>
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

 

With all do respect, OBP can not be done with JSON and JSONSchema without the semantic Ontologies. If it can, please provide concrete examples and demonstrate this to the community so we all can understand how you can do what Google, Facebook, DoD, etc couldn't with traditional approaches such as JSON.

On Nov 25, 2015 2:45 PM, "Terry MacDonald" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> wrote:

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 take umbrage with this point. There is no guarantee that developing the model using OWL/RDF will result in better objects being created or something more attuned to the ‘OBP path’. The same OBP ideology can be applied at the JSON level, and it was the direction we were heading. The new top-level relationship object that has been discussed is a step in the right direction.

 

I do hope that the JSON-LD presentation is a good clear practical and pragmatic one, as I do believe the benefits of deriving serialization from a model are useful as long as the serialization output is something that people are actually going to use.

 

Any idea on timeframe for when the JSON-LD-based approach will be presentable?

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

 

 

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 Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...>
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...

 

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbush@dtcc.com&#39;);" target="_blank">jbush@...> 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: <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 Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 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...

 

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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;terry@soltra.com&#39;);" target="_blank">terry@...> 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 | <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 Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">ikirillov@...>; Trey Darley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;trey@soltra.com&#39;);" target="_blank">trey@...>; Shawn Riley <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;shawn.p.riley@gmail.com&#39;);" target="_blank">shawn.p.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...

 

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. [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ikirillov@mitre.org&#39;);" target="_blank">mailto:ikirillov@...]

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

To: Cory Casanave; 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...

 

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" <<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@... [<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cti-users@lists.oasis-open.org&#39;);" target="_blank">mailto: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+on+behalf+of+trey@soltra.com&#39;);" target="_blank">cti-users@... on behalf of 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>

 


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

Trey Darley-3
In reply to this post by JA
On 26.11.2015 05:17:33, Jerome Athias wrote:
>
> And those who are not happy with JSON will leave or "fork".
>

OASIS is a standards body in which decisions are made by voting. There
are *always* minority voices disagreeing with particular decisions
taken in democratic communities.

You're prepared to "take your ball and go home" over the JSON issue.
Fine.

Assuming for the sake of discussion that we all swing your way on this
issue, in what fantasy world are all *future* OASIS CTI decisions
guaranteed to be to your liking? Are we as a community to tremble in
fear lest perchance we one day take a decision that you disapprove of
and "poof!", Jerome's out?! No, that would be silly.

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

Trey Darley-3
On 30.11.2015 16:45:51, Trey Darley wrote:
> On 26.11.2015 05:17:33, Jerome Athias wrote:
> >
> > And those who are not happy with JSON will leave or "fork".
> >
>
> OASIS is a standards body in which decisions are made by voting. There
> are *always* minority voices disagreeing with particular decisions
> taken in democratic communities.
>

Hi, Jerome -

My tone in that last mail was harsh. While I feel the point I was
trying to make is valid, I sincerely apologize for my tone. The mail
was written in haste at a conference; I should have taken a moment
longer to review it.

Ideally all our proceedings would be collegial. In this case I
inadvertently undermined that spirit of collegiality we aspire to and
for that I ask both your forgiveness and that of the entire CTI
community.

--
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
--
"Any sufficiently complex input format is indistinguishable from
bytecode." -- Bratus, Patterson, & Shubina

signature.asc (836 bytes) Download Attachment
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
No problem here. (I can take more than that ;))
Sincerely, I only hope you can demonstrate that you can do it and that it adds value.
I hope being a PITA can just add motivation for success.

Best of luck for all of us
Peace and love 
Best regards

On Monday, 30 November 2015, Trey Darley <[hidden email]> wrote:
On 30.11.2015 16:45:51, Trey Darley wrote:
> On 26.11.2015 05:17:33, Jerome Athias wrote:
> >
> > And those who are not happy with JSON will leave or "fork".
> >
>
> OASIS is a standards body in which decisions are made by voting. There
> are *always* minority voices disagreeing with particular decisions
> taken in democratic communities.
>

Hi, Jerome -

My tone in that last mail was harsh. While I feel the point I was
trying to make is valid, I sincerely apologize for my tone. The mail
was written in haste at a conference; I should have taken a moment
longer to review it.

Ideally all our proceedings would be collegial. In this case I
inadvertently undermined that spirit of collegiality we aspire to and
for that I ask both your forgiveness and that of the entire CTI
community.

--
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
--
"Any sufficiently complex input format is indistinguishable from
bytecode." -- Bratus, Patterson, & Shubina
123