Word is slowly coming through industry channels that the attackers in the Heartland breach exfiltrated sniffed data via an outbound network connection. While not surprising, I did hear that the connection wasn’t encrypted- the bad guys sent the data out in cleartext (I’ll leave it to the person who passed this on to identify themselves if they want). Rumor from 2 independent sources is the bad guys are an organized group out of St. Petersburg (yes, Russia, as cliche as that is).
This is similar to a whole host of breaches- including (probably) TJX. While I’m not so naive as to think you can stop all malicious outbound connections, I do think there’s a lot we can do to make life harder on the bad guys. 
First, you need to lock down your outbound connections using a combination of current and next-generation firewalls. You should isolate out your transaction network to enforce tighter controls on it than on the rest of your business network. Traditional firewalls can lock down most outbound port/protocols, but struggle with nested/stealth channels or all the stuff shoveled over port 80. Next-gen firewalls and web gateways (I hate the name, but don’t have a better one) like Palo Alto Networks or Mi5 Networks can help. Regular web gateways (Websense and McAfee/Secure Computing) are also good, but vary more on their outbound control capabilities and tend to be more focused on malware prevention (not counting their DLP products, which we’ll talk about in a second).
The web gateway and next gen firewalls will focus on your overall network, while you can lock of the transaction side with tighter traditional firewall rules and segmenting that thing off.
Next, use DLP to sniff for outbound cardholder data. The bad guys don’t seem to be encrypting, and DLP will alert on that in a heartbeat (and maybe block it, depending on the channel). You’ll want to proxy with your web gateway to sniff SSL (and only some web gateways can do this) and set the DLP to alert on unauthorized encryption usage. That might be a real pain in the ass, if you have a lot of unmanaged encryption outside of SSL. Also, to do the outbound SSL proxy you need to roll out a gateway certificate to all your endpoints and suppress browser alerts via group policies.
I also recommend DLP content discovery to reduce where you have unencrypted stored data (yes, you do have it, even if you think you don’t).
As you’ve probably figured out by now, if you are starting from scratch some of this will be very difficult to implement on an existing network, especially one that hasn’t been managed tightly. Thus I suggest you focus on any of your processing/transaction paths and start walling those off first. In the long run, that will reduce both your risks and your compliance and audit costs.
Reader interactions
5 Replies to “Recent Data Breaches- How To Limit Malicious Outbound Connections”
[…] card data was sent to Russia over clear text connections. Rothman post references a nice post from Richard Mogull on the […]
[…] Rich: Recent Breaches- How To Limit Malicious Outbound Connections. There are a couple of great comments with additional information, including one from Big Bad Mike Rothman, who is not dead yet. […]
Nice one-
And Hoff (on a phone call today) also recommended using DNS to restrict outbound connections
You can also pinpoint anomalous outbound connections via Netflow traffic analysis. It’s not going to block them, but at least an organization would know there was something funky going on. As always, you want as many opportunities to pinpoint that something is wrong as possible.
Rich, you said:
You glossed over this a bit, but it’s worth a reminder (especially for people who might be exploring SSL proxying for the first time) that if you just blindly accept all certs on client and proxy, you’‘ve just thrown away the benefit of SSL trust, and reduced left clients wide open to man-in-the-middle attacks. I don’‘t know how flexible the proxies are on their certificate handling, but I did work at a site where every SSL transaction popped up a warning about the wrong cert coming from the server, and we discovered it was a (mercifully brief) test of SSL proxying. They had no way to make our Mac, trust the proxy’s internal cert, and we had no way of knowing what kind of certs it was accepting on our behalf on the other side of the proxy.
Proxying SSL requires some careful consideration & configuration about how the web proxy will handle self-signed or otherwise untrusted certificates, to avoid exposing users to fraudulent sites.