Re: [cti-taxii] TAXII Architecture

[Mark Davidson <mdavidson@soltra.com>]

One key difference between OASIS specs and other specs (e.g., IETF) is that we can have multiple conformance clauses. In one document we could have a conformance clause for a “TAXII Repo” and another conformance clause for a “TAXII Broker”.

There is a lot of flexibility in how we define these things relate to each other (different conformance clauses, different work products, etc). Personally, and I suspect this is an underlying factor in the discussion, I think that Broker and Repository in all likelihood would be implemented as entirely different software systems that may or may not be packaged into the same product.

I view the attempt to say “MUST implement both” as a test. I think it would be better for interoperability and make writing TAXII Clients easier if there was only one type of software that could be a “TAXII Server”.  The test is whether this forces untenable requirements onto server implementers (i.e., you must get great gas mileage AND be able to tow 10,000 lbs).

So far I’m hearing plenty of arguments for optionality (an OR instead of an AND). I can be on board with “OR" as long as there is a reasonable solution for interoperability. Assuming we went with an “OR”, how would a TAXII Client detect what type of server it was interacting with, and how would users of TAXII Clients determine which pieces fit together? We should avoid the scenario where an end-user attempts to plug a TAXII Broker Client into a TAXII Repo Server and doesn’t understand why they don’t work together

Thank you.

-Mark

From: <cti-taxii@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Wednesday, December 16, 2015 at 10:58 AM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] TAXII Architecture

I think we are in violent agreement. This is why I posited we do not say “MUST be a repository.” However, we do need to have a minimal set of useful features, of which the repository set is a reasonable place to be.

I also think there should not be that much beyond what a repository would want to be a broker. If there is, then we are most likely talking two different protocols.

On Dec 16, 2015, at 10:28 AM, Wunder, John A. <jwunder@MITRE.ORG> wrote:

Note that what TAXII has defined for repositories is purely transport requirements….how they expose data, how data is transferred, etc. It explicitly is content-neutral.

The problem with having only the message broker is that while a lot of threat intel is shared as pub/sub, there are also requirements for request/response. Query, content libraries, and other request-response types of sharing patterns need to be considered as well, and the TAXII repository specification does that. It doesn’t define how the backend repository works, but it does define how to expose that data in a standard way (much as TAXII 1.1 did with its concept of data collections and query).

So…I agree with you on the scope of TAXII, but I think you’re misinterpreting what they mean when they say “repository spec” in the context of TAXII.

John

PS: I’m not saying that repository should be a MUST requirement. As I said earlier, I think we should let TAXII software support either or both.

From: <cti-taxii@lists.oasis-open.org> on behalf of Jerome Athias <athiasjerome@gmail.com>
Date: Wednesday, December 16, 2015 at 10:14 AM
To: Patrick Maroney <Pmaroney@specere.org>
Cc: Eric Burger <Eric.Burger@georgetown.edu>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] TAXII Architecture

I concur.

2015-12-16 18:12 GMT+03:00 Patrick Maroney <Pmaroney@specere.org>:

Do not concur at all with the shift to "Repositories" as a Must TAXII functionality.

TAXII should remain narrowly and specifically spec'd as the "Transport" Layer/Mechanism for CTI Inter-Exchange of STIX Packages.  

Section 5.2.1  of the current normative standard "got it right" from my perspective:

5.2.1 TAXII is Content Agnostic

The TAXII specifications do not provide details about the underlying content formats of records within TAXII. All content formats are a "black-box" as far as TAXII is concerned - none of the behaviors required to process TAXII at the message level require inspection of any information stored within message content. While TAXII Back-ends can have very different processing paths and requirements for different types of information, TAXII Services, Messages, and Exchanges are agnostic as to the information they convey. This allows TAXII to be usable for a wide array of sharing scenarios.

I suggest that there are:

TAXII Clients (AKA "TAXII Backends")

TAXII Gateways

A CTI Repository (which I do absolutely agree is a valuable component to add to the CTI Family of standards) should be a completely separate component of the CTI Standards

Patrick Maroney

Office:  (856)983-0001

Cell:      (609)841-5104

<C690F973-64C5-4C00-889B-C1A5BB4A2A0B[21].png>

President

Integrated Networking Technologies, Inc.

PO Box 569

Marlton, NJ 08053

From: <cti-taxii@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Wednesday, December 16, 2015 at 10:01 AM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>

Subject: Re: [cti-taxii] TAXII Architecture

I agree, which means how about this for a proposal:

<virtual text>

TAXII servers MUST implement repository functionality

TAXII servers MAY implement broker functionality

</virtual text>

The reason I said “virtual text” is the real text of the specification should say nothing normative about being a repository or broker. Rather, the real text just happens to require all TAXII servers to implement the things that make for repositories. The real text just happens to make the (hopefully tiny) set of things that only brokers care about to be optional. As a side note, the standards writing trick for saying “SHOULD do foo unless you are not a broker” is to say “MUST do foo if you are a broker.” That way you get strong normative language (no chance to screw up doing foo if you are a broker) without the wishy-washy language of SHOULD.

I do think we can have in the introductory material where we go over the architecture that TAXII servers can support repository and broker functionality. No need to hide what we do. However, there is no need to confuse people, either.

On Dec 16, 2015, at 8:08 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

" I can’t think of any “brokers” that wouldn’t reasonably also be a “repository”."

I agree that I can not see many vendors writing a broker-only software suite, HOWEVER I can see many clients running broker-only configurations at numerous positions of their network, including the edge. At those locations the software would be configured with repository disabled and should respond as such to a discovery msg...


-
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>Mark Davidson ---12/16/2015 08:22:14 AM---Here is a thought I'll throw out there. There will be TAXII Servers that implement the broker and re

From: Mark Davidson <mdavidson@soltra.com>
To: Trey Darley <trey@soltra.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 12/16/2015 08:22 AM
Subject: Re: [cti-taxii] TAXII Architecture
Sent by: <cti-taxii@lists.oasis-open.org>

---

Here is a thought I'll throw out there.

There will be TAXII Servers that implement the broker and repository functionality. I see these systems as the ones that will be attempting to facilitate exchange of information across systems/organizations. I can’t think of any “brokers” that wouldn’t reasonably also be a “repository”.

On the other hand, I can picture repositories that are hampered by broker requirements. A Threat Analyst workbench or SIEM might want to expose their threat information using  the TAXII repository concept (and perhaps even interact with a broker), but have no desire to facilitate the exchange of information across other systems/organizations via the broker concept.

To that end, maybe there are (notionally) two conformance clauses?

1. A TAXII Server implements both the broker and repository functionality.
2. A TAXII Repository implements only the repository functionality (we’d have to have some rule that maybe the broker side gives back an HTTP 501 - Not Implemented)

If this approach is taken, I would like to consider requiring or suggesting that only TAXII Servers are advertised in DNS and that TAXII Repositories are not.

This does go slightly against my desire to have a ‘TAXII' mean a single rigid thing, but I think there are systems out there that will want to offer a TAXII interface and not be a broker, and I view those systems as important to the overall threat sharing ecosystem.

Thoughts?

Thank you.
-Mark



On 12/16/15, 6:14 AM, "Trey Darley" <cti-taxii@lists.oasis-open.org on behalf of trey@soltra.com> wrote:

>On 15.12.2015 18:39:33, Jordan, Bret wrote:
>>
>> Question: Which of the following statements do you prefer? Or do you
>> prefer something all together different?
>>
>>
>> Option 1: A compliant TAXII server MAY implement the message broker
>> solution, the cyber information repository solution, or both.
>>
>> Option 2: A compliant TAXII server MUST implement the message broker
>> solution and the cyber information repository solution.
>>
>
>I would suggest a third option:
>
>"A compliant TAXII server MUST implement the message broker solution
>and SHOULD implement the cyber information repository solution."
>
>--
>Cheers,
>Trey
>--
>Trey Darley
>Senior Security Engineer
>4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
>Soltra | An FS-ISAC & DTCC Company
>www.soltra.com
>--
>"In protocol design, perfection has been reached not when there is
>nothing left to add, but when there is nothing left to take away."
>--RFC 1925

<C690F973-64C5-4C00-889B-C1A5BB4A2A0B[21].png>