[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-taxii] Question about multiple trust group support
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]
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.
In my humble opinion, having group membership is an important part of how channel and group administrators will control access to channels.
·
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. ·
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
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 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 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
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]