By John Vecchi, CMO, Anitian
Zero trust security has made its way into the offerings of most enterprise security companies while becoming a critical and new modern architecture adopted by the Department of Defense (DoD) and the federal government. However, many organizations today have built their information security programs around more traditional security technologies and methodologies. Moving to — and modernizing for — zero trust security is not as simple as adopting a single point technology or running a single scan. Here’s why.
Comparing Zero Trust to Traditional Approaches
If we contrast a modern, zero trust approach to traditional, legacy security approaches, it’s understandable why the National Security Agency (NSA), Department of Defense (DoD), Defense Industrial Base (DIB), and the Biden Administration’s Executive Order on Cybersecurity are all mandating Zero Trust Architectures (ZTA).
Yesterday’s legacy security strategy was built around a more traditional “internal trust” approach. The idea is that once inside the trusted zone, applications and systems can freely communicate. Access to the internal trusted zone is granted by passing users through a principal perimeter defense – in most cases a next-generation firewall. This makes it easier for attackers, as once they’ve stolen legitimate credentials or found other methods to bypass the perimeter defense, they can gain full access to the trusted zone where they can move laterally into the network. In these traditional security environments, the network perimeter is the primary mechanism for enforcing access. Its focus on maximum interoperability means that the default posture is to connect to everything, without asking what or why users and systems really should be connecting to or how we should be controlling access to minimize risk and data breaches.
Zero trust security and architecture is designed to address these questions, building security on a default foundation where no user or system should be allowed access to a resource until a certain level of trust has been established. In a zero trust environment, every connection and all access are explicitly defined, authorized, and constrained with each connection attempt. When a service (such as a system, application, container, etc.) needs to connect with another service, that connection must use a valid authentication method, pass some level of authorization, and be constrained and/or controlled to a strict “need to know” basis for access. Hence, a default posture of “zero trust” until you prove to be trusted. But even then, it’s only for that specific instance.
Zero Trust in the Real World
As an approach and architectural concept, zero trust is relatively simple. But as a practical, best practice to architect and deploy, zero trust can be difficult. This is mostly because today’s existing, legacy security environments are not designed, built, and deployed around zero trust principles.
Especially in today’s DevOps-driven cloud environments, development teams often build application and service environments in “full trust” mode with little-to-no access restrictions or security controls. Only after the application and cloud environment are built do security and DevOps teams work to implement security controls and access restrictions on the production environment. In essence, the environment begins in a vulnerable state. And, as the complexity of the cloud environment grows, the complexity of the security controls and enforcement grows along with it. If certain controls or configurations are missed or inaccurate, then the environment can be left vulnerable. According to Verizon’s 2022 Data Breach Investigations Report, misconfiguration errors scored as the highest source of data breaches.
In contrast, if a zero trust architecture and approach were deployed and enforced by default, the environment would be inherently secure, with no user or system having access. Not only would the granting of access be a required and overt act, but the number of services also needing access and the scope of the access would be finite and on a need-to-know basis. So, once you grant a system or user the appropriate access — while automating the application of those rights — you’re done. And, since this approach is deployed and enforced automatically and by default, the inherent security of the environment grows more seamlessly and at the same rate as the environment itself (and its complexity).
Achieving Zero Trust through Automation
If a cloud infrastructure environment is pre-built, pre-configured, and standardized using automation — with a cloud-native platform that deploys in a day (directly in your own AWS or Azure account) and is pre-built to NIST 800-53 to enforce zero trust by design and default — then a modern zero trust architecture can be achievable and affordable for any size enterprise or organization. As such, developers can now build their cloud applications within the confines of zero trust principles as soon as they begin, even as early as day one. This means access rights become an integral component of the DevOps process and a critical part of automated configuration management practices. As new applications are added to the environment, developers work more seamlessly with security practitioners and DevSecOps teams to configure access rights, authorization, logging, and other key infrastructure components.
Now, rather than having individual people tinkering with security tool configurations and access rights, developers can code rights into automation scripts, then run those scripts against test environments, evaluate their success, and perfect those scripts over time. Security practitioners and secure DevOps teams can likewise automate the evaluation of access rights, quickly identifying overly permissive rights, compliance drift, and other potential threat vectors. As a result, security and SecOps teams can use automation to quickly revert access, find and fix misconfigurations, and identify indicators of compromise (IOCs).
All this boils down to the fact that a zero trust approach appears to be the right way to improve your cloud security posture and the world is going in that direction. Of course, there are multiple ways to get there. Some paths seem faster and more logical than others. Now it’s up to you to choose.
About the Author
John Vecchi is the Chief Marketing Officer (CMO) of Anitian. As Chief Marketing Officer, John brings more than 24 years of experience in high-tech marketing, strategy, product marketing, product management, sales and consulting. Most recently, John was Chief Marketing Officer at ColorTokens and Anonyome Labs. Previously, he served as senior vice president of product marketing and strategy for Blue Coat Systems, Chief Marketing Officer for Solera Networks (acquired by Blue Coat), Vice President of WW Marketing at Zscaler, Head of Global Product Marketing & Strategy for Check Point Software, as well as executive marketing consultant for Symantec and Sr. Director of Product Marketing for McAfee’s Network Security Business Unit. John still serves as an Advisor at Signal Peak Ventures and has a B.A. from the University of St. Thomas, St. Paul, MN, focusing on international business and foreign language. As CMO, John oversees global marketing, branding, communications, press & analysts, and go-to-market strategy & execution.
John can be reached online on LinkedIn: https://www.linkedin.com/in/johnvecchi or Twitter: https://twitter.com/johnvecchi and at our company website https://www.anitian.com/
