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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

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


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


In hopes of increasing the understanding of RDF/OWL and JSON-LD, I’ve taken a snippet of the Poison Ivy sample provided up in GitHub, mapped it do an ontology defined in RDF/OWL, and then generated the same output in a number of different formats.

The ontology that describes a STIX Campaign is attached (campaign.rdf) and can be visualized as a class diagram using UML notation in the attached file campaign.html-classdiagram.png

Below is the basic snippet that I took from STIX/XML from the file fireeye-pivy-report.xml :

        <stix:Campaign timestamp="2014-05-08T09:00:00.000000Z" id="fireeye:campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e" xsi:type="campaign:CampaignType">

            <campaign:Title>th3bug</campaign:Title>

            <campaign:Status>Ongoing</campaign:Status>

            <campaign:Related_TTPs>

                <campaign:Related_TTP>

                    <stixCommon:Relationship>Uses Malware</stixCommon:Relationship>

                    <stixCommon:TTP idref="fireeye:ttp-34a3d511-e213-40d5-a932-fc4d836d455e"/>

                </campaign:Related_TTP>

                <campaign:Related_TTP>

                    <stixCommon:Relationship>Uses Malware</stixCommon:Relationship>

                    <stixCommon:TTP idref="fireeye:ttp-2821af3c-0f2b-45b4-92f5-465ca7a51920"/>

                </campaign:Related_TTP>

                <campaign:Related_TTP>

                    <stixCommon:Relationship>Uses Malware</stixCommon:Relationship>

                    <stixCommon:TTP idref="fireeye:ttp-862fd6e1-1711-4b70-8bec-1591f4baabc1"/>

                </campaign:Related_TTP>

            </campaign:Related_TTPs>

            <campaign:Attribution>

                <campaign:Attributed_Threat_Actor>

                    <stixCommon:Threat_Actor idref="fireeye:threatactor-fb580b4d-b36d-415c-b711-d9997955f5c1"/>

                </campaign:Attributed_Threat_Actor>

            </campaign:Attribution>

        </stix:Campaign>


The following examples illustrate a basic example of using the STIX Campaign ontology. The example show the definition of an ongoing Campaign called "th3bug" that is attributed to a particular threat actor and references 3 different TTPs that are asserted to be related to the campaign as described in the STIX/XML above.

The campaign is assigned the identifier campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e to uniquely identify the campaign. The rdf-schema#label provides a human‑readable text string to be used as the label to be displayed to users.

Through the use of RDF/OWL, it is possible to serialize an instance of Campaign in a number of different formats. To demonstrate this, the following examples illustrate the same information in a number of different formats.  Running the above STIX/XML thru a simple translator written in Python and based on the Campaign ontology, I was able to generate the following serializations:

N-triple Format


<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://stix.mitre.org/Campaign#Campaign> .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://www.w3.org/2000/01/rdf-schema#label> "th3bug" .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/stixCommon#id> "campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e" .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/stixCommon#timestamp> "2014-05-08T09:00:00Z" .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/stixCommon#title> "th3bug" .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/Campaign#status> "Ongoing"^^<http://stix.mitre.org/default_vocabularies-1#CampaignStatusVocab-1.0> .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/Campaign#attribution> <http://cti.company.com/threatactor-fb580b4d-b36d-415c-b711-d9997955f5c1> .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/stixCommon#relatedTTP> <http://cti.company.com/ttp-34a3d511-e213-40d5-a932-fc4d836d455e> .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/stixCommon#relatedTTP> <http://cti.company.com/ttp-2821af3c-0f2b-45b4-92f5-465ca7a51920> .
<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e> <http://stix.mitre.org/stixCommon#relatedTTP> <http://cti.company.com/ttp-862fd6e1-1711-4b70-8bec-1591f4baabc1> .

Turtle Format


<http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e>
  a <http://stix.mitre.org/Campaign#Campaign> ;
  rdfs:label "th3bug" ;
  stixc:id "campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e" ;
  stixc:timestamp "2014-05-08T09:00:00Z" ;
  stixc:title "th3bug" ;
  campaign:status "Ongoing"^^http://stix.mitre.org/default_vocabularies-1#CampaignStatusVocab-1.0 ;
  campaign:attribution <http://cti.company.com/threatactor-fb580b4d-b36d-415c-b711-d9997955f5c1> ;
  stixc:relatedTTP <http://cti.company.com/ttp-34a3d511-e213-40d5-a932-fc4d836d455e>,
                   <http://cti.company.com/ttp-2821af3c-0f2b-45b4-92f5-465ca7a51920>,
                   <http://cti.company.com/ttp-862fd6e1-1711-4b70-8bec-1591f4baabc1> .

RDF/XML Format


  <rdf:Description rdf:about="http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e">
    <rdf:type rdf:resource="http://stix.mitre.org/Campaign#Campaign"/>
    <rdfs:label>th3bug</rdfs:label>
    <stixc:id>campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e</stixc:id>
    <stixc:timestamp>2014-05-08T09:00:00Z</stixc:timestamp>
    <stixc:title>th3bug</stixc:title>
    <campaign:status rdf:datatype="http://stix.mitre.org/default_vocabularies-1#CampaignStatusVocab-1.0">Ongoing</campaign:status>
    <campaign:attribution rdf:resource="http://cti.company.com/threatactor-fb580b4d-b36d-415c-b711-d9997955f5c1"/>
    <stixc:relatedTTP rdf:resource="http://cti.company.com/ttp-34a3d511-e213-40d5-a932-fc4d836d455e"/>
    <stixc:relatedTTP rdf:resource="http://cti.company.com/ttp-2821af3c-0f2b-45b4-92f5-465ca7a51920"/>
    <stixc:relatedTTP rdf:resource="http://cti.company.com/ttp-862fd6e1-1711-4b70-8bec-1591f4baabc1"/>
  </rdf:Description>

JSON-LD Objects


{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id": "http://cti.company.com/campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e",
  "@type": "http://stix.mitre.org/Campaign#Campaign",
  "http://stix.mitre.org/Campaign#attribution": {
    "@id": "http://cti.company.com/threatactor-fb580b4d-b36d-415c-b711-d9997955f5c1"
  },
  "http://stix.mitre.org/Campaign#status": {
    "@type": "http://stix.mitre.org/default_vocabularies-1#CampaignStatusVocab-1.0",
    "@value": "Ongoing"
  },
  "http://stix.mitre.org/stixCommon#id": "campaign-d02a1560-ff69-49f4-ac34-919b8aa4b91e",
  "http://stix.mitre.org/stixCommon#relatedTTP": [
    {
      "@id": "http://cti.company.com/ttp-862fd6e1-1711-4b70-8bec-1591f4baabc1"
    },
    {
      "@id": "http://cti.company.com/ttp-2821af3c-0f2b-45b4-92f5-465ca7a51920"
    },
    {
      "@id": "http://cti.company.com/ttp-34a3d511-e213-40d5-a932-fc4d836d455e"
    }
  ],
  "http://stix.mitre.org/stixCommon#timestamp": "2014-05-08T09:00:00Z",
  "http://stix.mitre.org/stixCommon#title": "th3bug",
  "rdfs:label": "th3bug"
}


While this is NOT an exhaustive example, I believe it shows a concrete example of how this can be done using a sample directly from existing STIX 1.2.

Assuming that there is significant interest, I can provide additional examples of other STIX components represented in these serialization formats.

NOTE: this is a bit of a dated example as I have since also added support for additional information about the relationship itself, which are just represented as any other data in an RDF/OWL serialization.

Hope this helps everyone better understand what is being discussed.

Regards,

Paul Patrick


From: <cti-users@lists.oasis-open.org> on behalf of Shawn Riley
Date: Wednesday, October 7, 2015 at 5:20 PM
To: "cti-users@lists.oasis-open.org"
Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)

Just as an additional point of reference to the folks in the Financial Services industry. You might recognize RDF/OWL from the Financial Industry Business Ontology (FIBO). The Financial Industry Business Ontology (FIBO) is an open standard for defining the business terms and relationships associated with financial instruments, pricing concepts and financial processes. These "common language" standards are used to align the way financial institutions describe complex financial instruments and financial processes so that industry participants and regulators can harmonize reporting, validate data quality, aggregate transactions and analyze risks across the global financial system.  http://www.automatedtrader.net/news/at/153893/enterprise-data-management-council-releases-its-first-formal--ontology-standard

If you are in the financial services you might have folks who can provide greater insight to RDF/OWL inside your organizations. 

Shawn

On Wed, Oct 7, 2015 at 1:47 PM, Cory Casanave <cory-c@modeldriven.com> wrote:

So this is the plot developing in my mind…

 

We define a logical data model in UML (big surprise), from this we generate BOTH a RDF/JSON-LD schema with some structural annotations (this is being called frames by the JSON-LD camp) as well as a JSON-Schema. A valid CTI document will validate against both. A JSON-centric developer sees a structure, the semantic web centric developer sees RDF. The JSON-Schema will include the “context” properties that JSON-LD uses but these may not be used by the JSON centric developers. Thus both paradigms can be supported for the same wire format. As the market develops we will see where there is take-up and value. Other than the extra context properties I don’t think there would be any runtime overhead. The STIX API (which also could be generated) would, of course, fully support this format.

 

Cost: There would be some development required to generate these dual specifications from UML, but the effort would not be large and only the CTI team would need the capability since it would produce the normative CTI artifacts. There may also need to be some tweaking of RDF sterilizers to support this specific serialization format, but again, not a big deal. I suspect other groups may also find this capability interesting.

 

Of course, this would all have to be proven out – but I don’t see any major problems. There would be a couple of constraints on the RDF, but no deal killers.

 

-Cory Casanave

 

From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com]
Sent: Wednesday, October 07, 2015 1:21 PM
To: Jordan, Bret
Cc: Cory Casanave; Shawn Riley; cti-users@lists.oasis-open.org
Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)

 

I'll echo this and add onto it as well, the other much larger consideration here is simply the realities of software development. Every new format that exists in the wild, is therefore another format that you need to add support for to your tools if you want to have a workable ecosystem where tools can talk to each-other. It's also another format that needs to be developed, tested, and certified, against all of those various other tools, both internally and externally.

It doesn't matter if there are pre-existing translation libraries available for this translation. Libraries like that only reduce a tiny amount of the overall workload. The marshalling and de-marshalling of data is only one piece of the work effort... arguably, its the smaller piece.

In fact, with every new wire format, the integration work required will increase in a geometric fashion.

This is why it is so important to have "one true" wire format codified as a standard.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Jordan, Bret" ---2015/10/07 12:58:58 PM---Yes, for professional modelers and people that work in RDF"Jordan, Bret" ---2015/10/07 12:58:58 PM---Yes, for professional modelers and people that work in RDF every day, this would seem like the best

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Cory Casanave <cory-c@modeldriven.com>
Cc: Shawn Riley <shawn.p.riley@gmail.com>, "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Date: 2015/10/07 12:58 PM
Subject: Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)
Sent by: <cti-users@lists.oasis-open.org>





Yes, for professional modelers and people that work in RDF every day, this would seem like the best thing to do. You are using advanced tools, software packages and libraries that can consume anything as long as it is RDF.

The problem is, most of the developers that we need to recruit to write tools and software to work with STIX are not professional modelers and RDF people. They work in PHP and _javascript_, or in Objective-C, Android-Java, C++, Python, Perl, Ruby etc. They need to read in a blob of data over the wire, say JSON. Stick that in to memory somewhere. Then unmarshal that in to a struct or series of maps/dictionaries and then do something with it.

Further, most vendors that build security products or networking products use a PHP interface or Java interface with a ton of JSON and a REST API. Lets not make things hard for them. We need to recruit them. We need to get them on board.

Speaking from my past experience in start-ups. If the technology is outside of the development stack, and it is a checkbox feature, then it will never get done. We need this to be so simple and easy that everyone says "why would I NOT do this, lets just do it make it happen". At RSA and Blackhat I talked with a lot of startups that said, "if you would only do JSON we could adopt this". I talked with Facebook and they said if we could do JSON, they could support it natively in their solution.

If we want to win, lets make it easy for organizations to understand and use.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Oct 7, 2015, at 09:47, Cory Casanave <cory-c@modeldriven.com> wrote:

For “RDF people”, this is a non-issue. You call a library to read or write your data and it takes care of serialization. You will be able to accept data in any of the formats and not care, you deal with the RDF API and local language objects. This is why my specific knowledge of JSON-LD is minimal, it is just something a library takes care of.

I do understand the perspective of “_javascript_ people” who need to deal with the data in a specific syntax and don’t want to know about RDF.
In that the RDF people should not care and JSON people care a bunch it would seem a good idea to have a default serialization in JSON.

(I said I would shut up and I’m not doing well)

From:cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Shawn Riley
Sent:
Wednesday, October 07, 2015 11:40 AM
To:
Jordan, Bret
Cc:
cti-users@lists.oasis-open.org
Subject:
Re: [cti-users] Towards a better understanding of JSON-LD (Was: MTI Binding)

Help me understand this statement "Allowing people to send "RDF/JSON-LD (Hardback), RDF/XML (Paperback), RDF/Turtle (Amazon Kindle), RDF/N-Triples " will just mean this effort will be an epic failure and no one will be able to talk to each other"

Since all of those formats are RDF serializations, there are existing translators today that can convert RDF/JSON-LD to RDF/XML or RDF/Turtle or any other RDF/serialization format. This should increase adoption without forcing everyone to only use JSON.



On Wed, Oct 7, 2015 at 11:17 AM, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
You said:

"I have to believe that giving the community a choice of valid RDF based serialization formats (Hardback, Paperback, Amazon Kindle, Apple iPad, etc) will increase adoption faster than locking everyone into one serialization format like Hardback (JSON) or Paperback (XML). "

This is not a good idea IMO. We need a default on the wire solution that every one uses. Eric mentioned that in his email earlier today. Allowing people to send "RDF/JSON-LD (Hardback), RDF/XML (Paperback), RDF/Turtle (Amazon Kindle), RDF/N-Triples " will just mean this effort will be an epic failure and no one will be able to talk to each other.

Remember developers will be working with the on-the-wire formats. I do not like the hand waving of, oh the software will figure it out. No, developers need to write the software that consumes it and does something with it. Further, given that most people in this community have a hard time with understanding RDF and why it is needed, that goes to show that most developers in the wild probably also have a hard time understanding it. The average open source, web application, and APP developers want JSON, plain and simple and probably do not know how to even work with RDF. The more complicated we make this, the more esoteric solutions we use, the less likely they will code to it.

I am a huge proponent of UML models with JSON schema bindings. Very simple, very easy to understand, and very easy to use. The cost of entry for people to get started is minimal. If we want adoption, we need things to be simple and easy. I do not view RDF as a solution for STIX as the complexity cost will drive people away. UML is a great middle ground, average developers and companies and vendors can look at the UML models and quickly and easily understand what is going on and what they need to do in their products / software / solutions. Then if the data over the wire is in JSON schema, they can quickly and easily put this in to use in their PHP applications, their JAVA applications, their C++ applications, etc...


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Oct 7, 2015, at 08:04, Shawn Riley <shawn.p.riley@GMAIL.COM> wrote:

If you remember the XML vs RDF analogy of A Christmas Carol from Cambridge Semantics, http://www.cambridgesemantics.com/semantic-university/rdf-vs-xml, this example might help in better understanding the JSON vs RDF/JSON-LD choice.

If STIX reports were Books.

A STIX JSONSchema Book Store offers STIX books in JSON (Hardback)

A STIX RDF/OWL Book Store offers STIX Books in multiple RDF serializations. RDF/JSON-LD (Hardback), RDF/XML (Paperback), RDF/Turtle (Amazon Kindle), RDF/N-Triples (Apple iPad), etc.

The content of the STIX books from the STIX RDF/OWL Book Store is the same regardless of the on the wire serialization (RDF/JSON-LD, RDF/XML, etc) with dozens of tools already available that can convert between RDF serialization formats in case you want to read your book in another RDF serialization.

I have to believe that giving the community a choice of valid RDF based serialization formats (Hardback, Paperback, Amazon Kindle, Apple iPad, etc) will increase adoption faster than locking everyone into one serialization format like Hardback (JSON) or Paperback (XML).

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]


Attachment: campaign.rdf
Description: Binary data

Attachment: campaign.html-classdiagram.png
Description: PNG image



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