I can still hear the dismissive calls of it being “just another security buzz word.”
That was two years ago while advocating the importance of delivering Zero Trust Security tools in an explosive new area of enterprise security. At the time, my team and I were working on the industry’s first Definitive Guide to Zero Trust Security (for a different company) and saw how quickly zero trust was becoming both a critical new security approach and an entirely new security segment and market.
Fast forward to today and 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.
Real-world zero trust spotlight on the AWS cloud
Most AWS native services implement a zero trust approach very similar to the description above. For example, if you look at how Amazon Simple Storage Service (Amazon S3) buckets are accessed, you’ll find that there must be an access right explicitly defined for the S3 resource before anyone or any application can access it. First, the user or application must be authenticated using valid credentials. Next, the connection must use an access key and all connections are made directly to the Amazon S3 API — which will then authorize and validate all connections. Interestingly, the network connection between the requesting service and S3 resource is mostly immaterial. Although a network is used for transport, and there are certain network-level constraints, the network itself is not the designated layer for controlling access. The S3 service and API trusts nothing and no one until an administrator defines the rules of who and what can access a bucket and its contents. So, Amazon’s S3 is really a zero trust service by default and design.
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 were deployed and enforced by default — similar to how Amazon S3 was highlighted in the Spotlight above — 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 E.O.
As you can see in the infographic below, 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, we’ve mapped them for you in an intuitive infographic (perhaps one of the biggest I’ve had to build).
