Cloud Security Automation: The Fastest Path to Zero Trust
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. In the wake of the SolarWinds Orion breach and the Colonial Pipeline ransomware attack, the Biden Administration issued a new Cybersecurity Executive Order (EO) that included specific guidance for government agencies to adopt Zero Trust architectures and technologies.
This EO is, in many ways, a watershed moment for the security of government data, systems, and cloud environments. The inclusion of Zero Trust Architectures in the context of IaaS, PaaS, and SaaS offerings will not only impact federal and defense agencies, but also the greater commercial market and supply chain.
But for those of us who’ve seen these kind of government-driven cybersecurity initiatives in the past, mandating Zero Trust Architectures and security is just a first step. The next step is for agencies and private companies to adopt and deploy zero trust principles – something that’s easier said than done, especially in complex cloud environments. 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.
Zero Trust vs. 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 now the Biden Administration’s EO on Cybersecurity are all mandating Zero Trust Architectures.
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/why should users and systems really be connecting to or how we should be controlling access to minimize risk and data breaches.
Zero trust security and architectures are designed to addresses these questions, building security upon a default foundation that 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 (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/controlled to a strict “need to know” basis for access.
Why Zero Trust is Easier Said Than Done
As an approach and architectural concept, zero trust is relatively simple. However, as a practical, best practice to architect and deploy, zero trust is 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 2020 Data Breach Investigations Report, only hacking ranked higher than cloud misconfiguration errors as a source of data breaches.
In contrast, if a zero trust architecture and approach was 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 “by Default and by Design” with Cloud Security Automation
What if you could easily deploy and enforce zero trust by default and by design in the cloud through security and compliance automation and standardization? As we’ve seen over the past couple years, perhaps one of the greatest threats to any cloud environment is rapid and uncontrolled change. And when that change is combined with complexity, the need for speed, and human error, the threat compounds. When a cloud application security environment is built manually – with a patchwork of disparate, yet complex technologies and tools – it’s harder to deploy and maintain a comprehensive zero trust architecture. This is even more true when security comes in too late in the DevOps lifecycle – creating opportunities for developers to cast zero trust principles to the side when something gets broken and becomes an inhibitor to time-to-production.
But, if a cloud environment is pre-built, pre-configured, and standardized using automation – with a cloud-native platform that deploys quickly (directly in your own AWS or Azure account) and enforces zero trust by design and default – 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 from day 1. 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 or 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).
How Anitian’s Cloud Security and Compliance Automation delivers on the Presidential EO
The path to zero trust, as outlined in the Cybersecurity EO, is lined with cloud automation. The Biden Administration’s Executive Order on Improving the Nation’s Cybersecurity may call for the adoption of a Zero Trust Architecture, but actually achieving it – in the most accelerated, secure, and cost-effective way – comes from adopting and leveraging automated, standardized, and pre-engineered cloud-native platforms and technologies.
To show you exactly where cloud application security and compliance automation delivers on major sections of the Presidential EO, Anitian has mapped them for you in an intuitive infographic.
About the Author
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 Sr. Director of Product Marketing for McAfee’s Network Security Business Unit. John also serves as an Advisor at Signal Peak Ventures. As CMO, John oversees global marketing, branding, communications, press & analysts, and go-to-market strategy & execution.
John Vecchi can be reached online at john.vecchi@Anitian.com and at our company website www.Anitian.com.
