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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


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


Yes, probably a 405.  The spec did not try to call out ever error code that could be returned, just the common ones.

If this is in error, please send to the comments list with your suggestions on what should be fixed so we can fix that.  

Bret 

Sent from my Commodore 64 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On May 12, 2017, at 11:30 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I would expect it to return code 405if a collection was read-only.

This seems to be missing from the TAXII spec so I'd probably return a 403 until we got that added.



-
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:        Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:        Terry MacDonald <terry.macdonald@cosive.com>, Allan Thomson <athomson@lookingglasscyber.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/12/2017 01:59 PM
Subject:        Re: [cti] Re: [EXT] [cti] Embedded Relationships
Sent by:        <cti@lists.oasis-open.org>




I wanted to send out a ping to see if anyone can answer my questions below. Maybe someone has a little downtime this Friday afternoon to help me. I’m really curious what the return value should be.
 
-Nate
 
 
From: <cti@lists.oasis-open.org> on behalf of "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>
Date:
Monday, May 8, 2017 at 10:26 AM
To:
Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:
Terry MacDonald <terry.macdonald@cosive.com>, Allan Thomson <athomson@lookingglasscyber.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

 
Since I cannot gauge everyone’s body language over email, and I have not met everyone I’m not sure how to read most of these emails. I hope my intent to learn and improve the spec is coming through my emails. Writing a spec is challenging, and I understand that.
 
> The key is that for a product to be called say a "TAXII Collection Server", it MUST implement all of the methods that are defined.
 
Thanks for that statement. I was not sure if that was the case, and that is how I interpreted the spec. Then can someone provide an example return code and JSON object for a POST request with regards to Jason’s comments on personas/profiles that do not act as a repository?
 
> 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.
 
I’m not sure what the return code should be. The POST documentation says, “This Endpoint allows authorized TAXII Clients to add objects to a specified collection.” I assume the return code is 202 because the other codes are error codes, even though it is not really being added to a collection. What is the expected return code?
 
I also do not know what the return JSON should be. The ‘status’ JSON object is listed as the expected return JSON object. What would be the status code inside of the ‘status’ object? I assume complete since no further processing is needed but would like clarification.
 
Then for each object that was in the POST request they need to be put into one of three bins, successes, failures, or pendings. Into which bin in the status return object would each of the objects go? Pendings does not seem like a good bin because you already processed it and getting the status later returns the same type of status return object. It seems like an infinite loop. Failures does not seem appropriate because that seems like an error case to me. If I received a failure I would probably try again, but maybe that is the expected bin? Successes is an option, but it is a List<status-success>. A status-success object contains a required attribute of a url that is “the URL location of the created object.” I take the POST description statement of “add objects to a specified collection” and a returned “URL location of the created object” to mean I could do a GET request to try and download that object that I added to the collection, but maybe that is an incorrect assumption? Which bin would contain the objects?
 
-Nate
 
 
From: Bret Jordan <Bret_Jordan@symantec.com>
Date:
Sunday, May 7, 2017 at 11:04 AM
To:
"Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:
Terry MacDonald <terry.macdonald@cosive.com>, Allan Thomson <athomson@lookingglasscyber.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

 
Nate,
 
Per the conformance clauses in section 8, if a product wants to be called a "TAXII Server" or a "TAXII Collection Server" then it MUST satisfy all of the requirements that are associated with that clause.
 
I think the problem is that you are assuming that because someone implements the GET methods, that the server has to answer them with data.  As Jason has illustrated so well, the server can do what ever it wants with the data. Further, and implementation of the said server can do anything they want with the data.
 
The key is that for a product to be called say a "TAXII Collection Server", it MUST implement all of the methods that are defined.  
 
Long-term, we may identify some "profiles" for TAXII, like some of the great ones that Jason has called out.  But those will be profiles for what you do with the data, not which features you get to implement.
 
Bret
 


From: Reller, Nathan S. <Nathan.Reller@jhuapl.edu>
Sent:
Friday, May 5, 2017 8:01:55 AM
To:
Jason Keirstead
Cc:
Terry MacDonald; Allan Thomson; Bret Jordan; Struse, Richard; John-Mark Gurney; cti@lists.oasis-open.org
Subject:
Re: [cti] Re: [EXT] [cti] Embedded Relationships

 
> 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










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