Re: [cti-taxii] Question about multiple trust group support

Now TBH, a few days ago on the Slack channel I was arguing very heavily for something similar. Basically, having TAXII do the group/trustgroup stuff. But after some thought and listening to everyones feedback I am beginning to think my initial view was wrong and I am starting to come to middle ground with the rest of this SC. My only concern still, and I will add this to the open questions as well. If TAXII does not deal with trust groups in the spec, then do we run the risk of having non-comparable systems". I do not know the answer to this question yet, but it is one I want us to look at over time.

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 Sep 24, 2015, at 10:19, Trey Darley <trey@SOLTRA.COM> wrote:

Hey, Jason -

Imagine that a large multinational corporation or informal sharing network (hub and spoke) wants to synchronize some or all of their TAXII trust groups. As things currently stand, that would necessarily involve out-of-band (ie, non-TAXII) communication. What I'm proposing is an optional block for sharing trust group info. Soltra Edge can encapsulate its notion of trust group data inside the soltra block. If Intelworks groks that, it can act on it. If not, it can safely disregard the data encapsulated in the block.

(Or maybe, just maybe several vendors collaborate to support interoperability.)

Extend the notion to n vendor-specific definition of trustgroups. TAXII can easily support sharing trustgroup information in-band without actually codifying any particular notion in the standard.

[again with the strawman]
<trustgroups>
<soltra>
...
</soltra>
<intelworks>
...
</intelworks>
<trustgroups>

Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Thursday, September 24, 2015 14:40
To: Trey Darley
Cc: Adam Cooper; Jordan, Bret; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Question about multiple trust group support

I am not sure I understand your proposal. What would be inside those blocks, and what is the purpose of exchanging that information from the server to the client?

-
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

Trey Darley ---09/24/2015 01:07:46 AM---I agree that trust groups are likely to remain vendor-specific and hence it's pointless trying to fo

From: Trey Darley <trey@soltra.com>
To: Adam Cooper <adam.cooper@digital.cabinet-office.gov.uk>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 09/24/2015 01:07 AM
Subject: Re: [cti-taxii] Question about multiple trust group support

I agree that trust groups are likely to remain vendor-specific and hence it's pointless trying to formalize trust groups per se in TAXII 2.0.

At the same time, TAXII 2.0 *should* have a mechanism for exchange of trust group data between compatible systems. If you grok a vendor's notion of trustgroups, you can do something with it. Otherwise, you can safely ignore it.

I envisage this as an optional block, a la (total strawman):

<trustgroups>
<soltra>
...
</soltra>
<intelworks>
...
</intelworks>
<trustgroups>

Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

From: cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Adam Cooper <adam.cooper@digital.cabinet-office.gov.uk>
Sent: Thursday, September 24, 2015 08:37
To: Jason Keirstead
Cc: Jordan, Bret; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Question about multiple trust group support

I have to agree with Jason: trust groups can be implemented in many ways and are often vendor or technology specific. Limiting implementation options through specification under TAXII adds nothing to the core purpose of TAXII in my mind and may actually limit adoption in COTS products.

Perhaps I am looking at this from a slightly purist approach but there are two things at play here: 1) the TAXII protocol, and 2) TAXII servers. The protocol should in my opinion should NOT be implementation specific and focus on the primary purpose of TAXII i.e. the exchange of cyber threat information. A TAXII server, again in my opinion, should be something that implements the protocol but can do so in any way the developer/vendor chooses provided it is compliant with the protocol standard. The TAXII server (implementation) is then able to implement things like trust groups freely.

Thanks,

Adam

cti-taxii message