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
PresidentIntegrated Networking Technologies, Inc.PO Box 569Marlton, 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 functionalityTAXII 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
