Just FYI - Re: @Mark's comment on DNS SRV: The following discussion on DNS SRV in the MQTT TC may help inform our discourse:
https://issues.oasis-open.org/browse/MQTT-259
There are many other parallels ...
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email:
On Thu, Sep 24, 2015 at 5:25 AM -0700, "Davidson II, Mark S"
<> wrote:
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: [mailto:]
On Behalf Of Thompson, Dean
Sent: Thursday, September 24, 2015 6:14 AM
To: '' <>
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:
[mailto:]
On Behalf Of Trey Darley
Sent: Thursday, 24 September 2015 6:08 PM
To: Adam Cooper; Jason Keirstead
Cc: Jordan, Bret;
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:
<> on behalf of Adam Cooper <>
Sent: Thursday, September 24, 2015 08:37
To: Jason Keirstead
Cc: Jordan, Bret;
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.
