Cybersecurity presentations are known for having pithy titles (usually, the more provocative, the better). And nobody will lose any points for dunking on a concept or term with as much saturation — and overuse in marketing — as Zero Trust. On that score, AmberWolf’s talk at DEF CON 33, titled “Zero Trust, Total Bust: Breaking Into Thousands Of Cloud-Based VPNs With One Bug,” ticks all the boxes. But what about the substance of the critique? Did the research uncover fundamental flaws in Zero Trust? Although we think the research uncovered some significant issues, calling it a “total bust” is definitely overblown.
AmberWolf Identified Significant Flaws In Multiple Products
Over the course of seven months, AmberWolf researchers examined Zero Trust network access (ZTNA) products from security vendors Check Point, Netskope, and Zscaler, finding multiple security issues — more specifically, identity and access management (IAM) problems: user impersonation, authentication bypass, local privilege escalation, and access to an SFTP server containing client logs and authentication material. In short, they found the same sorts of vulnerabilities that routinely appear in other software.
The issue with security flaws in Zero Trust platforms themselves is that these platforms serve as foundational infrastructure and guardians responsible for access policy (authentication and authorization) enforcement to a wide variety and large number of enterprise resources instead of just one. These issues also highlight lingering implicit trust. We’ve made great strides in verifying users and endpoints, but we still rely on other systems to 1) implement and enforce policies reliably and 2) be trustworthy by virtue of being (mostly) free of critical, exploitable defects. The AmberWolf research demonstrates a breakdown in both.
Zero Trust Isn’t A Product
It bears repeating that Zero Trust isn’t a single thing (and it’s most definitely not a product). Zero Trust is a combination of things such as strong authentication (of users, devices, and apps/workloads), enforcement of least privilege, segmentation, data classification, and more.
Each of the Zero Trust domains is intended to work on its own and in concert with the others to ensure that a failure in one control doesn’t result in a catastrophic breach. The metaphorical purpose of the architecture, in other words, is to prevent fire or — barring that — contain its spread and limit the resulting damage. Depending on any one element to achieve that goal is a textbook example of a single point of failure and antithetical to the philosophy and goals of Zero Trust.
Product Security Problems Don’t Invalidate Architecture
The ZTNA products that AmberWolf examined are unfortunately not the first security products to have security flaws. It’s quite a leap, however, to say that flaws in security products mean that an underlying security architecture principle is flawed.
If building materials like cement and steel are defective, we don’t say that the design principles behind building a skyscraper are junk. Instead, we look at the root cause of the flaws in those materials and figure out how to avoid them in the future. If it’s a pervasive issue, it may mean a new approach to making and testing those materials; if it’s a couple of suppliers cutting corners, it may mean purchasing materials somewhere else next time.
One important way for vendors to ensure the security of their products is using and consistently upgrading robust, well-tested, standards-based packages such as OpenSSL, OpenSSH, OpenAM, and more. An important corollary to “don’t roll your own crypto” should be “don’t roll your own IAM libraries” to avoid precisely the issues identified by AmberWolf’s testing.
Like any software or hardware vendor, security vendors must incorporate product security principles throughout the product lifecycle to protect their customers and their brand. This starts early in the lifecycle, where security must identify strategic risks and potential threats, and continues with activities such as threat modeling, security training, pre-release application security testing, and post-deployment protections.
Critically, product security teams must also help product teams build in security and IAM features (like authentication), recommend secure default configurations, and make deployment and configuration guidance available to systems integrators that work with their customers. Through it all, close coordination with the product team is key.
It’s not unreasonable to hold security vendors to a higher standard when it comes to product security. CISA launched the Secure by Design pledge, with hundreds of enterprise software companies signing on and committing to building security into their products. If a vendor that you work with (security or otherwise) hasn’t signed the pledge, ask why not. If they have, ask them to share their progress against the goals.
Is Cloud Delivery Better, Worse, Or Just … Different?
A large and growing number of security capabilities are delivered at least partially via the cloud. That could be seen as a liability in this context. Despite the attention-grabbing claim about breaking into thousands of VPNs using a single bug, AmberWolf did no such thing — although its research clearly shows that an attack on that scale would have been possible. We say “would have been” because, although cloud delivery can sometimes result in new attack vectors, the cloud also offers benefits in terms of vulnerability remediation.
Zscaler responded to and fixed the vulnerability reported by AmberWolf the same day (although there was a brief regression several days later that was also quickly repaired). As with any case of security issues in security products, responsiveness and transparency matter. Contrast this with severe, exploited vulnerabilities in on-premises infrastructure that required federal law enforcement intervention or guidance that involved literally unplugging affected systems to remediate security issues — not to mention coordinated action on the part of hundreds or thousands of organizations, as opposed to just one.
Connect With Us
As always, Forrester clients can connect with Sandy for product security, Andras for identity, and me for Zero Trust by setting up a guidance session or inquiry.
We’ll also be in Austin, Texas, on November 5–7 with a host of our colleagues for the Forrester Security & Risk Summit. This year’s theme is “Master Risk, Conquer Chaos,” and the agenda includes a track focused on Zero Trust as well as a variety of keynotes, breakouts, workshops, roundtables, and special programs to help you master whatever chaos your teams are facing today. We hope to see you there!
