Precryption: The Zero Trust Prescription for Decryption

Editor’s note: This is part three of a four-part series. For part one, see “Be Sure to Whack Your Cybersecurity Blind Spots,” for part two, see “Avoid Dead Reckoning: Why Zero Trust Requires Network Visibility”, and for part four, see Harness East-West Visibility for Defensive Security.” This series is also available as an ebook.

By now, we’re all waking up to the reality that ransomware and other malicious cyberattacks aren’t going away anytime soon. Threat actors are cashing in on a lucrative environment for exploits with few negative consequences.

Companies are moving critical business applications — once contained in on-premises walled gardens — into increasingly service-oriented and cloud-based hybrid IT environments. This is only natural as development teams want to be more agile in delivering software, scaling their environments, and expanding network topologies to meet changing business requirements and customer needs.

Unfortunately, this new norm of a distributed expanse of nodes and connections has opened up new network threat vectors, and the hacker world has devised new attacks and payloads that seem invisible to detection until they cause damage, even with Zero Trust security policies in place.

How can we realize the benefits of encryption, while getting ahead of the risk it can become in the hands of attackers?   

Chasing Encryption in the Cloud

There are a few natural advantages of a modern cloud stack for cyber defense.

Major hyperscalers maintain perimeter security for North-South traffic coming into cloud instances and firewalls against incoming DDoS attacks — though AWS makes it clear in their shared responsibility model that “while AWS manages security of the cloud, you are responsible for security in the cloud.”

Further, the elastic property of cloud infrastructure allows developers to call for microservices workloads that are launched into ephemeral clusters and containers that are released when no longer needed, often before attackers can detect them.

Still, having so many moving, changing systems and services loosely tied together within a hybrid IT application environment also exposes a complex and broad network threat surface with many potential handholds for attackers.

To obfuscate sensitive data from attacks, especially for East-West traffic that moves laterally within the organization’s extended network, messages are routed through readily available open-source encryption libraries like OpenSSL, making it much harder for an outsider to break into a secured channel and decrypt that data into any useful or recognizable form.

Strong encryption was a game changer for cyber defense. At the same time, cyber attackers also have ready access to modern encryption tools to cloak their actions. By encrypting their own traffic and lateral movement through the network, they can often lurk undetected by threat hunters with security tools.

In fact, 31 percent of data breaches went undetected by security and observability tools, some of which may be attributed to this blind spot for encrypted traffic, according to a recent study by Gigamon.

Why Decryption Won’t Mitigate Risk

Encryption has come a long way since good old PGP in our mail clients.

Perfect Forward Secrecy (PFS) is a feature within TLS 1.3 that makes it impossible to use out-of-band decryption. Even if the current session key is compromised, it cannot be used to reveal secrets within older sessions and past transactions.

Since each session creates a new key, hackers can’t sniff the wire to collect keys — and even if they did somehow manage to decrypt one ephemeral key with supercomputing power, that key would be rendered useless for other sessions. PFS stymies the old man-in-the-middle (MITM) attack style that was popular a decade or more ago.

However, PFS also provides a private environment for bad actors to hide their movements within a network once they have stolen credentials. Longer-running attacks such as malware can be later reactivated, and remote commands effectively concealed from threat detection within that secure encrypted channel.

So, would decryption help? Well, the odds of winning the lottery are better than a human or computer simply guessing a strong cipher, even if millions of tries are allowed.

This leaves operators trying to break into the encrypted channel of their own nodes and the network to collect and decrypt messages that look like keys and payloads that attackers might be using, which is an arduous task with mixed results for determining if encrypted traffic is benign or malicious.

Besides the relative difficulty and consumption of valuable compute resources of this form of monitoring, breaking and inspecting active messages would likely interfere with the performance and availability of local and network resources.

Traditional forms of threat hunting use inline proxies for decryption, which might be useful for North-South traffic coming into your data center or network from the internet, but they are unacceptably intrusive for East-West traffic.

Setting up a proxy that slows down customer traffic to avoid an unknown risk? That’s not a compromise for which the business can settle.

Precryption Starts Earlier

There’s a new approach that can stop encryption from helping attackers hide their own actions. What if you could know exactly what encrypted traffic is suspicious, before it is encrypted?

Gigamon has done exactly this with a new breakthrough technology called Precryption™.

Precryption provides a much simpler way to front-run any kind of encryption and eliminate blind spots by seeing concealed threat activity and anomalous data in the cloud, VMs, and containers, before it hits an encryption library and moves on to the network.

Gigamon Precryption technology operates through the new GigaVUE^® Universal Cloud Tap (UCT), which utilizes plaintext to transform, analyze, and route encrypted cloud traffic for deep network observability and SecOps threat hunting, with message and packet visibility down to the Linux kernel level.

The rightful admin of a given Linux system or container image can use Gigamon Precryption technology to get a plaintext view of cloud traffic before it’s encrypted, using eBPF networking privileges within the Linux system to understand communications between applications and the network tap.

In a multi-node scenario, Precryption technology can also be applied after decryption. Messages and responses coming back out of the network into the local system’s decryption library channel can also be viewed and analyzed for threats without interference.

The Intellyx Take

Before Precryption came on the scene, there were many other ways to intercept and prevent dangerous messages. These options mostly centered on preventing outside intrusion and then getting into the middle of a transaction to find whatever suspicious activity made it through via decryption.

Standard decryption methods were never designed to meet the needs of distributed application environments, where network traffic involves application components and microservices sharing secrets with each other, rather than responding to external requests.

Visibility into encrypted traffic is a foundational building block of true Zero Trust practices. It would be safer to assume our perimeter security is already compromised and act accordingly. Once an intruder has gained access to some part of your network, they can use encryption to their advantage.

It’s time to turn over a new leaf on encryption and decryption with Gigamon Precryption technology.

©2023 Intellyx LLC. Intellyx retains editorial control over this content. At the time of writing, Gigamon is an Intellyx customer. No AI chatbots were used to write this article.