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


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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

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

Comments inline

On Wednesday, 25 November 2015, Terry MacDonald <terry@soltra.com> 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



Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com



From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Shawn Riley
Sent: Thursday, 26 November 2015 1:38 AM
To: Jonathan Bush (DTCC) <jbush@dtcc.com>
Cc: cti-users@lists.oasis-open.org
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. 



On Wed, Nov 25, 2015 at 9:19 AM, Bush, Jonathan <jbush@dtcc.com> 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: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Shawn Riley
Sent: Wednesday, November 25, 2015 6:51 AM
To: cti-users@lists.oasis-open.org

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. 


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 <terry@soltra.com> 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.




Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com




-----Original Message-----
From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Cory Casanave
Sent: Wednesday, 25 November 2015 2:03 AM
To: Kirillov, Ivan A. <ikirillov@mitre.org>; Trey Darley <trey@soltra.com>; Shawn Riley <shawn.p.riley@gmail.com>
Cc: cti-users@lists.oasis-open.org
Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...



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.




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

From: Kirillov, Ivan A. [mailto:ikirillov@mitre.org]

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

To: Cory Casanave; Trey Darley; Shawn Riley

Cc: cti-users@lists.oasis-open.org

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.








On 11/23/15, 4:32 PM, "Cory Casanave" <cory-c@modeldriven.com> 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.


>-----Original Message-----

>From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A.

>Sent: Monday, November 23, 2015 2:50 PM

>To: Trey Darley; Shawn Riley

>Cc: cti-users@lists.oasis-open.org

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



>On 11/23/15, 4:06 AM, "Trey Darley" <cti-users@lists.oasis-open.org on behalf of trey@soltra.com> 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




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



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.


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