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

RE the below:

I would assert this is not necessarily true. If there is a TAXII server in the cloud, and I am paying for access to it as a client - I would not expect that I have administrative control over that service and that I can make my own sharing channels. Rather I would just expect them to tell me what channel or channels to use, and I would use those. Those channels might be sourcing data from other internal data structures, the idea that I can always create them for every service doesn't make sense.

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

Inactive hide details for "Jordan, Bret" ---2015/09/29 02:49:17 PM---I do not disagree with you.  And I can fully understand th"Jordan, Bret" ---2015/09/29 02:49:17 PM---I do not disagree with you. And I can fully understand the desire for there to be a tear line / Chi

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Mark Davidson <mdavidson@mitre.org>, Terry MacDonald <terry.macdonald@threatloop.com>, "Thompson, Dean" <Dean.Thompson@anz.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/09/29 02:49 PM
Subject: Re: [cti-taxii] Question about multiple trust group support
Sent by: <cti-taxii@lists.oasis-open.org>

I do not disagree with you. And I can fully understand the desire for there to be a tear line / Chinese wall between certain aspects. I also fully get why vendors need and want to own certain parts of it.

I would propose that there are two fundamental elements we are looking at:

A) Vendor developed deployment

B) Vendor agnostic deployment

In a Vendor developed solution, it makes perfect sense to have the specification be a loose as possible. This allows a vendor to claim compliance without having to do or change their implementation strategy. In a Vendor agnostic solution, you need to make sure everyones clients and servers can all work together and talk together.

So the crutch of the problem is part of the use-case that I sent out earlier that I am still wanting reviewed. In that use case I tried to come up with an example to help illustrate the issues that I see.

So in a vendor agnostic deployment, say a TAXII Server in the cloud, how SHOULD two desperate parties, using different TAXII clients / APPs connect and share information? Realizing that these two people will NEED and WANT to create their own permissions to make sure only they can see each others CTI information. This has two steps:
1) Create channels for their private use
2) Create permissions for these channels / aka a trust group / aka specify which users can access the channel

Now valid options for this are:
1) This is up to the vendor who produces the TAXII Server in the cloud and clients will use an API path. So the work flow is for User 1 to login in to the web interface of the TAXII Server in the cloud and setup the trust group, channels, and permissions. Then via an out-of-band method, transfer that information to User 2. Doing this, keeps all provisioning out of the spec and keeps clients pretty dumb. This also means that every TAXII Server in the cloud might do this differently. It also means that short-lived or temporary channels / trust groups will be painful to setup as it can NOT be done at the client level without each client, which might be produced be some other vendor, knowing the proprietary APIs to do this for every single cloud TAXII Server.

2) Add some of this functionality either to the API or to messages on the API. This would enable clients to tell a TAXII Server that they are requesting a new channel or trust group and that the following users / groups should have access to it.

Now in the event of a organizational deployed solution, that is internet facing say in the DMZ, the idea of provisioning new channels and trust groups, will probably never pass muster from local change control at an organization. They will obviously not allow someone on the outside to setup new channels and they will probably require change control for some one on the inside.

Our current model and architecture for TAXII works in the following two use cases:
1) Intra-organization (device to device)
2) Inter-organization (Org to ISAO, ISAC to ISAC, Gov to CERT, etc)

Where I think things break down, IMO, is addressing the user to user sharing of CTI outside of email / IM, meaning how do two people use TAXII to share CTI?



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."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

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