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

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

+1 on the entire below message, this is also how I saw things working (federation vs. single silo)

Also, I would say, if there is a use case where a single trust group wants to use many TAXII servers - then they can federate their logins and groups totally outside TAXII if they choose, via LDAP or any other such system. It is really no different than for example, multiple mail servers in an organization or multiple <any other type of server> - the group management and permission management is synchronized outside the core protocol (usually using LDAP or a derivative like AD)

-
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


"Davidson II, Mark S" ---2015/09/30 10:30:48 AM---Terry, thank you for the message – great points. I’d like to hone in on what I see a key topic: a tr

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

---

Terry, thank you for the message – great points.
 
I’d like to hone in on what I see a key topic: a trust group using multiple TAXII servers (or not).
 
My view of the world has been that each Trust Group would exist on only one TAXII Server (e.g., EX-ISAO uses https://exisao.example.com/taxii/ as it’s API Base). A single trust group spread across multiple servers (e.g., indicators channel is on example.com; logs channel is on mitre.org; but they are the same trust group) seems like it would be fairly complicated to define and implement, and I don’t have a clear understanding of the benefit.
 
Instead of spreading a Trust Group across TAXII Servers, I’ve envisioned the interaction between trust groups to be something like federation, where a worker from trust group A pushes info to trust group B (regardless of whether they live on the same server or not).
 
For the sake of taking a side primarily to spur discussion: Is there a scenario that requires a trust group spread across multiple TAXII Servers?
 
For what it’s worth, I see scalability and locality as implementation specific aspects of a TAXII Server (I call this out specifically so it can be challenged). A high quality TAXII Server would be robust enough to support lots of messages / connections, and ideally would have locally available servers (e.g., if you are in US, you connect to a US server; if you are in EU, connect to an EU server; message passing happens through engineering wizardry in the backend).
 
Thank you.
-Mark

From: Terry MacDonald [mailto:terry.macdonald@threatloop.com]
Sent: Tuesday, September 29, 2015 9:03 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>; Davidson II, Mark S <mdavidson@mitre.org>; Terry MacDonald <terry.macdonald@threatloop.com>; Thompson, Dean <Dean.Thompson@anz.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Question about multiple trust group support

Hi All,

My concern with leaving groups completely out of the scope of TAXII is that it:
· Only allows trustgroups to exist on one vendors TAXII server (no interoperability for large international trustgroups)
· It forces manual configuration with details entered by hand (potential for errors and doesn't scale)
· If a trustgroup has a large international multi-organization membership, and they share a channel, addition of any new members becomes problematic:
o Member would need to be added manually across multiple vendors to enable mesh sharing (vs add once and the members details are shared across all members)
o OR all members of the trustgroup would be forced to use a single vendors product to get the group membership functionality working.
It won't scale, and it won't make it easy to use different vendors products to handle large scale trustgroups with an international multi-organization membership. There are a large number of these groups, most requiring members to not acknowledge they exist, but they do. They require the ability to manage members from across the globe. They will use many different vendors implementations as their TAXII Servers. They WILL need a way to determine if a trustgroup member has the right to access the data in a channel.

In Bret's email he summarized the following:

Summary
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)

I actually believe that the current implementation will only work effectively within item 1 - Intra-organization. Item 2 - Inter-organization will only work in a few scenarios, due to the requirement for both parties to manually enter in the group membership (just like an old pre-shared key VPN).

It will work inter-organization:
· when the all the members use the same vendor (then the vendor can patch TAXII so it will work)
· when the membership is small enough that all members within the 'mesh' network are able dedicate resources to updating their membership manually
It won't work inter-organization:
· when the membership is large (one trustgroup has 1459 members as of today)
· when administration of the membership is handled by multiple parties (all trustgroups I am a member of are like this)
· when the the TAXII server is a 'public' TAXII server to allow the general public to exchange information (this will happen when it becomes easy to do)
I firmly believe that without the ability to do basic group membership we will be greatly impacting the usability of TAXII for sharing threats at scale.

Another point to note - TAXII doesn't need to support a complete group management protocol - it only needs:
· to have the ability to announce details to the other members of the group,
· answer queries from member TAXII servers asking for if a TAXII client or server should be allowed access to the channel or group.
Things like:
· TAXII Server ServerA from OrgA is authorized to be a member of TrustgroupA and here are their details.
· TAXII Server ServerA from OrgA is authorized to access channelX
·
In my mind, the actual authentication databases are implementation specific, and are handled differently by each implementation. Each implementation will need to receive the TAXII new member announcement and store the details within their system. This will ensure that if the new member connects to any other TAXII server that is a member of the trustgroup, they will be granted permission. We effectively create a worldwide high-availability pool of servers.

It is important to note at this point that not all TAXII servers will be allowed to administer the group and/or channels. The access to these will need to be restricted, so that the trustgroup administrative personnel are the only ones who are able to authorize new members. We may still need to be able to allow a trustgroup to allow anyone to join a trustgroup and post to their channels, just in case fully open untrusted public sharing is something that people would want to do.



Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant

M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com



Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 30 September 2015 at 05:17, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

RE the below:

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:
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


"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.

Question
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.

Summary
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?




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 29, 2015, at 07:02, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I don't believe anything management-related (creating groups, adding/removing people from groups, making channels, subscribing people to channels) should be part of the TAXII spec.

This is all highly implementation specific, and has nothing to do with a CTI data transfer protocol.

TAXII should not be not an extension to LDAP - lets leave this task to protocols designed from the ground-up to handle enterprise-grade user and group management.


-
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>"Davidson II, Mark S" ---2015/09/29 09:50:20 AM---I agree that groups are important. IMO, under the latest proposed concept, trust groups are still a

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, Terry MacDonald <terry.macdonald@threatloop.com>
Cc: "Thompson, Dean" <Dean.Thompson@anz.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/09/29 09:50 AM
Subject: RE: [cti-taxii] Question about multiple trust group support
Sent by: <cti-taxii@lists.oasis-open.org>


---





I agree that groups are important. IMO, under the latest proposed concept, trust groups are still a thing and still matter, they are just outside the scope of the TAXII specifications (Note: I assert this specifically so that it can be challenged).

Responding to Jason’s point: I think right now we are partly having a scoping discussion. Earlier, Bret offered (IMO) four good scope labels: Spec, Implementation, Deployment, and Process. I haven’t attempted to label the questions in this way, but perhaps it’s a good way to think about them. We will certainly end up talking through things that are beyond the scope of a spec in order to make sure the spec is sane.

I updated the REST API design per our current discussion [1] (changes: [2]); note that the current proposal is that the API-Base concept forms the boundary around a trust group.

In terms of Terry’s questions:

> What channels the trustgroup offers?
> What type of information is sent on each channel?
[MD] These should be covered by the API already (we haven’t come up with straw-man objects yet; should we do that?)

> How to join a channel?
> How to be approved to access the channel?
> How to post data to the channel?
> How to leave a channel?
[MD] IMO this would be covered under subscriptions (subscribe, unsubscribe); we haven’t totally fleshed out subscriptions yet, I’ve started a discussion on the wiki page

> How to prove their identity?
[MD] IMO this will covered under authentication parts of the spec

> List who is receiving the data sent to the channel?
[MD] No way to do this under the current proposal; maybe it should be added? I would look at this as “list current subscribers” (perhaps just part of a channel-info object?)

> Am I allowed to post data to the channel?
[MD] If you POST and get an HTTP 403 or 501, you are not. Though the API response for channel info could be updated to include this information

> Where else to connect to when the current TAXII server fails?
[MD] Not sure – would this be handled by typical networking techniques for HTTP reliability/availability? E.g., round-robin DNS or failover?

Next, I’ll get to the Trust Group questions

> Where the nearest TAXII server is for a trustgroup
[MD] This concept is not covered in the latest proposal. Is this a requirement?

> How to join a trustgroup
[MD] We haven’t fleshed out whether this is a requirement or how to do it (I’ve subbed out a /management/ portion of the API for exploring this).

> How to prove their identity
[MD] IMO would be covered under authentication parts of the spec

> How to be approved as a trustgroup member
[MD] We haven’t fleshed out whether this is a requirement or how to do it.

At least for me, I think this raises an open question:
· What management commands need to be available at any given API-Base? Nominally, these could be exposed by at [API-Base]/management/<something?>/

Comments/opinions welcome.

Thank you.
-Mark

[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/HTTP-REST-API-for-TAXII-2.0
[2] https://github.com/TAXIIProject/TAXII-Specifications/wiki/HTTP-REST-API-for-TAXII-2.0/_compare/a4e6bef68741d0258fa7c29d2e62a466d76437ae...fb3101f7cf5cb7839fdabc61cdc4e4088ee2b808
From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com]
Sent: Tuesday, September 29, 2015 7:44 AM
To: Terry MacDonald <terry.macdonald@threatloop.com>
Cc: Davidson II, Mark S <mdavidson@mitre.org>; Thompson, Dean <Dean.Thompson@anz.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Question about multiple trust group support

While I agree that every bullet you have below is important in an effective CTI sharing initiative - the problem is, almost every bullet is also very organization and tool-set specific.

The methodology and requirements I personally have to provide, or a toolset has to provide, in order to prove my identity at the FS-ISAC may not be the same as at IBM or ThreatLoop - in fact it is almost assuredly not the same. Similarly, at IBM trust groups may already exist as they are used throughout the organization, while at another organization trust groups will be specific to CTI. In one organization / tool-set, you may not "join" channels at all because you will be auto-assigned channels based on your role or the type of tool you are.

I can make similar points for most of these items.

This is the problem I have with trying to standardize this type of thing (users / groups) - if this is part of the standard, then the standard won't be able to be consumed.


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>Terry MacDonald ---2015/09/28 11:00:56 PM--- Hi All In my humble opinion, having group membership is an important part of how

From: Terry MacDonald <terry.macdonald@threatloop.com>
To: Terry MacDonald <terry.macdonald@threatloop.com>, "Davidson II, Mark S" <mdavidson@mitre.org>, "Thompson, Dean" <Dean.Thompson@anz.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/09/28 11:00 PM
Subject: Re: [cti-taxii] Question about multiple trust group support
Sent by: <cti-taxii@lists.oasis-open.org>


---






Hi All
In my humble opinion, having group membership is an important part of how channel and group administrators will control access to channels.

That said, having a channel's group ownership reflected in the REST API path isn't necessary, as long as there is another mechanism for reflecting that relationship. In fact, having a group within the REST path may in fact make the things more difficult, e.g. if the trustgroup name changes, then the REST endpoint will change. Removing the group name from within the REST API path is a good idea.

I still believe that the group discovery mechanisms are needed in order to ensure interoperability of different vendors implementations. How will a new organization be able all the channels a trustgroup offers otherwise? How will a new TAXII Client know:
· Where the nearest TAXII server is for a trustgroup
· How to join a trustgroup
· How to prove their identity
· How to be approved as a trustgroup member
· What channels the trustgroup offers
· What type of information is sent on each channel
· How to join a channel
· How to prove their identity
· How to be approved to access the channel
· Where else to connect to when the current TAXII server fails
· How to leave a channel
· Am I allowed to post data to the channel
· How to post data to the channel
· List who is receiving the data sent to the channel
Groups not only make the TAXII clients life easier, but they also make the TAXII server admins life easier. With groups a TAXII server admin can create a group and then give 'control' of that group to different user to administer. That user then can worry about making sure that only the 'right' people are given access to that group. Members of that trustgroup are then automatically allowed to access the channels that the group is responsible for. This system also would allow for trustgroup administration to be spread across multiple servers i.e. a trustgroup could be administered by two users on two different TAXII Servers - e.g. one on Soltra and the other on Intelworks. Ensuring a standard mechanism for sharing this information allows for this decentralization to occur.

It seems like a good idea to separate groups from channels, but I still think they are useful. I would like to see something like this:

GET /groups - Returns a list of available/accessible groups
GET /groups/<group-name>/ - Returns information about a group, including the channels available in the group

GET /channels - Returns a list of all publicly listed channels
GET /channels?group=<group-name> - Returns a list of channels that are part of an unlisted group
POST /channels?group=<group-name> - Returns a list of channels that are part of an unlisted group that requires authentication
GET /channels/<channel-name>/ - Returns info about a specific channel


Comments?

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant

M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com



Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 28 September 2015 at 22:28, Davidson II, Mark S <mdavidson@mitre.org> wrote:
Are there any comments on this? If not, I’d like to assert that this represents the (for now) general feelings of the group and take the following actions:

· Update the REST API [1] to: remove groups, add the concept of an API Base, document the DNS SRV concept

· Update the REST API to call out the removed capabilities: General group discovery and no common convention for API Base beyond the “well known value”

· Attempt to describe trust groups in a way that would be in the spec (e.g., say they exist, but say that they are explicitly not in the spec)

If we are in rough agreement about the REST API (I think we are – but please speak up if you have concerns/comments that are not accounted for), working through the scenario Bret’s offered would be a good way to validate the REST API’s current state, at least for one use-case/workflow.

Thank you.

-Mark

[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/HTTP-REST-API-for-TAXII-2.0

From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Davidson II, Mark S
Sent: Thursday, September 24, 2015 8:26 AM
To: Thompson, Dean <Dean.Thompson@anz.com>; 'cti-taxii@lists.oasis-open.org' <cti-taxii@lists.oasis-open.org>

Subject: RE: [cti-taxii] Question about multiple trust group support
I realize my email gets down into the design a bit, but here’s what I’m thinking:
· Trust groups are a thing, they just don’t belong inside the scope of the spec.

· The REST API gets updated to remove the “/groups/<groupname>/” layer, and only has the “/channels/<channelname>” part

· Multiple instances of the REST API can exist on a server

· Each instance of the REST API has something called an “API Base” (we can probably pick a better name) that is the root of the REST API instance. One server can have as many “API Bases” as they like.

I see there being two basic cases for TAXII integration: configuration-based, and auto-discovery.

In the auto-discovery case, discovery would probably be based off of a DNS SRV record. A DNS SRV record would advertise something like “The TAXII server I want you to use is at $hostname:$port” (Note: You can NOT specify a URL in DNS SRV records). The spec could have an algorithm for coming up with a well-known “API Base” from DNS – notionally https://$hostname:$port/well-known-value/. For this to work, there’d have to be a requirement/expectation that any TAXII Server advertised in DNS has this well-known API base. I see this as a critical enabler for plug-and-play capabilities.

In the configuration-based case, I think all you have to do is configure a client to use the API Base – e.g., if I had an online threat portal, I could say “If you want to use my threat portal, use https://example.com:443/my_portal_api_base/ as your API base”. This would of course require other products to allow a configurable API Base (and possible multiple configurable API bases for integrating with multiple TAXII Servers).

This idea draws a boundary around channel groupings, but without specifying a group concept in the spec. If your implementation only needs one API base – go for it. If you want multiple API bases for multiple some other reason (multiple groups, sub-groups, etc), you can have that.

I do see a couple drawbacks to this design, as compared to groups being in the spec:

· No more auto-discovery of groups
o This could be mitigated by somehow adding another feature (maybe)
· There might not be a common convention for multiple API bases (e.g., I might use hostnames, you might use ports, somebody else might use URLs).
o Hopefully this is mitigated by having the API base be an opaque string.
Thoughts? I’m particularly interested in drawbacks I didn’t call out.

Thank you.

-Mark


From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Thompson, Dean
Sent: Thursday, September 24, 2015 6:14 AM
To: 'cti-taxii@lists.oasis-open.org' <cti-taxii@lists.oasis-open.org>
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 3^rd 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 3^rd 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

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




---


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