Sometimes encryption can actually make you less secure

Most information security professionals believe the following is a truism: Encryption makes you more secure. While sometimes your decision to encrypt data or traffic is driven by compliance mandates, it’s still interesting to consider what threats different forms of encryption actually protects you from.

Encrypting data at rest in your data center

This protects you in case of physical removal of hard drives from your data center. If your data center is in a colocation facility, you might not trust the physical security enough and this makes eminent sense.

If the server is in your own data center, you likely have good physical controls in place and the gain in security is nominal, although encryption clearly doesn’t hurt.

Encrypting data at rest in your employee’s laptops

This protects you in case of physical loss of control over the laptop. Given that laptops are taken offsite, left in car trunks and forgotten in cafes, the likelihood of this happening across a 1,000-employee company is quite high. So, the gain in security is substantial.

Encrypting data in flight across the Internet

This protects you by preventing outsiders on the big-bad-internet from seeing the contents of your communications. For this, encryption may be in the form of SSL/TLS or IPsec VPNs.

If you need to see inside this encrypted traffic before it leaves your network, you can put a forward proxy in place for outbound connections. If you need to see inside the encrypted traffic before it reaches your servers, you can utilize a reverse proxy or load balancer on inbound connections.

Since you have no actual control over the network infrastructure carrying your data across the internet, insisting on encryption for this traffic makes sense.

Encrypting application data in flight across your internal network

This protects you against individuals inside your network by preventing them from seeing application traffic (and potentially account passwords) in the clear.

This is particularly true for HTTPS-based applications, which often use clear-text passwords inside a TLS wrapper to authenticate user accounts and were developed with the assumption that the traffic would be encrypted.

The likelihood of this traffic being intercepted in the corporate network is reasonably limited. After all, switches only send unicast traffic on trunk ports or on the port leading to the machine the traffic is intended for. But since network administrators with privileges may have access to trunk ports, encryption still makes sense here.

Encrypting infrastructure protocols in flight across your internal network

By infrastructure protocols, I mean protocols that form the backbone of many enterprises. These include DHCP, DNS, Kerberos, SMB and DCERPC. If you’re a Windows-centric enterprise, the last three of these protocols underpin many of the services on which your Windows clients and servers depend.

It turns out that encrypting these protocols provides little protection against likely attack vectors since they were designed under the assumption that they would be run in the clear. Encrypting these protocols actually removes the ability to detect compromised endpoints by inspecting the traffic they emit.

Given that it is far more likely that an endpoint will become compromised and far less likely that internal traffic will be intercepted and far less value to be derived from seeing these protocols in the clear, encrypting infrastructure protocols in flight turns out to provide a very poor tradeoff.

A case study featuring SMB

In 2012, Microsoft shipped version 3 of its SMB protocol, which provided the option to encrypt SMB traffic. The fact that SMB v3 became available more than five years ago might lead you to believe that all companies are now running SMB v3.

But as the WannaCry ransomware attack in 2017 showed, this is far from the case. WannaCry exploited an SMB v1 vulnerability and proved surprisingly potent in enabling the lateral spread of this worm. Nevertheless, slowly but surely Windows servers and clients have been updated and more enterprises are gradually adopting SMB v3.

The natural question is whether or not to enable the optional encryption v3 supports. When I discuss this question with our customers, their first instinct is to turn on encryption because we’ve been taught to view encryption as a way of reducing the attack surface.

But in an age where we finally understand the limits of a strategy built entirely on attack prevention, turning on encryption for SMB will allow one compromised endpoint to attack neighboring systems with no possibility of network-based oversight that could detect the attack.

With encrypted SMB v3 deployed:

• Ransomware encrypting remote file systems becomes invisible (until someone stumbles across an encrypted file on the file server).
• Lateral movement via psexec or a myriad of other RPC UUIDs becomes invisible.
• Reconnaissance using RPC UUIDs becomes invisible.
• Brute-force password guessing of local accounts on another system becomes invisible.

Needless to say, in an age where advanced analytics to detect a sophisticated attack is often the only chance of heading off substantial harm, encrypting SMB is akin to taking one step forward and 50 steps back.

Consider the attack vector you’re concerned about and realize that while encryption hides data from potential attackers, in some cases it also may severely limit your ability to detect an attacker in your midst.