[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Jordan, Bret
Cross-posting to the broader community as most of them are not on the members OASIS CTI list, but have valuable feedback on this topic..  CTI-Users, please review this thread in the email archives at OASIS.

So where does this leave us?  I still do not feel like we have a super clear path forward that we all agree on, and I would like to see us come to some sort of steady state.  

We have heard comments from the Telco space, FS-ISAC/DTCC, MITRE/DHS, vendors (IBM, bit9, BrightPoint) and the Model development space.  I would like to here more from the community especially those that will be writing code and I would like to hear more from those that have already commented. We need everyone's ideas and input, even if we do not always agree.  The ideas and comments are valuable as they stitch together the dots and that make up the context that will eventually reveal the picture. 

My top level design goals are:

*) We work on a good solid UML model, trying as best as we can to address the issue Aharon has called out.  

*) We get the security practitioners to review the model to make sure it is easy to use, understand, and that it has the data they need in the places they expect, 

*) We get development teams, product managers, and vendors to review the model for ease of adoption in to product portfolios and do some top level implementation sanity checking.  In product development terms, we want to make sure our architectural stack is solid and that we are not doing things that are going to make life really painful or difficult in the future (like our current implementation of Data Markings).  

==> Where we need further discussion, I believe, is how do we go from Data Model to Data Exchange Format (that thing that most people actual care about). 


I think if we can do these things, and get consensus on the last one, we will be moving in the right direction.  This can help ensure that we are designing and building both a Data Model and a Data Exchange Format that can actually be used.   The road forward will be a bit bumpy, and it is going to require a lot of thought from everyone.

I believe we have the chance of doing something great here.  I believe that we as a global community can make this work.  I believe we can fix the things that are painful and really make a difference in the Cyber Threat world.  




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


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

[cti-users] RE: [cti] Thoughts on STIX and some of the other threads on this list

Grobauer, Bernd
Hi,

this is a bit late, but there were several requests for
broad feedback on the major issue of what the future
should look like, so here goes ...

First, for the impatient, reader, the contents of what
comes below in a nutshell:

I) If we change the binding from XML to something else
   for the next major release, we need to be sure that
   the effort of doing so does neither slow us
   down to much nor distract too much attention from
   what really are the major problems of dealing
   with STIX/CybOX (the fact that we use XML
   is *not* the issue that will decide between success
   or failure). And currently, I must says,
   I am not sure that we can take the time to
   solve the major issues *and* change the
   binding.

II) I agree with the list of problem points that
    Aharon has sent around some days ago: these are
    things we need to solve *first*.

III) To Aharon's list, I would add the problem of
    embedded relationship info rather than describing
    relations between entities/objects separately --
    that is a major design flaw of STIX/CybOX.

IV) 80% (or say 60% or whatever -- at least a substantial percentage)
    of STIX/CybOX has never been used so far. We should consider
    simplifying drastically.

V) Another source of complexity: CybOX tries to be all-encompassing,
   including the expression of what are essentially certain types of
   signatures (that is where the logical operations come in) as well
   as the description of all kinds of observable stuff, going even
   into rather detailed forensic information. In contrast to this, the
   #1 use case most people are after is the sharing of rather simple
   basic indicators ("observable patterns", "things to look
   for").

   So here is a bit of heresy: Maybe we should consider a
   STIX-without-CybOX variant in which basic indicators can be
   expressed in a very simple key/value-list-kind-of-way (where
   mappings to default-representations into CybOX make sure that we
   have well-defined semantics and the link to CybOX is preserved)
   without logical operators.

Now in detail:

I) Regarding the big issue of XML vs. JSON vs. "something else":

I do not think that XML vs JSON will be decisive regarding the
question whether STIX/CybOX will be relevant in future: there
are advantages and disadvantages to both.

What, however, will be decisive, is whether STIX/CybOX really
are helpful in expressing and consuming useful cyber-threat intelligence.

As others have already said on the mailing list: the main issues that
currently make STIX and CybOX hard to deal with have *nothing* to
do with the fact that we currently express things in XML rather than
JSON.

I think the main questions in going forward is: what should we
spend our (limited) resources on when moving towards the next
major release?

What I am worried about is that switching the representation
from XML to something else will lead to significant delay
as well as draw focus from the topics that really matter to
the format issue rather than the really pressing issues.

Maybe I am overestimating the required effort of switching
the binding, but let us not be fooled by the idea that
having a piece of code that produces/consumes, say, JSON,
constitutes a language definition. The problem of
defining a JSON binding is definitely harder that "just take
XYZ's current JSON implementation (with XYZ being Mitre,
Intelworks, Bluecoat or whatever) and be done with it." --
especially since none of the existing JSON implementations
is even close to a complete coverage of either STIX
or CybOX.

Right now, the tone on the mailing list suggests that
it is a given that the upcoming major releases of STIX
and CybOX will be based on a non-XML binding. Is that
really so?


II) Now, regarding the problems we should really focus on.
Aharon has made the following points:

1) Complex logical operations

2) Heavily nested objects

3) Object Versioning

4) Relationships that go 50 levels deep backwards and forwards.

5) Making it easy just to share a single evil URL with someone. Reduce verbosity ?

6) XPATH in the Marking Structure. Or the marking object in general.

7) Multiple ways to say the same thing

8) Almost every field being optional

I agree to these points. Let me add/expand to that below.

III) Relationship information embedded in STIX entity / CybOX Objects

   This, I feel, is the number one design flaw of STIX/CybOX in more than one
   ways:

   - there is no way to communicate a relationship between two things
     without (re)defining at least one of the things (namely the 'thing'
     into which the relationship info has to be embedded)

   - not all relationships that one might want to express are supported

     - why do I have to go through a campaign entity in order to
       associate an indicator with a threat actor?

     - why do I have to go through an incident to associate an incident
       with a threat actor

   - embedding of relationships leads to more complicated entity definitions
     and expressions (cf. Aaron's 2nd item)


IV) High complexity, of which 80% (a guess) have never been used so far

   If you look at python-stix/cybox, certainly the most comprehensive of
   all implementations for producing and consuming STIX/CybOX: there is still
   stuff missing. Also, if you look at what CybOX objects, or rather which parts
   of which CybOX objects, are supported by the existing STIX/CybOX-based
   systems, it is hard not to reach the following conclusion:

   We take a sledgehammer to crack a nut (or, as we say in Germany: we are building
   canons to shoot at sparrows).

   So we have a standard, for which there is no system able to either produce
   or ingest (and make sense of) even close to 100% of the standard.
   That is a problem, because

   - the unused 80% (or 50% or whatever) add complexity at all stages of
     dealing with the standard (defining it, tooling for it, ...)

   - the perceived benefit that we are future-proof in the sense
     that pretty much everything can be expressed, is not really much
     of a benefit: what use is it to be able to express something,
     which nobody is able to process?

   We try solve part of the problem with profiles that describe of how certain
   use-cases are to be encoded ... but if we find that those profiles
   use a 20% subset of the standard, maybe that tells us something?

V) Once more complexity: CybOX: Simple Indicators vs. Signatures vs. Observables/Forensics Information

   The way, CybOX is currently used in CTI exchange is, again, taking
   a sledgehammer against a nut:

   - The indicators, most of us currently are able to communicate and
     process are rather simple: a hash value, an URI, a domain name,
     an email address.

     So what usually happens is that the simplest of indicators are wrapped into
     a CybOX object, only to be unwrapped by the receiver and stuck into
     on of his six buckets of information he is able to deal with.

     That is fine, I guess, though if the producer starts adding information
     into CybOX objects, which is something the receiver's "unwrapping" code
     will ignore ... and it may take the receiver some time to realize
     that his automated processes are discarding information. Or the
     importer/unwrapper may even break, interpret things wrongly, ...

     Now take a look at what, e.g., MISP does: an indicator is
     basically a key-value pair, where the key describes the kind of indicator
     and the value the indicator itself:

     - the problem of inadvertently missing information does not occur: either
       I know how to deal with a certain indicator type or I do not

     - adding new indicator types takes as little as adding a new key rather
       than defining a whole new object type.

     There are, of course, also drawbacks to the MISP way of doing things,
     but currently, MISP is a lot closer to what is current practice in
     sharing technical indicators than CybOX.

  - Aharon mentioned the complex logical operations that are troublesome.

    Their genesis, that is at least my understanding, lies in the
    fact that STIX/CybOX owe a lot to OpenIOC.

    However: OpenIOC at its heart is a language for expressing
    signatures/patterns for a certain line of products and geared towards
    the capabilities of these products. If CybOX/STIX had started out, e.g.,
    from a line of thinking closer to a different product line, CybOX/STIX
    might look quite different. Why do we have logical operators, but
    not, say temporal, operators ("first this, then two times that, and
    then finally again this, all within 5 seconds"), as we have
    in SIEMs or network monitoring?

    Do we need/want CybOX/STIX to be an all-encompassing generic
    signature/pattern language? Or is that maybe a case for
    the current test-mechanism feature that allows the embedding
    of SNORT, OpenIOC and what have you?

  - Recently, Sean reminded us on the mailing list, that CybOX
    also has its uses in MAEC for malware expressions and in
    the expression of forensics information. It is great, that
    CybOX is so powerful and versatile ... but most of its
    power seems to be lost or even contra productive when it
    comes to getting basic CTI exchange started.

  Some time ago, Terry alerted us to the fine but important
  distinction between observable pattern (what to look out for)
  and observable instance (what has really been seen). Although
  we have talked about use-cases of communicating observable
  instances (I have seen this and that): the majority, I think,
  is interested in exchanging stuff to look out for.

  I may be committing heresy now, but let us think the unthinkable for
  a moment: How about a profile of STIX that allows communication of
  basic indicators (observable patterns) in a way that is closer to
  MISP's key-value pairs (with a well-defined mapping into CybOX
  proper), leaving full CybOX to cases in which observable instances
  (i.e., something that has been observed) are to be communicated?
  A mapping from such a simplified expression into a standard
  CybOX representation would then provide precise semantics and
  retain the link to CybOX-proper.


Kind regards,

Bernd

----

Bernd Grobauer, Siemens CERT


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
|

[cti-users] RE: [cti] Thoughts on STIX and some of the other threads on this list

Bush, Jonathan
So we are getting some good thoughts coming in now, but we still seem to be going in circles on what direction we are heading next.  Aharon - Do we have a 'next step' identified?  Is there any interest in an in-person meeting?

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Grobauer, Bernd
Sent: Wednesday, September 09, 2015 7:49 AM
To: [hidden email]; [hidden email]
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list

Hi,

this is a bit late, but there were several requests for broad feedback on the major issue of what the future should look like, so here goes ...

First, for the impatient, reader, the contents of what comes below in a nutshell:

I) If we change the binding from XML to something else
   for the next major release, we need to be sure that
   the effort of doing so does neither slow us
   down to much nor distract too much attention from
   what really are the major problems of dealing
   with STIX/CybOX (the fact that we use XML
   is *not* the issue that will decide between success
   or failure). And currently, I must says,
   I am not sure that we can take the time to
   solve the major issues *and* change the
   binding.

II) I agree with the list of problem points that
    Aharon has sent around some days ago: these are
    things we need to solve *first*.

III) To Aharon's list, I would add the problem of
    embedded relationship info rather than describing
    relations between entities/objects separately --
    that is a major design flaw of STIX/CybOX.

IV) 80% (or say 60% or whatever -- at least a substantial percentage)
    of STIX/CybOX has never been used so far. We should consider
    simplifying drastically.

V) Another source of complexity: CybOX tries to be all-encompassing,
   including the expression of what are essentially certain types of
   signatures (that is where the logical operations come in) as well
   as the description of all kinds of observable stuff, going even
   into rather detailed forensic information. In contrast to this, the
   #1 use case most people are after is the sharing of rather simple
   basic indicators ("observable patterns", "things to look
   for").

   So here is a bit of heresy: Maybe we should consider a
   STIX-without-CybOX variant in which basic indicators can be
   expressed in a very simple key/value-list-kind-of-way (where
   mappings to default-representations into CybOX make sure that we
   have well-defined semantics and the link to CybOX is preserved)
   without logical operators.

Now in detail:

I) Regarding the big issue of XML vs. JSON vs. "something else":

I do not think that XML vs JSON will be decisive regarding the question whether STIX/CybOX will be relevant in future: there are advantages and disadvantages to both.

What, however, will be decisive, is whether STIX/CybOX really are helpful in expressing and consuming useful cyber-threat intelligence.

As others have already said on the mailing list: the main issues that currently make STIX and CybOX hard to deal with have *nothing* to do with the fact that we currently express things in XML rather than JSON.

I think the main questions in going forward is: what should we spend our (limited) resources on when moving towards the next major release?

What I am worried about is that switching the representation from XML to something else will lead to significant delay as well as draw focus from the topics that really matter to the format issue rather than the really pressing issues.

Maybe I am overestimating the required effort of switching the binding, but let us not be fooled by the idea that having a piece of code that produces/consumes, say, JSON, constitutes a language definition. The problem of defining a JSON binding is definitely harder that "just take XYZ's current JSON implementation (with XYZ being Mitre, Intelworks, Bluecoat or whatever) and be done with it." -- especially since none of the existing JSON implementations is even close to a complete coverage of either STIX or CybOX.

Right now, the tone on the mailing list suggests that it is a given that the upcoming major releases of STIX and CybOX will be based on a non-XML binding. Is that really so?


II) Now, regarding the problems we should really focus on.
Aharon has made the following points:

1) Complex logical operations

2) Heavily nested objects

3) Object Versioning

4) Relationships that go 50 levels deep backwards and forwards.

5) Making it easy just to share a single evil URL with someone. Reduce verbosity ?

6) XPATH in the Marking Structure. Or the marking object in general.

7) Multiple ways to say the same thing

8) Almost every field being optional

I agree to these points. Let me add/expand to that below.

III) Relationship information embedded in STIX entity / CybOX Objects

   This, I feel, is the number one design flaw of STIX/CybOX in more than one
   ways:

   - there is no way to communicate a relationship between two things
     without (re)defining at least one of the things (namely the 'thing'
     into which the relationship info has to be embedded)

   - not all relationships that one might want to express are supported

     - why do I have to go through a campaign entity in order to
       associate an indicator with a threat actor?

     - why do I have to go through an incident to associate an incident
       with a threat actor

   - embedding of relationships leads to more complicated entity definitions
     and expressions (cf. Aaron's 2nd item)


IV) High complexity, of which 80% (a guess) have never been used so far

   If you look at python-stix/cybox, certainly the most comprehensive of
   all implementations for producing and consuming STIX/CybOX: there is still
   stuff missing. Also, if you look at what CybOX objects, or rather which parts
   of which CybOX objects, are supported by the existing STIX/CybOX-based
   systems, it is hard not to reach the following conclusion:

   We take a sledgehammer to crack a nut (or, as we say in Germany: we are building
   canons to shoot at sparrows).

   So we have a standard, for which there is no system able to either produce
   or ingest (and make sense of) even close to 100% of the standard.
   That is a problem, because

   - the unused 80% (or 50% or whatever) add complexity at all stages of
     dealing with the standard (defining it, tooling for it, ...)

   - the perceived benefit that we are future-proof in the sense
     that pretty much everything can be expressed, is not really much
     of a benefit: what use is it to be able to express something,
     which nobody is able to process?

   We try solve part of the problem with profiles that describe of how certain
   use-cases are to be encoded ... but if we find that those profiles
   use a 20% subset of the standard, maybe that tells us something?

V) Once more complexity: CybOX: Simple Indicators vs. Signatures vs. Observables/Forensics Information

   The way, CybOX is currently used in CTI exchange is, again, taking
   a sledgehammer against a nut:

   - The indicators, most of us currently are able to communicate and
     process are rather simple: a hash value, an URI, a domain name,
     an email address.

     So what usually happens is that the simplest of indicators are wrapped into
     a CybOX object, only to be unwrapped by the receiver and stuck into
     on of his six buckets of information he is able to deal with.

     That is fine, I guess, though if the producer starts adding information
     into CybOX objects, which is something the receiver's "unwrapping" code
     will ignore ... and it may take the receiver some time to realize
     that his automated processes are discarding information. Or the
     importer/unwrapper may even break, interpret things wrongly, ...

     Now take a look at what, e.g., MISP does: an indicator is
     basically a key-value pair, where the key describes the kind of indicator
     and the value the indicator itself:

     - the problem of inadvertently missing information does not occur: either
       I know how to deal with a certain indicator type or I do not

     - adding new indicator types takes as little as adding a new key rather
       than defining a whole new object type.

     There are, of course, also drawbacks to the MISP way of doing things,
     but currently, MISP is a lot closer to what is current practice in
     sharing technical indicators than CybOX.

  - Aharon mentioned the complex logical operations that are troublesome.

    Their genesis, that is at least my understanding, lies in the
    fact that STIX/CybOX owe a lot to OpenIOC.

    However: OpenIOC at its heart is a language for expressing
    signatures/patterns for a certain line of products and geared towards
    the capabilities of these products. If CybOX/STIX had started out, e.g.,
    from a line of thinking closer to a different product line, CybOX/STIX
    might look quite different. Why do we have logical operators, but
    not, say temporal, operators ("first this, then two times that, and
    then finally again this, all within 5 seconds"), as we have
    in SIEMs or network monitoring?

    Do we need/want CybOX/STIX to be an all-encompassing generic
    signature/pattern language? Or is that maybe a case for
    the current test-mechanism feature that allows the embedding
    of SNORT, OpenIOC and what have you?

  - Recently, Sean reminded us on the mailing list, that CybOX
    also has its uses in MAEC for malware expressions and in
    the expression of forensics information. It is great, that
    CybOX is so powerful and versatile ... but most of its
    power seems to be lost or even contra productive when it
    comes to getting basic CTI exchange started.

  Some time ago, Terry alerted us to the fine but important
  distinction between observable pattern (what to look out for)
  and observable instance (what has really been seen). Although
  we have talked about use-cases of communicating observable
  instances (I have seen this and that): the majority, I think,
  is interested in exchanging stuff to look out for.

  I may be committing heresy now, but let us think the unthinkable for
  a moment: How about a profile of STIX that allows communication of
  basic indicators (observable patterns) in a way that is closer to
  MISP's key-value pairs (with a well-defined mapping into CybOX
  proper), leaving full CybOX to cases in which observable instances
  (i.e., something that has been observed) are to be communicated?
  A mapping from such a simplified expression into a standard
  CybOX representation would then provide precise semantics and
  retain the link to CybOX-proper.


Kind regards,

Bernd

----

Bernd Grobauer, Siemens CERT


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

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/

Reply | Threaded
Open this post in threaded view
|

[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Trey Darley-3
A face-to-face would likely prove both productive as well as *highly* entertaining.



Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: [hidden email] <[hidden email]> on behalf of Bush, Jonathan <[hidden email]>
Sent: Wednesday, September 9, 2015 15:16
To: 'Grobauer, Bernd'; [hidden email]; [hidden email]
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list

So we are getting some good thoughts coming in now, but we still seem to be going in circles on what direction we are heading next.  Aharon - Do we have a 'next step' identified?  Is there any interest in an in-person meeting?


Reply | Threaded
Open this post in threaded view
|

[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Jordan, Bret
In reply to this post by Bush, Jonathan
I would love a F2F.  And I think Bernd has brought up some really good points.  


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 Sep 9, 2015, at 07:16, Bush, Jonathan <[hidden email]> wrote:

So we are getting some good thoughts coming in now, but we still seem to be going in circles on what direction we are heading next.  Aharon - Do we have a 'next step' identified?  Is there any interest in an in-person meeting?

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Grobauer, Bernd
Sent: Wednesday, September 09, 2015 7:49 AM
To: [hidden email]; [hidden email]
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list

Hi,

this is a bit late, but there were several requests for broad feedback on the major issue of what the future should look like, so here goes ...

First, for the impatient, reader, the contents of what comes below in a nutshell:

I) If we change the binding from XML to something else
  for the next major release, we need to be sure that
  the effort of doing so does neither slow us
  down to much nor distract too much attention from
  what really are the major problems of dealing
  with STIX/CybOX (the fact that we use XML
  is *not* the issue that will decide between success
  or failure). And currently, I must says,
  I am not sure that we can take the time to
  solve the major issues *and* change the
  binding.

II) I agree with the list of problem points that
   Aharon has sent around some days ago: these are
   things we need to solve *first*.

III) To Aharon's list, I would add the problem of
   embedded relationship info rather than describing
   relations between entities/objects separately --
   that is a major design flaw of STIX/CybOX.

IV) 80% (or say 60% or whatever -- at least a substantial percentage)
   of STIX/CybOX has never been used so far. We should consider
   simplifying drastically.

V) Another source of complexity: CybOX tries to be all-encompassing,
  including the expression of what are essentially certain types of
  signatures (that is where the logical operations come in) as well
  as the description of all kinds of observable stuff, going even
  into rather detailed forensic information. In contrast to this, the
  #1 use case most people are after is the sharing of rather simple
  basic indicators ("observable patterns", "things to look
  for").

  So here is a bit of heresy: Maybe we should consider a
  STIX-without-CybOX variant in which basic indicators can be
  expressed in a very simple key/value-list-kind-of-way (where
  mappings to default-representations into CybOX make sure that we
  have well-defined semantics and the link to CybOX is preserved)
  without logical operators.

Now in detail:

I) Regarding the big issue of XML vs. JSON vs. "something else":

I do not think that XML vs JSON will be decisive regarding the question whether STIX/CybOX will be relevant in future: there are advantages and disadvantages to both.

What, however, will be decisive, is whether STIX/CybOX really are helpful in expressing and consuming useful cyber-threat intelligence.

As others have already said on the mailing list: the main issues that currently make STIX and CybOX hard to deal with have *nothing* to do with the fact that we currently express things in XML rather than JSON.

I think the main questions in going forward is: what should we spend our (limited) resources on when moving towards the next major release?

What I am worried about is that switching the representation from XML to something else will lead to significant delay as well as draw focus from the topics that really matter to the format issue rather than the really pressing issues.

Maybe I am overestimating the required effort of switching the binding, but let us not be fooled by the idea that having a piece of code that produces/consumes, say, JSON, constitutes a language definition. The problem of defining a JSON binding is definitely harder that "just take XYZ's current JSON implementation (with XYZ being Mitre, Intelworks, Bluecoat or whatever) and be done with it." -- especially since none of the existing JSON implementations is even close to a complete coverage of either STIX or CybOX.

Right now, the tone on the mailing list suggests that it is a given that the upcoming major releases of STIX and CybOX will be based on a non-XML binding. Is that really so?


II) Now, regarding the problems we should really focus on.
Aharon has made the following points:

1) Complex logical operations

2) Heavily nested objects

3) Object Versioning

4) Relationships that go 50 levels deep backwards and forwards.

5) Making it easy just to share a single evil URL with someone. Reduce verbosity ?

6) XPATH in the Marking Structure. Or the marking object in general.

7) Multiple ways to say the same thing

8) Almost every field being optional

I agree to these points. Let me add/expand to that below.

III) Relationship information embedded in STIX entity / CybOX Objects

  This, I feel, is the number one design flaw of STIX/CybOX in more than one
  ways:

  - there is no way to communicate a relationship between two things
    without (re)defining at least one of the things (namely the 'thing'
    into which the relationship info has to be embedded)

  - not all relationships that one might want to express are supported

    - why do I have to go through a campaign entity in order to
      associate an indicator with a threat actor?

    - why do I have to go through an incident to associate an incident
      with a threat actor

  - embedding of relationships leads to more complicated entity definitions
    and expressions (cf. Aaron's 2nd item)


IV) High complexity, of which 80% (a guess) have never been used so far

  If you look at python-stix/cybox, certainly the most comprehensive of
  all implementations for producing and consuming STIX/CybOX: there is still
  stuff missing. Also, if you look at what CybOX objects, or rather which parts
  of which CybOX objects, are supported by the existing STIX/CybOX-based
  systems, it is hard not to reach the following conclusion:

  We take a sledgehammer to crack a nut (or, as we say in Germany: we are building
  canons to shoot at sparrows).

  So we have a standard, for which there is no system able to either produce
  or ingest (and make sense of) even close to 100% of the standard.
  That is a problem, because

  - the unused 80% (or 50% or whatever) add complexity at all stages of
    dealing with the standard (defining it, tooling for it, ...)

  - the perceived benefit that we are future-proof in the sense
    that pretty much everything can be expressed, is not really much
    of a benefit: what use is it to be able to express something,
    which nobody is able to process?

  We try solve part of the problem with profiles that describe of how certain
  use-cases are to be encoded ... but if we find that those profiles
  use a 20% subset of the standard, maybe that tells us something?

V) Once more complexity: CybOX: Simple Indicators vs. Signatures vs. Observables/Forensics Information

  The way, CybOX is currently used in CTI exchange is, again, taking
  a sledgehammer against a nut:

  - The indicators, most of us currently are able to communicate and
    process are rather simple: a hash value, an URI, a domain name,
    an email address.

    So what usually happens is that the simplest of indicators are wrapped into
    a CybOX object, only to be unwrapped by the receiver and stuck into
    on of his six buckets of information he is able to deal with.

    That is fine, I guess, though if the producer starts adding information
    into CybOX objects, which is something the receiver's "unwrapping" code
    will ignore ... and it may take the receiver some time to realize
    that his automated processes are discarding information. Or the
    importer/unwrapper may even break, interpret things wrongly, ...

    Now take a look at what, e.g., MISP does: an indicator is
    basically a key-value pair, where the key describes the kind of indicator
    and the value the indicator itself:

    - the problem of inadvertently missing information does not occur: either
      I know how to deal with a certain indicator type or I do not

    - adding new indicator types takes as little as adding a new key rather
      than defining a whole new object type.

    There are, of course, also drawbacks to the MISP way of doing things,
    but currently, MISP is a lot closer to what is current practice in
    sharing technical indicators than CybOX.

 - Aharon mentioned the complex logical operations that are troublesome.

   Their genesis, that is at least my understanding, lies in the
   fact that STIX/CybOX owe a lot to OpenIOC.

   However: OpenIOC at its heart is a language for expressing
   signatures/patterns for a certain line of products and geared towards
   the capabilities of these products. If CybOX/STIX had started out, e.g.,
   from a line of thinking closer to a different product line, CybOX/STIX
   might look quite different. Why do we have logical operators, but
   not, say temporal, operators ("first this, then two times that, and
   then finally again this, all within 5 seconds"), as we have
   in SIEMs or network monitoring?

   Do we need/want CybOX/STIX to be an all-encompassing generic
   signature/pattern language? Or is that maybe a case for
   the current test-mechanism feature that allows the embedding
   of SNORT, OpenIOC and what have you?

 - Recently, Sean reminded us on the mailing list, that CybOX
   also has its uses in MAEC for malware expressions and in
   the expression of forensics information. It is great, that
   CybOX is so powerful and versatile ... but most of its
   power seems to be lost or even contra productive when it
   comes to getting basic CTI exchange started.

 Some time ago, Terry alerted us to the fine but important
 distinction between observable pattern (what to look out for)
 and observable instance (what has really been seen). Although
 we have talked about use-cases of communicating observable
 instances (I have seen this and that): the majority, I think,
 is interested in exchanging stuff to look out for.

 I may be committing heresy now, but let us think the unthinkable for
 a moment: How about a profile of STIX that allows communication of
 basic indicators (observable patterns) in a way that is closer to
 MISP's key-value pairs (with a well-defined mapping into CybOX
 proper), leaving full CybOX to cases in which observable instances
 (i.e., something that has been observed) are to be communicated?
 A mapping from such a simplified expression into a standard
 CybOX representation would then provide precise semantics and
 retain the link to CybOX-proper.


Kind regards,

Bernd

----

Bernd Grobauer, Siemens CERT


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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

[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Aharon Chernin
In reply to this post by Bush, Jonathan
> As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

Eric, I just wanted to say I agree with your thought processes.

To the community: this is why I think we should be focusing on the consumer, not the vendor. If the consumer expects STIX products to "just work", then the consumer will give the correct message to the vendor community. Making vendors happy does not necessarily equate to happy customers, or the adoption of our interoperative vision. There are ways vendors can adopt STIX/TAXII without actually making their product interoperate with other products. But, there is no way a vendor can get around delivering exactly what the consumer wants to fulfill their demand.

Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | [hidden email]
www.soltra.com

________________________________________
From: [hidden email] <[hidden email]> on behalf of Eric Burger <[hidden email]>
Sent: Wednesday, September 9, 2015 2:02 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list

My $0.02, after letting folks get the gas out.

Q1: Format on the Wire
========================
Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

So, one and only one data exchange format, please.

Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


Q2: Formal Data Model
=========================
Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

So, what are my proposals?

First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

Thanks.

P.S. I’m up for a meeting in DC, too ;-).



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
|

[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Jordan, Bret
In reply to this post by Bush, Jonathan
Eric, great points and well said.  I like your top level vision for this group as well, it is clear this is not your first rodeo.  

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.  
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used.  It just works....   Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.  

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products. 

On the TAXII side, we are pushing to these Value statements.  We are pushing for simplicity, elegance, and ease of use.  We want TAXII to be the best way for sharing CTI, period.  We want it to be so easy that there is no reason why you would not do it.  We want it to just work and be so conceptually easy to understand.  

I think that Eric and Bernd have really spelled out a call to action for this group.  Lets answer the call, lets work together, lets solve this.  

I believe we can solve this.  I believe we as a group are smart enough and have enough collective wisdom to do it.  I believe that we can really make a long-term difference in cyber security.  I have a vision for where the SOC of the future needs to go, and I want to see us get there.  
 

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 Sep 9, 2015, at 12:02, Eric Burger <[hidden email]> wrote:

My $0.02, after letting folks get the gas out.

Q1: Format on the Wire
========================
Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

So, one and only one data exchange format, please.

Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


Q2: Formal Data Model
=========================
Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

So, what are my proposals?

First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

Thanks.

P.S. I’m up for a meeting in DC, too ;-).





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

[cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

John Anderson


Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows. 😊


I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.


Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.


It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter 5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:


What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?


Sincerely,

John Anderson


PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.




From: [hidden email] <[hidden email]> on behalf of Jordan, Bret <[hidden email]>
Sent: Wednesday, September 9, 2015 3:40 PM
To: Eric Burger
Cc: [hidden email]; [hidden email]
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
 
Eric, great points and well said.  I like your top level vision for this group as well, it is clear this is not your first rodeo.  

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.  
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used.  It just works....   Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.  

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products. 

On the TAXII side, we are pushing to these Value statements.  We are pushing for simplicity, elegance, and ease of use.  We want TAXII to be the best way for sharing CTI, period.  We want it to be so easy that there is no reason why you would not do it.  We want it to just work and be so conceptually easy to understand.  

I think that Eric and Bernd have really spelled out a call to action for this group.  Lets answer the call, lets work together, lets solve this.  

I believe we can solve this.  I believe we as a group are smart enough and have enough collective wisdom to do it.  I believe that we can really make a long-term difference in cyber security.  I have a vision for where the SOC of the future needs to go, and I want to see us get there.  
 

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 Sep 9, 2015, at 12:02, Eric Burger <[hidden email]> wrote:

My $0.02, after letting folks get the gas out.

Q1: Format on the Wire
========================
Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

So, one and only one data exchange format, please.

Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


Q2: Formal Data Model
=========================
Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

So, what are my proposals?

First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

Thanks.

P.S. I’m up for a meeting in DC, too ;-).




Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

pmaroney
John,

Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures"?

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Pat

_____________________________
From: John Anderson <[hidden email]>
Sent: Wednesday, September 9, 2015 5:29 PM
Subject: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
To: <[hidden email]>
Cc: <[hidden email]>



Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows. 😊


I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.


Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.


It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter <a href="x-apple-data-detectors://6" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="6"> 5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:


What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?


Sincerely,

John Anderson


PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.




From: [hidden email] <[hidden email]> on behalf of Jordan, Bret <[hidden email]>
Sent: Wednesday, September 9, 2015 3:40 PM
To: Eric Burger
Cc: [hidden email]; [hidden email]
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
 
Eric, great points and well said.  I like your top level vision for this group as well, it is clear this is not your first rodeo.  

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.  
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used.  It just works....   Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.  

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products. 

On the TAXII side, we are pushing to these Value statements.  We are pushing for simplicity, elegance, and ease of use.  We want TAXII to be the best way for sharing CTI, period.  We want it to be so easy that there is no reason why you would not do it.  We want it to just work and be so conceptually easy to understand.  

I think that Eric and Bernd have really spelled out a call to action for this group.  Lets answer the call, lets work together, lets solve this.  

I believe we can solve this.  I believe we as a group are smart enough and have enough collective wisdom to do it.  I believe that we can really make a long-term difference in cyber security.  I have a vision for where the SOC of the future needs to go, and I want to see us get there.  
 

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 <a href="tel:7415%200050" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="19"> 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Sep 9, 2015, at 12:02, Eric Burger < [hidden email]> wrote:

My $0.02, after letting folks get the gas out.

Q1: Format on the Wire
========================
Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

So, one and only one data exchange format, please.

Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


Q2: Formal Data Model
=========================
Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

So, what are my proposals?

First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

Thanks.

P.S. I’m up for a meeting in DC, too ;-).






Reply | Threaded
Open this post in threaded view
|

[cti-users] Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Jason Keirstead

John - REST is one of the topics we have actively been exploring on the TAXII slack channel.

Please take a look at our TAXII Blue Sky REST ideation page here - https://github.com/FreeCTI/BlueSky/wiki/HTTP-REST-API .

NOTE This is an ideation page only as it is easier to discuss ideas that are written down. We welcome your comments.

-
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 Patrick Maroney ---09/09/2015 05:43:40 PM---John, Presume you are referring to Roy Thomas Fielding's Patrick Maroney ---09/09/2015 05:43:40 PM---John, Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and

From: Patrick Maroney <[hidden email]>
To: John Anderson <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 09/09/2015 05:43 PM
Subject: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
Sent by: <[hidden email]>





John,

Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures"?

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Pat

_____________________________
From: John Anderson <
[hidden email]>
Sent: Wednesday, September 9, 2015 5:29 PM
Subject: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
To: <
[hidden email]>
Cc: <
[hidden email]>



Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows. 😊

I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.

Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.

It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter <a href="x-apple-data-detectors://6/">5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:

What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?

Sincerely,
John Anderson

PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.



From: [hidden email] <[hidden email]> on behalf of Jordan, Bret <[hidden email]>
Sent:
Wednesday, September 9, 2015 3:40 PM
To:
Eric Burger
Cc:
[hidden email]; [hidden email]
Subject:
Re: [cti] Thoughts on STIX and some of the other threads on this list

Eric, great points and well said. I like your top level vision for this group as well, it is clear this is not your first rodeo.

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used. It just works.... Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products.

On the TAXII side, we are pushing to these Value statements. We are pushing for simplicity, elegance, and ease of use. We want TAXII to be the best way for sharing CTI, period. We want it to be so easy that there is no reason why you would not do it. We want it to just work and be so conceptually easy to understand.

I think that Eric and Bernd have really spelled out a call to action for this group. Lets answer the call, lets work together, lets solve this.

I believe we can solve this. I believe we as a group are smart enough and have enough collective wisdom to do it. I believe that we can really make a long-term difference in cyber security. I have a vision for where the SOC of the future needs to go, and I want to see us get there.


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 <a href="tel:7415%200050">7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
      On Sep 9, 2015, at 12:02, Eric Burger < [hidden email]> wrote:

      My $0.02, after letting folks get the gas out.

      Q1: Format on the Wire
      ========================
      Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

      As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

      So, one and only one data exchange format, please.

      Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


      Q2: Formal Data Model
      =========================
      Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

      One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

      If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

      So, what are my proposals?

      First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

      Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

      Thanks.

      P.S. I’m up for a meeting in DC, too ;-).






Reply | Threaded
Open this post in threaded view
|

[cti-users] Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

John Anderson
In reply to this post by Jordan, Bret

Jason,

Thanks for the link. I looked at the document. It looks like it defines a JSON/RPC API that uses HTTP Status Codes. That's definitely a step up on the Richardson Maturity Model than POSTed XML SOAP/RPC. (However, some have questioned whether the RMM is a valid path to true REST.) Thanks for sharing, esp. sharing code examples.


What Fielding describes in Chapter 5 is quite different. I'd be curious to see how the TAXII 2.0 specification treats Resources, Content-Types, and Link Relations (critical to HATEOAS). With those three building blocks in place, the data formats (aka, Representations) should fall into place.


Personally, I would implement Representations first in XHTML, because XHTML enables the plain vanilla web browser to be a client. (And along with that, you get a great automation ecosystem.) But by talking about a data format, I'm getting ahead of more critical questions: namely, Resources, Content-Types and Link Relations.


CyBOX provides well-defined data structures that could easily morph into Resources (and Content-Types). STIX describes many object relationships that could easily map to Link Relations. The biggest bit of impedance mismatch is the way STIX/CyBOX handle Object IDs; those should probably just graduate to resolvable URIs.

What other parts of TAXII could be brought into greater alignment with Chapter 5?
John



From: Jason Keirstead <[hidden email]>
Sent: Wednesday, September 9, 2015 6:23 PM
To: Patrick Maroney
Cc: John Anderson; [hidden email]; [hidden email]
Subject: Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
 

John - REST is one of the topics we have actively been exploring on the TAXII slack channel.

Please take a look at our TAXII Blue Sky REST ideation page here - https://github.com/FreeCTI/BlueSky/wiki/HTTP-REST-API .

NOTE This is an ideation page only as it is easier to discuss ideas that are written down. We welcome your comments.

-
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 Patrick Maroney ---09/09/2015 05:43:40 PM---John, Presume you are referring to Roy Thomas Fielding's Patrick Maroney ---09/09/2015 05:43:40 PM---John, Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and

From: Patrick Maroney <[hidden email]>
To: John Anderson <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 09/09/2015 05:43 PM
Subject: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
Sent by: <[hidden email]>





John,

Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures"?

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Pat

_____________________________
From: John Anderson <
[hidden email]>
Sent: Wednesday, September 9, 2015 5:29 PM
Subject: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
To: <
[hidden email]>
Cc: <
[hidden email]>



Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows. ��

I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.

Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.

It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter 5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:

What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?

Sincerely,
John Anderson

PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.



From: [hidden email] <[hidden email]> on behalf of Jordan, Bret <[hidden email]>
Sent:
Wednesday, September 9, 2015 3:40 PM
To:
Eric Burger
Cc:
[hidden email]; [hidden email]
Subject:
Re: [cti] Thoughts on STIX and some of the other threads on this list

Eric, great points and well said. I like your top level vision for this group as well, it is clear this is not your first rodeo.

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used. It just works.... Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products.

On the TAXII side, we are pushing to these Value statements. We are pushing for simplicity, elegance, and ease of use. We want TAXII to be the best way for sharing CTI, period. We want it to be so easy that there is no reason why you would not do it. We want it to just work and be so conceptually easy to understand.

I think that Eric and Bernd have really spelled out a call to action for this group. Lets answer the call, lets work together, lets solve this.

I believe we can solve this. I believe we as a group are smart enough and have enough collective wisdom to do it. I believe that we can really make a long-term difference in cyber security. I have a vision for where the SOC of the future needs to go, and I want to see us get there.


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 <a href="tel:7415%200050">7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
      On Sep 9, 2015, at 12:02, Eric Burger < [hidden email]> wrote:

      My $0.02, after letting folks get the gas out.

      Q1: Format on the Wire
      ========================
      Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

      As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

      So, one and only one data exchange format, please.

      Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


      Q2: Formal Data Model
      =========================
      Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

      One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

      If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

      So, what are my proposals?

      First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

      Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

      Thanks.

      P.S. I’m up for a meeting in DC, too ;-).






Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

Jordan, Bret
John,

Please join the TAXII subcommittee and the TAXII slack channel.  We would love to get all of your ideas and have you help us design and build the future of TAXII.  Soltra is a member of OASIS so it is easy for you to join.  

Once you do this we can move these development and future design discussions in to their appropriate places.

Thanks 

Bret 

Sent from my Commodore 64

On Sep 9, 2015, at 7:23 PM, John Anderson <[hidden email]> wrote:

Jason,

Thanks for the link. I looked at the document. It looks like it defines a JSON/RPC API that uses HTTP Status Codes. That's definitely a step up on the Richardson Maturity Model than POSTed XML SOAP/RPC. (However, some have questioned whether the RMM is a valid path to true REST.) Thanks for sharing, esp. sharing code examples.


What Fielding describes in Chapter 5 is quite different. I'd be curious to see how the TAXII 2.0 specification treats Resources, Content-Types, and Link Relations (critical to HATEOAS). With those three building blocks in place, the data formats (aka, Representations) should fall into place.


Personally, I would implement Representations first in XHTML, because XHTML enables the plain vanilla web browser to be a client. (And along with that, you get a great automation ecosystem.) But by talking about a data format, I'm getting ahead of more critical questions: namely, Resources, Content-Types and Link Relations.


CyBOX provides well-defined data structures that could easily morph into Resources (and Content-Types). STIX describes many object relationships that could easily map to Link Relations. The biggest bit of impedance mismatch is the way STIX/CyBOX handle Object IDs; those should probably just graduate to resolvable URIs.

What other parts of TAXII could be brought into greater alignment with Chapter 5?
John



From: Jason Keirstead <[hidden email]>
Sent: Wednesday, September 9, 2015 6:23 PM
To: Patrick Maroney
Cc: John Anderson; [hidden email]; [hidden email]
Subject: Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
 

John - REST is one of the topics we have actively been exploring on the TAXII slack channel.

Please take a look at our TAXII Blue Sky REST ideation page here - https://github.com/FreeCTI/BlueSky/wiki/HTTP-REST-API .

NOTE This is an ideation page only as it is easier to discuss ideas that are written down. We welcome your comments.

-
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


Patrick Maroney ---09/09/2015 05:43:40 PM---John, Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and

From: Patrick Maroney <[hidden email]>
To: John Anderson <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 09/09/2015 05:43 PM
Subject: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
Sent by: <[hidden email]>





John,

Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures"?

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Pat

_____________________________
From: John Anderson <
[hidden email]>
Sent: Wednesday, September 9, 2015 5:29 PM
Subject: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
To: <
[hidden email]>
Cc: <
[hidden email]>



Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows.

I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.

Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.

It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter 5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:

What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?

Sincerely,
John Anderson

PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.



From: [hidden email] <[hidden email]> on behalf of Jordan, Bret <[hidden email]>
Sent:
Wednesday, September 9, 2015 3:40 PM
To:
Eric Burger
Cc:
[hidden email]; [hidden email]
Subject:
Re: [cti] Thoughts on STIX and some of the other threads on this list

Eric, great points and well said. I like your top level vision for this group as well, it is clear this is not your first rodeo.

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used. It just works.... Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products.

On the TAXII side, we are pushing to these Value statements. We are pushing for simplicity, elegance, and ease of use. We want TAXII to be the best way for sharing CTI, period. We want it to be so easy that there is no reason why you would not do it. We want it to just work and be so conceptually easy to understand.

I think that Eric and Bernd have really spelled out a call to action for this group. Lets answer the call, lets work together, lets solve this.

I believe we can solve this. I believe we as a group are smart enough and have enough collective wisdom to do it. I believe that we can really make a long-term difference in cyber security. I have a vision for where the SOC of the future needs to go, and I want to see us get there.


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 <a href="tel:7415%200050">7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
      On Sep 9, 2015, at 12:02, Eric Burger < [hidden email]> wrote:

      My $0.02, after letting folks get the gas out.

      Q1: Format on the Wire
      ========================
      Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

      As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

      So, one and only one data exchange format, please.

      Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


      Q2: Formal Data Model
      =========================
      Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

      One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

      If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

      So, what are my proposals?

      First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

      Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

      Thanks.

      P.S. I’m up for a meeting in DC, too ;-).






Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list

John Anderson

Bret,

Could you point me to the right information about getting connected with the TAXII Slack channel, please?

Thanks,

JSA




From: Jordan, Bret <[hidden email]>
Sent: Wednesday, September 9, 2015 10:45 PM
To: John Anderson
Cc: Jason Keirstead; Patrick Maroney; [hidden email]; [hidden email]
Subject: Re: [cti-users] Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
 
John,

Please join the TAXII subcommittee and the TAXII slack channel.  We would love to get all of your ideas and have you help us design and build the future of TAXII.  Soltra is a member of OASIS so it is easy for you to join.  

Once you do this we can move these development and future design discussions in to their appropriate places.

Thanks 

Bret 

Sent from my Commodore 64

On Sep 9, 2015, at 7:23 PM, John Anderson <[hidden email]> wrote:

Jason,

Thanks for the link. I looked at the document. It looks like it defines a JSON/RPC API that uses HTTP Status Codes. That's definitely a step up on the Richardson Maturity Model than POSTed XML SOAP/RPC. (However, some have questioned whether the RMM is a valid path to true REST.) Thanks for sharing, esp. sharing code examples.


What Fielding describes in Chapter 5 is quite different. I'd be curious to see how the TAXII 2.0 specification treats Resources, Content-Types, and Link Relations (critical to HATEOAS). With those three building blocks in place, the data formats (aka, Representations) should fall into place.


Personally, I would implement Representations first in XHTML, because XHTML enables the plain vanilla web browser to be a client. (And along with that, you get a great automation ecosystem.) But by talking about a data format, I'm getting ahead of more critical questions: namely, Resources, Content-Types and Link Relations.


CyBOX provides well-defined data structures that could easily morph into Resources (and Content-Types). STIX describes many object relationships that could easily map to Link Relations. The biggest bit of impedance mismatch is the way STIX/CyBOX handle Object IDs; those should probably just graduate to resolvable URIs.

What other parts of TAXII could be brought into greater alignment with Chapter 5?
John



From: Jason Keirstead <[hidden email]>
Sent: Wednesday, September 9, 2015 6:23 PM
To: Patrick Maroney
Cc: John Anderson; [hidden email]; [hidden email]
Subject: Re: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
 

John - REST is one of the topics we have actively been exploring on the TAXII slack channel.

Please take a look at our TAXII Blue Sky REST ideation page here - https://github.com/FreeCTI/BlueSky/wiki/HTTP-REST-API .

NOTE This is an ideation page only as it is easier to discuss ideas that are written down. We welcome your comments.

-
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


Patrick Maroney ---09/09/2015 05:43:40 PM---John, Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and

From: Patrick Maroney <[hidden email]>
To: John Anderson <[hidden email]>, "[hidden email]" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 09/09/2015 05:43 PM
Subject: [cti] Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
Sent by: <[hidden email]>





John,

Presume you are referring to Roy Thomas Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures"?

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Pat

_____________________________
From: John Anderson <
[hidden email]>
Sent: Wednesday, September 9, 2015 5:29 PM
Subject: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
To: <
[hidden email]>
Cc: <
[hidden email]>



Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows.

I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.

Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.

It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter 5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:

What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?

Sincerely,
John Anderson

PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.



From: [hidden email] <[hidden email]> on behalf of Jordan, Bret <[hidden email]>
Sent:
Wednesday, September 9, 2015 3:40 PM
To:
Eric Burger
Cc:
[hidden email]; [hidden email]
Subject:
Re: [cti] Thoughts on STIX and some of the other threads on this list

Eric, great points and well said. I like your top level vision for this group as well, it is clear this is not your first rodeo.

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used. It just works.... Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products.

On the TAXII side, we are pushing to these Value statements. We are pushing for simplicity, elegance, and ease of use. We want TAXII to be the best way for sharing CTI, period. We want it to be so easy that there is no reason why you would not do it. We want it to just work and be so conceptually easy to understand.

I think that Eric and Bernd have really spelled out a call to action for this group. Lets answer the call, lets work together, lets solve this.

I believe we can solve this. I believe we as a group are smart enough and have enough collective wisdom to do it. I believe that we can really make a long-term difference in cyber security. I have a vision for where the SOC of the future needs to go, and I want to see us get there.


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 <a href="tel:7415%200050">7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
      On Sep 9, 2015, at 12:02, Eric Burger < [hidden email]> wrote:

      My $0.02, after letting folks get the gas out.

      Q1: Format on the Wire
      ========================
      Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.

      As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.

      So, one and only one data exchange format, please.

      Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.


      Q2: Formal Data Model
      =========================
      Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.

      One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.

      If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.

      So, what are my proposals?

      First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.

      Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.

      Thanks.

      P.S. I’m up for a meeting in DC, too ;-).