Stop me if you’ve heard this joke before.
Knock Knock
Who’s there?
You just got pwned for answering
As a joke, it’s terrible. (Is it, though? 😁) But in reality, this is a pretty accurate reflection of the state of the zero day world we live in today. Allow me to explain.
As you may have heard, zero days are popping up at an unprecedented rate. Google says that it’s catching more of them than ever. While that may be a function of more diligently searching for them, it doesn’t make zero days any less dangerous. After all, the more of our devices we connect to the internet, the more we should expect to find.
Governments and unscrupulous entrepreneurs around the world have even unwittingly created a thriving black market for zero day vulnerabilities, with some fetching into the millions of dollars given the right buyer. It turns out that zero days are enabled by a fundamental underpinning of the internet today, but this bug can be disabled if we simply let go of legacy notions of trust (and our outsized notions of good manners when it comes to fielding packet requests).
A recipe for zero day disaster
Here’s why zero days are such a large (and effective) nuisance:
When you connect to an application via the TCP/IP protocol – the lingua franca of the internet – it sends an SYN packet. This is the first knock on the door. The application acknowledges the knock by sending SYN/ACK – in effect, a knock back to the user. Once the user hears this return knock, the application flow begins. This is how TCP connections are set up.
So, what’s wrong with this picture? The knocks – TCP SYN packets – carry no authentication or authorization information. Instead, every application must answer any connection request. Now, if you’ve heard of SYN flood DDoS attacks, you know that a constant knocking on the doorstep of an application is capable of bringing it down entirely.
The way TCP connections are set up establishes why zero day vulnerabilities are often so devastating. Because applications and web servers are required to answer every connection without knowing if the incoming request is authorized or not. What follows could be a purposefully malformed request that causes the application or the operating system to be vulnerable. And, crucially, it can come from anywhere or anyone.
You might ask, “isn't that what firewalls are for?” But no, that’s not the case. Firewalls have the same problem that the web/app servers have. They’re incapable of discerning if the incoming connection is authorized or not. Sure, you can create an access control list (ACL) to prevent certain IPs, but how would one do that for an internal application in a large enterprise?
Don’t trust the knock on the door
So, short of rewriting TCP/IP from the ground up (a quixotic task given the install base), is there a solution? There is, and it’s called zero trust. When adhered to correctly, this method works with the identity provider (IdP) of your choice to make sure that you are an authorized user of the application.
Every kiss may begin with a “K” but every application starts with an IdP. We’ve solved the authorized user problem, but how do we protect the server from having to answer every knock on the door? Simple. Eliminate the door. If there is no door to knock on, the problem is resolved. I know what you’re thinking, “if there’s no door, how do you connect to the app?”
Zscaler eliminates this issue by creating a connection from the data center to the Zero Trust Exchange – Zscaler’s purpose-built cloud for handling this traffic. By creating the connection in this manner, no listener (door) is required at the application server. No inbound connections are required, alleviating the problem of “answer all connection requests.” This sounds simple enough, but there is a key ingredient that will guarantee success or failure.
A hyper-cloud is required to ensure transactions don’t suffer delays that can cripple performance and user experience. As we often say, a security solution that comes at the expense of the user’s experience is no solution at all, since it’s soon to be disabled anyway. Don’t believe me? Google “how to turn off my VPN” and treat yourself to a few of the hundreds of available how-to articles on the topic.
Zscaler’s Zero Trust Exchange sees up to four million transactions (NOT packets!) per second. On an average day, that equates to over 220 billion transactions. As a frame of reference, Google handles five to nine billion searches per day. Zscaler handles 20 times that on any given day. Don’t trust me (pun intended). Have a look at Zscaler Trust for a real-time status on Zero Trust Exchange transactions.
Ultimately, the Zero Trust Exchange makes your applications unreachable to non-authorized users. And as we think about the inevitable next zero day attack, remember that if you’re not reachable, you’re not breachable.
What to read next