Date: Monday, November 2, 2015 at 4:12 PM
To: Terry MacDonald <terry@soltra.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Patrick Maroney <Pmaroney@Specere.org>
Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, Trey Darley <trey@soltra.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
Date: Monday, November 2, 2015 at 2:46 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Patrick Maroney <Pmaroney@Specere.org>
Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, Trey Darley <trey@soltra.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: RE: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
There were some people working at FIRST on a TLP replacement (or extension?) call the Information Exchange Policy Framework (IEPF) based on TLP but
expanded to give more ‘control’ to producers. It covered:
‧
Sharing
‧
Handling
‧
Actions
‧
Commercial Use
When I last saw it, it seemed very useful, and in my opinion exactly what we need as a replacement. As such I’m contacting the author to find out
what state it is in, as it’s been a while. If it’s still a thing, then I’ll see if I’m permitted to post some examples to this and the STIX list.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From:cti-taxii@lists.oasis-open.org
[mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Jason Keirstead
Sent: Tuesday, 3 November 2015 3:45 AM
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>; Terry MacDonald <terry@soltra.com>; Trey Darley <trey@soltra.com>;
cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
However, the problem with the current marking mechanisms is just as you allude to.. "Those who do not honor the data marking/handling conventions...". Relying on "convention" for implementation of a specification is
a dangerous course to be on, and it is my biggest gripe against the current TLP data marking. In my opinion, TLP is so ill-defined as to the implications of each level (what defines "organization"?), that it is near useless. The only way TLP can ever make
sense is "by convention" within a small group of actors who can all agree on something. This isn't how to formulate a global standard that needs to work among a diverse set of actors. That's why I strongly advocate for a better more robust mechanism for marking
in STIX 2.0 and to throw away the ever-confusing TLP.
-
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
Patrick
Maroney ---2015/10/31 02:46:56 AM---Re: "I guess this is one of my pet peeves with data making / data handling. Most of the groups that
From: Patrick Maroney <Pmaroney@Specere.org>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: Terry MacDonald <terry@soltra.com>, Trey Darley <trey@soltra.com>, "cti-taxii@lists.oasis-open.org"
<cti-taxii@lists.oasis-open.org>
Date: 2015/10/31 02:46 AM
Subject: Re: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
Sent by: <cti-taxii@lists.oasis-open.org>
Re: "I guess this is one of my pet peeves with data making / data handling. Most of the groups that really need this are not going to share with people outside of their group"
Actually it's just the opposite, the more advanced groups are much more likely to share high value actionable intelligence (at least tactical) once we have solid data marking/handling constructs. We know the value of early detection/prevention
and criticality of broadly sharing ephemeral IOCs ASAP.
Those who do not honor the data marking/handling conventions in any trust based community will eventually be exposed and isolated from same.
Patrick Maroney
_____________________________
From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Friday, October 30, 2015 6:34 PM
Subject: Re: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
To: Patrick Maroney <pmaroney@specere.org>
Cc: Terry MacDonald <terry@soltra.com>, Trey Darley <trey@soltra.com>,
<cti-taxii@lists.oasis-open.org>
You hit on a very key point that I have brought up many times before.... Not everyone is going to share nor can everyone share openly. Thanks for re-illustrating that point. We are going to have pockets of CTI within niche eco-systems and various trust groups
or groups of interest that share some amount of CTI within their groups. Public and open sharing will be for very low hanging fruit that people often refer to as background noise. The more juicy and cutting edge CTI will be highly restricted and available
only under certain out-of-band subscription agreements.
To this end, we need TAXII to be able to work really well within these close networks and niche eco-systems. We also need TAXII to work with ad-hoc groups of interest that need to share some latest greatest threats in a seemingly
structured way.
I guess this is one of my pet peeves with data making / data handling. Most of the groups that really need this are not going to share with people outside of their group. Further, it will be impossible to guarantee that an end
STIX/TAXII system will honor the data-markings. Also, a lot of the data-markings I am hearing about are so complicated that a human need to read them understand them anyway, it is not like arbitrary software is going to know how to handle them.
The things I want to focus on in TAXII are:
1) How do we make intra-org sharing of CTI amazingly simple and easy to use
2) How do we enable org-to-org sharing of CTI in a secure manner for those orgs that are open to sharing in the first place
3) How do we enable ad-hoc groups to setup a TAXII sharing community on the fly to share information about some new threat they are looking in to.
4) How do we build a relatively secure system so people can selectively share CTI with people.
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 15:59, Patrick Maroney <
Pmaroney@Specere.org> wrote:
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:
< cti-taxii@lists.oasis-open.org>
on behalf of Bret Jordan < bret.jordan@bluecoat.com>
Date: Friday, October 30, 2015 at 5:28 PM
To: Terry MacDonald < terry@soltra.com>
Cc: Trey Darley < trey@soltra.com>, "
cti-taxii@lists.oasis-open.org" <
cti-taxii@lists.oasis-open.org>
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 <
terry@soltra.com> 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 |
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
...
. . .