Re: [cti-taxii] The need (or no need) for TAXII to support Query

["Ron Williams" <Ron.Williams@us.ibm.com>]

Protocol Specs aren't API specs. They simply describe the 'standard' message sequences and their message's format. A Web Services API is really a protocol. Protocol Services are responsible for participating in proper message sequence interchanges, and proper handling of their message formats. RestFUL Web Services 'API's' are really protocols with a simple call response / sessionless character - hence their confusion with 'API.' So if by 'API direction' we're talking RestFUL Web Services - I content it's still protocol and should be handled as one. Multi-sequence protocol requests (i.e. Multi-Part POLL Requests) require a proper protocol sequence and message definitions for both caller and responder. An API spec does not handle this well unless you bury the protocol operations.

The specification should describe sequence and message formats for all elements of a conversation between client and server. That's why this is a Protocol Spec, and not an API spec.

Cheers!

~r

ron.williams@us.ibm.com | stsm, ibm master inventor | chief architect, infrastructure protection | divisional idt lead | ibm | mobile +1.512.633.7711 | ofc +1.720.349.2236
羅恩·威廉姆斯 | 首席架構師基礎設施保護 | IBM安全
"It is much less dangerous to think like a man of action, than to act like a man of thought." - Nicholas Nassim Taleb


"Jordan, Bret" ---10/19/2015 18:24:50---Would it be possible to treat Query as a separate work product and specification TAXII SC? The reas

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Terry MacDonald <terry.macdonald@threatloop.com>, Mark Davidson <mdavidson@mitre.org>, Trey Darley <trey@soltra.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 10/19/2015 18:24
Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query
Sent by: <cti-taxii@lists.oasis-open.org>

---

Would it be possible to treat Query as a separate work product and specification TAXII SC?  The reason for this is I think a Query Specification / Work Product will need tight coupling to both TAXII and the CTI language under the covers.   With the TAXII API model that we are moving to, I could see entry points for query on that API that supports things like STIX, CybOX, IODEF, OpenIOC, FB ThreatExchange, etc.  


Thanks,

Bret



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

On Oct 19, 2015, at 05:14, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:


Agree 100% with your vision Terry and I think you expressed the argument better than I.

Now my question is, how to make it a reality :) IE, if STIX is responsible for answering QUERY messages, how does this work...

Presumably, if TAXII 2.0 was a REST service, then you would want QUERY 2.0 to be a REST service as well so that servers who have TAXII can also run a QUERY endpoint on the same port.

So that is feasible, but the question is, how do we come up with the specification for this service. Is this something for the STIX SC? Or a "QUERY" SC?

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

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


<graycol.gif>Terry MacDonald ---2015/10/17 01:22:25 AM---Hi All, Just splitting this out into its own thread so we can all keep track :)

From: Terry MacDonald <terry.macdonald@threatloop.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Davidson II, Mark S" <mdavidson@mitre.org>, Trey Darley <trey@soltra.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/10/17 01:22 AM
Subject: [cti-taxii] The need (or no need) for TAXII to support Query
Sent by: <cti-taxii@lists.oasis-open.org>

---




Hi All,

Just splitting this out into its own thread so we can all keep track :)

I half agree with Jason :). I think Query is outside of the scope of TAXII, but I also think it is the responsbility of each carried protocol to provide its own query and response functionality if it requires it.

To me TAXII has the express purpose of enabling the sharing of CTI data (over a channel). To me that means that TAXII is only worried about:

- ensuring everyone allowed to see the CTI data channel sees it
- allowing people to request access to the CTI data channel
- allowing channel owners to allow access to the CTI data channel

TAXII should effectively treat the information carried within TAXII as a 'black box' from the TAXII perspective. As an example, if a TAXII channel is carrying STIX data, then it should be the responsibility of STIX to ask queries for STIX data. Similarly, if in the future TAXII carries VERIS classification data, then it should be the responsibility of VERIS to ask queries for VERIS data. TAXII should just ensure that the data gets to where it should go, and that only those who are allowed to see it, receive it. (And that it is marked to contain either STIX or VERIS data so the receiving TAXII process knows which process to hand the carried data to.

Loosely coupling TAXII from the data it carries gives us future flexibility for what TAXII can carry. Tightly coupling TAXII by enforcing support for STIX querying restricts this flexibility, and ensures that when new version of STIX is released we will need to release a new version of TAXII query to support it. And then restricts the ability for us to add new protocols to be carried by TAXII (e.g. VERIS) as new TAXII query releases would be required there too.

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant

M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com



Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My opinions do not necessarily reflect those of Threatloop.com.

[attachment "signature.asc" deleted by Ron Williams/Austin/IBM]