Sorry, can't pass this one up:
In my experience of directly observing APT and increasingly dangerous asymmetric warfare cyber-adversaries: Anyone who stands up a public facing TAXII Gateway which globally exposes any level of sensitive intelligence longer than what is minimally required
to securely transit any such externally facing/exposed gateway, deserves the same societal condemnation as those who are similarly exposing critical infrastructure Industrial Control Systems, Power Grid, Chemical Plants, Refineries, Water Treatment, Communications
Infrastructure, PII Data, etc. Have we learned nothing?
There is nothing wrong (in my view) with providing the means to find resources globally, provided said resources have the hardened security infrastructure commensurate with the level of sensitivity of the information and services they provide. Also, to
the points made by others, for the reasons alluded to above, there will be environments where there are physical air-gaps between participants. The CTI standards need to be agnostic in this regard and not presume TAXII Gateways will serve universally as transport
for STIX Packages.
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Office: (856)983-0001
Cell: (609)841-5104
From: <
> on behalf of Bret Jordan <
>
Date: Friday, October 30, 2015 at 5:28 PM
To: Terry MacDonald <
>
Cc: Trey Darley < >, " " <
>
Subject: Re: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
Terry it is great to re-bring these things up, as we have discussed on the Slack channel. Everyone needs to keep in mind that the DNS SRV record is called out in the spec to allow intra-org device a way to discover the internal TAXII server. Every thing else
is an implementation / deployment issue.
We have public facing servers today, DNS and HTTP are the most common. At some point, some organizations will have public facing TAXII servers. So therefore the TAXII servers need to be hardened with good coding standards and have controls put
around them.
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 Oct 30, 2015, at 14:02, Terry MacDonald <
> wrote:
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
