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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

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


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


 

Hi!,

 

I tend to agree with Trey’s comments with each vendor and technology implementation basically making their own interpretation of what a trust group is and hence it could lead to a number of issues with coding and implementations.  Is another way to approach the problem (and maybe more true to form of what I think TAXII is when I think of it) to use something like PKI in the body of the TAXII message and hence you can only use the data if you have a valid key which belongs to a certain trust group.  This doesn’t get around the problem of key exchange and identifying/ensuring trust relationships although you could potentially add some verbage to the TAXII syntax to allow for key exchange. 

 

It would also potentially deal with trust repositories where other 3rd parties whether they are channels or brokers hold onto the data or act as a conduit for them.  Whilst in transit the indicators are protected and as long as the 3rd party broker or channel management knows how to read the header information can ensure delivery of the message.  It also potentially removes the need to have multiple channels setup for different trust groups.  Various trust groups could exist on the one channel, it is the consumer that needs to have the key to unlock and use the data.

 

Just an idea.

 

Regards,

 

Dean

 

From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Trey Darley
Sent: Thursday, 24 September 2015 6:08 PM
To: Adam Cooper; Jason Keirstead
Cc: Jordan, Bret; cti-taxii@lists.oasis-open.org
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

 


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

 

 


This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.



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