There is a big difference between being open with your data, and having
that data live on a public internet-facing web server for query. The
difference is PULL vs PUSH, and it is a big one. Organizations will be
willing to PUSH subsets of their threat intel to trust group based sharing
platforms - and yes that is indeed the whole reason we are all here - but
most organizations are not going to allow outsiders, even those in their
own trust group, to connect to their internal threat repositories to PULL
threat intel. It would be like having your PCI servers sitting out on the
Internet - not going to happen.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security |
www.securityintelligence.comWithout data, all you are is just another person with an opinion - Unknown
From: "Bush, Jonathan" <
jbush@dtcc.com>
To: "'Camp, Warren (CTR)'" <
warren.camp@associates.hq.dhs.gov>,
"Jordan, Bret" <
bret.jordan@bluecoat.com>, Jason
Keirstead/CanEast/IBM@IBMCA
Cc: "Sean D. Barnum" <
sbarnum@mitre.org>, Jane Ginn
<
jane.ginn@gmail.com>, "Wunder, John A." <
jwunder@mitre.org>,
"cti-users@lists.oasis-open.org"
<
cti-users@lists.oasis-open.org>,
"cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Date: 2015/10/05 08:21 PM
Subject: RE: [cti-users] [cti-stix] [cti-users] MTI Binding
Agreed Warren, my assumption was that was the whole point of what we were
doing here – Creating an open community for cyber intel sharing. I can
certainly appreciate though this won’t happen overnight, but that is a
cultural issue. When we get beyond that barrier, we need to have the
systems in place already to allow it. If we start building with that in
mind at that time, it will be too late. “Begin with the end in mind”.
From: Camp, Warren (CTR) [mailto:
warren.camp@associates.hq.dhs.gov]
Sent: Monday, October 05, 2015 5:42 PM
To: Jordan, Bret; Jason Keirstead
Cc: Bush, Jonathan; Sean D. Barnum; Jane Ginn; Wunder, John A.;
cti-users@lists.oasis-open.org;
cti-stix@lists.oasis-open.orgSubject: RE: [cti-users] [cti-stix] [cti-users] MTI Binding
Not being an expert in these matters, please consider my 2 cents worth of
concern. I am concerned about statements such as “vast majority of CTI
communication will NOT exist in broad and open sharing” There won’t be any
CTI communications if there is no value proposition for the cybersecurity
community. The value is not just sharing information, the value is how we
used the shared information. If we foster many different
methods/approaches to sharing information, we will never leverage how to
use the information. I believe part of the value proposition is providing
solutions such as direct updating of IDS/IPS rules or malware signatures
based on Threat Indicator and Alert data. With all the discussions are we
improving what we have or are we improving where and how we want end.
PS I enjoy the discussions and I am learning a lot from the different
perspectives.
Thank you,
Warren
From:
cti-users@lists.oasis-open.org [mailto:
cti-users@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, October 05, 2015 3:21 PM
To: Jason Keirstead
Cc: Bush, Jonathan; Sean D. Barnum; Jane Ginn; Wunder, John A.;
cti-users@lists.oasis-open.org;
cti-stix@lists.oasis-open.orgSubject: Re: [cti-users] [cti-stix] [cti-users] MTI Binding
I would agree with Jason. It seems like the vast majority of CTI
communication will NOT exist in broad and open sharing. There will be
trust groups, subscriptions, niche eco-systems, and all manner of
boundaries around what people do with their CTI.
About the best we can hope for in the short term is organizations pushing
data (copy) to an ISAO or ISAC or DHS and then having them correlate and do
something with the data and then re-share it.
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 5, 2015, at 12:13, Jason Keirstead <
Jason.Keirstead@ca.ibm.com > wrote:
I think you're making a big assumption that most systems used to
share CTI will be internet facing and/or publicly accessible, which
isn't true.
The odds that CTI System A (originator of STIX Name space "
CompanyA.com") can communicate directly with CTI System B (originator
of STIX Name space "CompanyB.com") are actually quite low.
This is why the data has to be copied, otherwise there is no way at
all to build a knowledge graph.
-
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
<graycol.gif>"Bush, Jonathan" ---2015/10/05 02:48:22 PM---The
use-case I had in mind was that instead of tools transporting data
around the internet, copying
From: "Bush, Jonathan" <
jbush@dtcc.com>
To: "'Jordan, Bret'" <
bret.jordan@bluecoat.com>
Cc: "Sean D. Barnum" <
sbarnum@mitre.org>, Jane Ginn <
jane.ginn@gmail.com>, "Wunder, John A." <
jwunder@mitre.org>, "
cti-users@lists.oasis-open.org" <
cti-users@lists.oasis-open.org>, "
cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Date: 2015/10/05 02:48 PM
Subject: [cti-users] RE: [cti-stix] [cti-users] MTI Binding
Sent by: <
cti-users@lists.oasis-open.org>
The use-case I had in mind was that instead of tools transporting
data around the internet, copying it from one place to another, we
could just have the data link to other referenced data that exists
somewhere else in the CTI “ecosystem”. Why move all that data around
when I can just point to it? And… if that leads me to a place that
then points to other data locations, before long I will have a “net”
of data that I can use to perform complex analytical analysis to
answer questions that would otherwise be very difficult.
(I suppose I’m defining the semantic web here)
… at least that was where my head was at with it.
From:
cti-stix@lists.oasis-open.org [
mailto:
cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, October 05, 2015 1:42 PM
To: Bush, Jonathan
Cc: Sean D. Barnum; Jane Ginn; Wunder, John A.;
cti-users@lists.oasis-open.org;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] [cti-users] MTI Binding
I have been reading a lot about JSON-LD, and I get how and why it
might be interesting in a website context when you are sharing
unknown data back and forth. Meaning there is no standard for the
data you are sharing. Think user profile between Google, Twitter,
Facebook etc. But, unless I am mistaken, the purpose of STIX is to
define a standard for CTI so that we all share the same data.
Can someone explain why JSON-LD is needed in the CTI context. I just
do not see why anyone that is building an application to use CTI
would care since all of the data that will be shared between them is
KNOWN and in a standard well known form, aka STIX... Please help me
understand this use case.
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 5, 2015, at 11:20, Bush, Jonathan <
jbush@dtcc.com>
wrote:
I would agree that some of the technologies involved with
the Semantic web scare me a little bit (very complex,
many seem pretty academic), but at least if we go with a
structure that sets us up for this sort of “linked” data
thinking now, we leave that door open for the future.
From:
cti-stix@lists.oasis-open.org [
mailto:
cti-stix@lists.oasis-open.org] On Behalf Of
Jordan, Bret
Sent: Monday, October 05, 2015 1:11 PM
To: Bush, Jonathan
Cc: Sean D. Barnum; Jane Ginn; Wunder, John A.;
cti-users@lists.oasis-open.org;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] [cti-users] MTI Binding
http://manu.sporny.org/2014/json-ld-origins-2/ 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 5, 2015, at 10:34, Bush, Jonathan <
jbush@dtcc.com> wrote:
Great information here, thank you Sean.
It sounds like we are talking about
Use-Cases -> UML (or OWL/RDF) -> JSON-LD
(context portion mapping model to JSON
constructs to use) -> JSON (actual instances
of content)
I could get behind that.
From: Barnum, Sean D. [
mailto:
sbarnum@mitre.org]
Sent: Monday, October 05, 2015 10:14 AM
To: Bush, Jonathan; 'Jane Ginn'; Wunder, John
A.
Cc:
cti-users@lists.oasis-open.org;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [cti-users] MTI
Binding
I don’t think I would concur with Jane’s
characterization that this represents a
"significant shift in the level at which we
are approaching the problem set”. Rather, I
think it fits very well into how we have been
approaching the problem but may represent an
acceleration along our path. We began the
STIX efforts leveraging XSD to specify the
language because we as a community did not
yet know or agree on what CTI was and XSD
provided a good structured mechanism everyone
could deal with to collaboratively define and
experiment in an explicit way. It was
recognized since the beginning that this was
only a temporary approach and that we would
eventually need a richer more semantic
specification with a derived abstraction
stack like I described in my earlier post
(ontology/data-model, binding specs,
implementations, instance data). We have been
working along this path as a community
gradually separating out and establishing
these abstractions for quite a while now. As
we have evolved the technology along the
planned path we have tried to be mindful not
only of the raw technical capabilities of
given technologies to support targeted use
cases and represent necessary information but
also of the community’s ability and
willingness to understand, accept and adopt
them. I and several others in the community
have long posited that a full semantic model
(likely using something like OWL/RDF) would
likely be the best long term form for the
ontology/data-model layer as that is exactly
what such technologies are designed for and
would provide excellent flexibility but also
excellent consistency and potential for
automated transformation. To date this has
been viewed as a goal to work towards but not
something to be pushed too soon as the
community may not be familiar enough with it
yet. This led to the interim step of
leveraging UML to specify the normative model
for the language. The UML-based
specifications we have today, while not fully
semantic, provide us the practical ability to
fully instantiate the desired abstraction
stack for STIX. I continue to hold the
opinion (as do several others in the
community like Pat, Paul, Shawn, etc.) that
we should continue to evolve towards a full
explicit semantic form of specification for
the ontology/data-model but it is still
unclear how fast that evolution should occur.
The plan discussed several times for STIX 2.0
was to stick with the UML + text docs form
but begin to work in some semantic modeling
snippets as part of discussions on a few of
the refactoring issues (e.g. separating out
relationships) that are semantic in their
roots and likely include a few OWL-style
diagrams in the spec text docs. This could
then be a good introduction to these
approaches for the community and an initial
basis for future evolution to fully semantic
models.
While Jonathan is correct that most XML-based
implementations would require some major
retooling to support a JSON-based
serialization form, I don’t think that
JSON-LD inherently brings any further burden
that that. To be clear, instance STIX data
using a JSON-LD approach would still be &pure
JSON”. It is just that the structure of that
JSON would be aligned to the
ontology/data-model higher in the abstraction
stack. To use a simple analogy, think of
“pure JSON” not as a human language like
English or French but rather as something far
lower level such as human cursive
handwriting. It can be used to convey all
sorts of different semantics and structure
(English, French, etc.). The LD/context
portions of JSON-LD are what allow someone
reading the cursive to recognize whether they
are reading English or French and to
understand the actual meaning of what is
being written. This mapping of meaning from
the low-level serialization format to the
higher-level ontology/data-model is what the
two middle layers of the abstraction stack
are all about. These layers are required to
be there no matter which approach we take.
Without these layers expressed content,
regardless of whether it is JSON, XML,
protobuf or whatever, would not be
interpretable of interoperable. JSON-LD
provides one option for defining these layers
for a targeted “pure JSON” end serialization
for instance data (which is what I believe
Bret and several others really want). Another
option would be to write the JSON binding
spec as some other form of rules (including
potentially human language) and then specify
the implementation using something like JSON
Schema. JSON-LD simply provides an explicit
structured way to tackle these two layers.
Does that make sense?
Again, anyone knowledgeable on these topics
should feel free to point out where they
believe my characterizations are incorrect or
unclear.
Sean
From: "cti-stix@lists.oasis-open.org" on
behalf of "Bush, Jonathan"
Date: Saturday, October 3, 2015 at 8:15 AM
To: 'Jane Ginn', John Wunder
Cc: "cti-users@lists.oasis-open.org", "
cti-stix@lists.oasis-open.org"
Subject: RE: [cti-stix] Re: [cti-users] MTI
Binding
I would agree. JSON-LD could be an incredibly
powerful way to represent intelligence data,
but it represents a fundamental shift that
will require a major retooling for most
implementations to really take advantage of
it. The good news is that tools (such as
Soltra products to be all about “me” for a
second) could ease into that implementation
by thinning the implementation down to pure
JSON at first (I believe, someone correct me
if I’m wrong here). The real question is,
will we as implementers get to the point
where we really jump all in and represent
data using the “LD” portion of the concept?
Again, looks promising (after all, if Google
and Facebook are using it to represent
complex data, why shouldn’t we be paying
attention), but do we all know what we would
be buying in to?
From:
cti-stix@lists.oasis-open.org [
mailto:
cti-stix@lists.oasis-open.org] On
Behalf Of Jane Ginn
Sent: Friday, October 02, 2015 8:45 PM
To: Wunder, John A.
Cc:
cti-users@lists.oasis-open.org;
cti-stix@lists.oasis-open.org Subject: [cti-stix] Re: [cti-users] MTI
Binding
Hi All:
While reading through this thread it occurred
to me that the JSON-LD suggestion represents
a significant shift in the level at which we
are approaching the problem set. Cory has
long been arguing for us to shift our focus
to a semantic model that can serve as a
language agnostic approach to solving the CTI
sharing problem. Bret has been pushing for
JSON as a tool to help us achieve more wide
spread adoption. We currently have bindings
in XML and Python... but no MTI for moving
forward with STIX 2.0.
JSON-LD appears to address several of our
issues at a higher level of abstraction.
I'm also intrigued by the potential, from the
POV of STIX cosumers, at how PMML can be
deployed seamlessly to use wire speed data on
attacks for predictive modelling... or at
least deploying the myriad of tools for
predictive modelling. I expect this is an
area of white space in the market that will
be picked up by a vendor and developed as an
enterprise solution. We just need to get the
front end right for the integration.
Jane Ginn
Cyber Threat Intelligence Network
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.
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.
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.
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.
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.