While we want encryption because it protects data as it travels across networks, encryption is actually a significant obstacle to strong network security, and we are living in a world of encryption. The most recent Google transparency report shows that 94% of its traffic is now encrypted, while the 2019 Mary Meeker Internet Trends report shows that 87% of global web traffic is now encrypted. This is significant and good for data privacy since it’s now very difficult or near impossible for an outsider to snoop in on our communications.
However, security teams need to see into data-in-flight in order to analyse it and look for potential threats. There is no doubt that encryption improves privacy, but it does so at the risk of making it easy for attackers to hide their activity inside encrypted conversations.
Can’t address what you can’t see
For robust security, you need to be able to analyse full packet data unencrypted. If organisations can’t see exactly what’s going inside their networks, it seriously limits their ability to detect and act upon threats. With access to decrypted packet contents, security teams can detect and investigate a range of important events, such as an executed vulnerability, malicious payload delivery, or data exfiltration. Without decryption, security teams remain blind to critical security threats such as these, rendering threat detection and investigation near impossible.
If traffic can be decrypted on-demand, and in a safe and secure environment with access restricted to only the tools and individuals that need it, organisations are much more secure and able to respond to and investigate threats. But decryption done poorly becomes a security and privacy risk in itself, should the decrypted information get into the wrong hands. Organisations need to decrypt network traffic for robust security, but they need to do it in a way that does not compromise privacy or security of the data itself.
Business blind to threats
Before ephemeral key encryption, SecOps had an advantage if it controlled the network infrastructure. By owning or knowing the static private key held on each server, it was possible to passively tap and decrypt information for security analytics and packet capture. With TLS 1.1 and earlier, encryption is always done using static private keys residing on the server, and with access to the private key, network traffic can be decrypted either in real time or after the fact based on recorded traffic. However, if the private key becomes known by a threat actor, any traffic in the past, present and future can be decrypted.
Achieving a data-centric approach to security requires homomorphic encryption
This has changed completely with ephemeral key cryptography, which is optional in TLS 1.2 and mandatory in TLS 1.3. Now, every conversation between many clients and a server will each use a unique “session key” to encrypt the data for that session. This means that if a private session key is leaked, it only compromises one session, which is great for privacy. However, in making encryption stronger to better protect privacy, it means security teams can no longer passively tap and decrypt traffic to look for possible threats. The only way to decrypt traffic is to do so in real-time.
SecOps teams – and the security tools they use – need to be able to analyse traffic in decrypted form, both to detect possible threats and for forensic analysis such as quantifying a potential breach. This means having a reliable architecture for encrypting and decrypting traffic is key. Teams need to record a decrypted copy of the traffic and have the ability to go back in time to see the full extent of any threats that have been detected.
An architecture to decrypt traffic in real-time
It is possible to decrypt traffic in real-time, but you must have the right architecture in place to enable this. The solution is to deploy a decryption solution (such as a Network Packet Broker with decryption capability) in-line with the traffic flow. These solutions act as man-in-the-middle or TLS proxy devices. Instead of a single TLS session between client and server, two TLS connections are made, one between the client and proxy, and another between the proxy and server. The proxy is responsible for maintaining strong encryption on both connections to protect privacy. Since the proxy also has access to all the decrypted traffic, this traffic can then be sent to analytics tools for real-time analysis and/or to packet capture appliances for recording, and safely storing, unencrypted traffic for post-event forensic analysis.
With this architecture in place, threats can no longer hide within encrypted traffic, and network security tools gain a newfound efficacy with the ability to see the vital clues and indicators of compromise (IoCs) that signal threats or potential breaches. And by recording the decrypted traffic, security analysts have access to the definitive evidence they need to analyse security threats and data breaches quickly, see exactly what happened, and respond appropriately. With strong TLS 1.3 encryption, data privacy is not compromised, ensuring that strong security can be achieved without impacting privacy or data security.
The state of the cyber security market, according to BlackBerry’s CTO
This best practice approach will help you to re-gain visibility and security with fully integrated decryption, traffic analysis, and packet recording. By implementing reliable, tiered network monitoring to decrypt both TLS 1.3 with emphemeral keys and legacy encryption for both active inbound and outbound SSL traffic, you will have always-on full capture of decrypted traffic, giving full visibility of your network to detect all threats and maintain optimal network performance.
[emailsignup]
