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] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery


This is a very good point. From an attackers point of view this threat intelligence will be a very juicy target.

 

Things we know:

 

·         Attackers will try and get into a TAXII server if they are aware of it

·         Security through Obscurity is not a security control

·         Automated TAXII to TAXII community will enhance the usefulness of the complete CTI stack

·         Some suggestions made on the CTI-STIX list requires the ability for TAXII servers to automatically discover and communicate with each other (STIX request/response)

 

This really is a question of whether the benefits of the automated discovery outweigh the possibility that someone will see the TAXII server and gain access to it. Given that the TAXII servers will need to talk to other TAXII servers in order to operate (kinda like DNS servers do) we will require some documented communication mechanism to exist between them. If its not a DNS SRV record, then it will be a particular port on a particular hostname in their domain namespace. The attacker will just look for that domain name on that port and will discover the TAXII server anyway. The only caveat to that are TAXII servers with restricted membership and some kind of restricted access group (‘iptables’/firewalling) going on, which I don’t think will be common.

 

The fact is that our TAXII servers will need to access other TAXII servers across the internet in order to communicate. This requires opening up a port in the firewall. This port needs to be accessible to all in order to answer queries from TAXII clients and other TAXII servers.

 

There is an alternative. We could do the equivalent of BGP, and manually do TAXII ‘peering’ agreements between leaf TAXII servers and upstream TAXII servers, where we use upstream TAXII servers as TAXII ‘hubs’, and they then map out the TAXII network topology to determine where to route things. But this gets pretty complex pretty quickly.

 

I believe a better approach would be just to accept the fact the TAXII server WILL be discovered, and to hide it behind a reverse HTTP proxy with proper authentication, ensure the TAXII server is secured, patched and monitored, and maybe even run a split TAXII server (like split DNS) where the ‘publicly’ shared STIX data sits on the externally facing TAXII server and the ‘private’ STIX data sits on the internal server – just like DNS.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

-----Original Message-----
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Trey Darley
Sent: Friday, 30 October 2015 7:41 PM
To: cti-taxii@lists.oasis-open.org
Subject: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery

 

Hi, y'all -

 

While from an architectural perspective using DNS SRV records to support discovery in TAXII 2.0 is an elegant and obvious approach (cf.

[0]), when viewed from the perspective of operational security things appear rather problematic. At the same time you're making it easy for the blue team to discover your TAXII gateway, you're simultaneously advertising it to the whole internet, including potential attackers.

 

 

Using DNS SRV records *internally* within an organization makes sense but for public-facing discovery we should come up with an alternative that's less advantageous to the blackhats.

 

[0]: https://taxiiproject.github.io/taxii2/rest-api/#dns-srv

 

--

Cheers,

Trey

--

Trey Darley

Senior Security Engineer

4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra | An FS-ISAC & DTCC Company www.soltra.com

--

"No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker." --RFC 1925



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