Is Encryption One of Your Biggest Network Security Holes?

If you were to look at your firewall logs right now and performed some type of analysis, you’ll probably see that there’s a large percentage of data leaving your network completely encrypted. Well that’s great you say. Encryption protects communications in transit and allows for secure sessions between you and the destination endpoint. If that’s what you think, you’re 100% percent right and it’s also one of your biggest security holes in your network!  Because today, the bad guys are getting much smarter. They are tapping into your secured communications and routing them back to their own destination. You know why? Because it’s most likely allowed outbound traffic from your network and you can’t see it. And hackers could be using it to a truck through your firewall and you wouldn’t be able to tell. In order to mitigate this risk there are some things you should do to not only alert on this malicious behavior, but stop it in its tracks.

Turn on firewall logging

One of the first things you need to do is turn on your firewall logging as soon as possible and send the logs to a log management solution. While these logs may generate extremely large amounts of data and analysis of it may seem like a daunting task, it’s absolutely crucial data to have. Even if you can only keep the data for a short while – a few weeks or a month – it’s still better than not having it all.

This data will allow you to perform analysis and alert on the source IP address through a threat intelligence or SIEM solution. This isn’t a perfect way to block or alert on traffic, but it will help make you aware of what’s happening on your network. If you notice there’s an outbound SSH or HTTPS connection every night going to Russia from a payroll system, you might want to look into that a little more. You won’t know until you start investigating the endpoints in your network, since the traffic is still encrypted at this point.

Monitor outbound encrypted sessions

Another thing you should do is monitor outbound encrypted sessions. You can do this by grabbing the netflow from all egress points and looking for suspicious connections at random times of the day (think off hours and weekends) that are going to places in the world that you have no business going to. Set up alerts looking for connections or session times that seem to be lasting way longer than normal (many times hackers are going to try and siphon the data out in a steady stream).

Monitor the quantity of data

Lastly, look for encrypted sessions that have pushed way more data than a connection should and possibly even set a limit for encrypted traffic going outbound. As I mentioned, you might see a slow connection lasting a long time, or a session that’s dumping GB’s of data. These should types of activities should trigger alerts for further investigation, since you can’t see the session data…..yet.

Man-in-the-middle inspection

The only real way to catch encrypted traffic performing malicious activity is to perform some type of man-in-the-middle inspection on the egress points. A perfect example of this is enabling HTTPS inspection on your web content firewalls or IPSs. By importing a certificate to the endpoints that has its traffic sent through an IPS/Firewall/Proxy you can run deep packet inspection against 443 destined traffic and review the encrypted sessions for all types of malicious traffic. The IPS/Firewall/Proxy device intercepts the traffic, creates a secure connection to the remote server and itself, as well as between itself and the internal endpoint. At this point it decrypts the traffic from the endpoint and encrypts it against the remote end. While the traffic is decrypted you run your inspection of the packet and determine if there is any malicious behavior occurring, and block if there is, as you normally would. This is the best way to monitor, alert and block maliciously encrypted traffic.

Check for outbound traffic that’s not using a web protocol

One last thing to look for is not only malicious signatures within the HTTPS protocol, but traffic that’s going outbound over 443 that is not using a web protocol. This might not show up in the signatures as malicious, but if you can tie a protocol to a port and a hacker is trying to use command and control communications over the internet that isn’t web traffic you might be able to detect additional attacks.

With this in mind we still need to continue to push for encryption in all our communications, but we must be careful not to leave it as a hole in our networks. Many people see this as a privacy breach, but there should be no expectation of privacy while you’re working in a corporate environment. There are ways to limit HTTPS inspection in most security appliances, such limiting inspection to financial sites so as not to see bank account information, but again, what if it’s what the attackers are hoping to find? There’s a fine line here, but the risk of not looking for malicious encrypted sessions is much greater than the alternative.