Introducing the new VMware Zero Trust blog series
This is the first in a series of blogs meant to demystify Zero Trust based on interactions with our customers, industries, and standards. With mounting hype behind zero trust, our customers come to us to fill in previously checked-off security boxes with new Zero Trust check marks. All the while we often hear questions like, is Zero Trust all just marketing? Is it a solution? An architecture? Is it something else altogether?
This first blog will set the stage and explain the trending need for Zero Trust, followed by subsequent posts diving deeper into the specifics.
How We Got Here
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” – Josh Billings.
The cybersecurity industry has a troubling dilemma. One that is filled with strict requirements that govern how security should be applied based on many factors, such as the sensitivity of the data being used/serviced/stored. Standardizing these guardrails into compliance standards and regulations helped formalize security controls and spawned massive industries. Meanwhile, cybersecurity professionals struggle with the balance of implementing the standards to avoid liability, along with a never-ending list of new defense-in-depth tools to add. Let’s face it: security fails, and cybersecurity professionals face the delicate balance of chasing bad vs. implementing proactive tooling to limit the attack surface.
Basing security on “just not being the easy target” focuses on measuring security efficacy on the wrong target (or goal). Perhaps that is why cybersecurity analysts are lobbying for a change. Maybe the new threats from the changing geopolitical landscape have shined a necessary spotlight, or we knew this all along, as even the President mandates a change. The executive order is not just what is in the federal controls but is highly recommended within the private sector as well. Further, the SEC is stepping in with new proposed rule changes that draw parallels to what led to the Sarbanes-Oxley Act. Looking back to the history of SOX, it came at a time when the check-box standards that govern financials were no longer enough and made the CEO/CFO directly responsible for the financial reports. Maybe this may start to infer that someday the CEO/Board/etc. need to be held personally accountable for unacceptable cybersecurity risks. The recent call by the SEC falls short of this effort, but maybe there will be more to come. The question is, are we ready?
Reasons for Why We Are Here
When implementing security controls or mitigations, whether with new policies and tooling or detection and response, there is a point where some risks are just accepted. Today this is usually the result of having checked all the boxes that limit the liability on a compliance level and the ones trying to avoid “being the easy target.” This usually comes in the form of frantically patching or implementing controls for whatever the latest news story was. With the time that is left over, security engineering teams then take over and examine a new set of solutions to fill in other perceived gaps in security strategy.
We envision a presented solution by associating that solution with something familiar to us. In many ways, it’s the best way to remember and learn. But in doing so, we may inadvertently shield ourselves from fully understanding the presented solution. For instance, a common task of implementing point products to solve a tactical security need. Often times the point product gets through the (point of contact) POC, pilots and starts to get rolled into production fine, as it does in fact solve that tactical security need, only to discover the solution lacks any correlation with multiple security domains, by definition of “point product.” To really understand the efficacy and see the full benefit, it will require aggregating the logs of all other point solutions utilizing multiple heterogenous management planes, and still not provide the proper perspective of risk and security posture. Further, we may not learn what is lacking till we are too far down the road. In today’s world of ever-increasing means of attacking a network, security teams face a daunting checklist to cover all the bases when tasked with securing various use cases.
Security solutions often conceal the reality of their ability to map to requested use case needs appropriately. What often looks like a fulfilling solution leaves many black holes. No solution is likely to fulfill all needs. To stop the proliferation of multiple security tools and endlessly add one tool to fill the void of another, we first need clarity on what a solution provides and how it provides it in context with the rest of the security ecosystem. Doing so will prevent unchecking a previously checked box due to an insufficiently provided solution.
The Cybersecurity Trends Driving the Need for Zero Trust
The need for change and more holistic strategies is clear, even mandated by the government and recommended by industry bodies. But, how to get there is a windy road full of potholes, dead ends, and hazards. We can all agree that there are no easy buttons or silver bullets, but there are promising trends that we’ll explore in the post that follows. Instead of point products, analysts focus on pushing industry trends into consumable solutions, like SASE/SSE and XDR.
Zero Trust architectures have made their way to Presidential directives and cross-industry working groups. The hazards and dead ends along the road become the same check-box-like strategy used to the detriment of SOC implementations. Sure, we’ll hit some potholes along the way, but if we learned anything from Josh Billings, the journey becomes the destination if you know for sure there ain’t no sure.
Summary and beginnings of the journey
Before we wrap up this introduction, I wanted to point out that VMware is working with the industry on a more holistic end-to-end approach:
VMware is working with the National Institute of Standards and Technology’s (NIST’s) National Cybersecurity Center of Excellence (NCCoE) on the Implementing a Zero Trust Architecture Project to develop practical, interoperable approaches to designing and building zero trust architectures that align with the tenets and principles documented in NIST SP 800-207, Zero Trust Architecture. The proposed example solution(s) will integrate commercial and open source products together that leverage cybersecurity standards and recommended practices to showcase the robust security features of a zero trust architecture applied to several common enterprise IT use cases. NIST does not evaluate commercial products under this consortium and does not endorse any product or service used. Additional information on this consortium can be found at https://www.nccoe.nist.gov/zerotrust.
