Re: [cti] Re: [EXT] [cti] Embedded Relationships

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I still think there is confusion here.
There is an assumption being made that if one POSTs something to a collection,
that later on someone can always GET that information back from the TAXII
server. There is actually no requirement in TAXII for this - nor hopefully
would there ever be as having such a requirement would severely limit what
could be done with TAXII. 

Just because I implement all of the
GET and POST methods for collections does not mean that anything that is
POSTed to a collection can later be fetched via GET. Examples...

- The data may have a short TTL on my
server and delete every hour

- The data may not be written to disk
at all and my GET endpoint always returns empty

- The GET endpoint on my server may
return a totally different set of dynamically generated data than what
is POSed to my server. As an example, I may make a system that accepts
inidcators to be POSTed to a collection, and sightings for those indicators
to be returned from GET on the collection.

Again I want to stress that there are
far more use cases for TAXII collections than a simple CRUD repository.

In fact if all we were trying to do
was define a CRUD repository, why do TAXII at all.... we could have just
used any number of existing standards like WebDAV for that, as WebDAV already
has everything you'd need for a CRUD repository of STIX data.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown




From:      
 "Reller, Nathan
S." <Nathan.Reller@jhuapl.edu>
To:      
 Jason Keirstead/CanEast/IBM@IBMCA
Cc:      
 Terry MacDonald <terry.macdonald@cosive.com>,
Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>,
"Struse, Richard" <Richard.Struse@hq.dhs.gov>, John-Mark
Gurney <jmg@newcontext.com>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Date:      
 05/05/2017 11:02 AM
Subject:    
   Re: [cti] Re:
[EXT] [cti] Embedded Relationships
Sent by:    
   <cti@lists.oasis-open.org>

---

> Again, you are assuming that people
are always occupying the "repository" persona. There are many
personas for TAXII, not all of which store data. I highly suggest you take
a look at the personas defined in the Interoperability Subcommittee's use
case specification - https://docs.google.com/document/d/1l54RhjxwuXrZUQ19zIHUiZ7_c6otbLbVVfluKJogU7s/edit#heading=h.4do73o99e2l7
 
OK, now I understand. In the specification
for TAXII I was reading Section 8 as meaning that all functions must be
implemented because it says, “It MUST support all requirements as defined
in section 3, section 4 and section 5.” It was unclear to me what that
really meant, but all of the collections API stuff is in Section 5. With
such a small spec it seemed to me that I must implement all of the methods.
Here you are saying that I do not.
 
I would suggest making it clearer that
you do not need to implement all of the methods and functionality. I would
compare this to the OASIS KMIP spec that does clearly indicate there are
different profiles and what methods and objects need to be implemented
for each profile. They even have a separate document to list all of the
different profiles, which I think you are calling personas although I don’t
quite get that feeling after skimming through the document you linked.
In the KMIP world if you don’t implement an operation then you MUST return
an error action of “Operation Failed” with reason “Operation Not Supported.”
Perhaps that is the intent of the 404 error, but I did not read it that
way. The KMIP spec also provides a Query method that returns all of the
supported operations. This way a client can verify what type of KMIP server
it is talking to.
 
KMIP v1.3 spec:
http://docs.oasis-open.org/kmip/spec/v1.3/os/kmip-spec-v1.3-os.html
 
KMIP v1.3 profiles:
http://docs.oasis-open.org/kmip/profiles/v1.3/os/kmip-profiles-v1.3-os.html
 
In addition to making it clear that not
all operations needed to be supported the profiles document provides a
nice checklist of what objects and functions need to be implemented. As
we implemented the KMIP spec for our open source library PyKMIP it was
nice to have a checklist of what needed to be implemented. For instance,
we first wanted to support symmetric keys. There is a profile called “Symmetric
Key Lifecycle Profiles” and it tells me which algorithms and key types
I need to implement. It seems like there is some of that in the personas
document, but in my opinion I think the KMIP format is much cleaner to
read. The nice part about the personas document is that it provides more
context, so maybe we could combine the approaches? I think that would be
very helpful to readers.
 
Symmetric Key Lifecycle Profiles:
http://docs.oasis-open.org/kmip/profiles/v1.3/os/kmip-profiles-v1.3-os.html#_Toc473103134
 
For what it’s worth, KMIP Specification
1.3 and KMIP Profiles 1.3 are finalists for the “Outstanding Approved
Standard” at the 2017 Open Standards Cup.
 
-Nate
 
 
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, May 4, 2017 at 2:10 PM
To: "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>
Cc: Terry MacDonald <terry.macdonald@cosive.com>, Allan Thomson
<athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>,
"Struse, Richard" <Richard.Struse@hq.dhs.gov>, John-Mark
Gurney <jmg@newcontext.com>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] [cti] Embedded Relationships
 
> Could you further explain this? I
don’t understand how something can be a TAXII server but not have a historical
database. 
> I feel that it must have some repository/database of information to
store the POSTed objects temporarily until a TAXII client 
> does a GET request. Otherwise where do you get the STIX objects that
are used in steps 4 and 6 above? A proxy I get,
> but that is really just a middle-man between a real TAXII server.

Again, you are assuming that people are always occupying the "repository"
persona. There are many personas for TAXII, not all of which store data.
I highly suggest you take a look at the personas defined in the Interoperability
Subcommittee's use case specification - https://docs.google.com/document/d/1l54RhjxwuXrZUQ19zIHUiZ7_c6otbLbVVfluKJogU7s/edit#heading=h.4do73o99e2l7

Just because you POST TAXII information to me, does not mean you can then
later GET that same information from me, because I may not be acting as
any kind of repository. I may not even have a TAXII "read" facility
at all, and only accept POSTs to a channel or collection, and all GETs
against the channel or collection return empty all the time. A use case
for this may be a device that wants to expose a TAXII collection or channel
to allow people to submit CTI to it to trigger some action, such as adding
something to a watch list or launching a remediation. As such, I have no
need to store this information at all, anywhere.

Or, to flip it around, I may offer a read-only view of a channel or collection
and not anyone to ever POST anything to it at all. A use case for this
might be a proxy device that exposes live sighting information on a channel
or collection. This information would all be read-only, live, streaming
data from the device.... there is no repository, and if you go back to
that device in an hour those objects wouldn't even exist on it anymore.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown