Zero Trust focuses on business outcomes, stopping successful attacks, reducing compliance scope, blocking data exfiltration, and whilst doing all that, saving money. The methodology proves the means to protect critical assets by designing around them, as opposed to designing by starting at the perimeter and working inwards. It also provides a pathway to implement the least-privilege access model across your infrastructure, whilst enabling pervasive visibility throughout, and reducing the attack surface area.
Software-defined data centres provide an enhanced framework for implementing Zero Trust, through easier insertion of security controls across the network, and the ability to build granular policy based on dynamic workloads. The more hardware-based your data centre is, the more challenging it is to try and retro-fit a Zero Trust approach, given the amount of upheaval that may be required. There could be large-scale design changes, change control pain, political issues, to name a few.
Cloud infrastructure on the other hand can provide the perfect opportunity to implement Zero Trust, by not having the legacy baggage to work around in order to implement. Retrofitting Zero Trust in cloud infrastructure is much simpler too, using blue/green deployment concepts, and utilising the lack of capital investment required in public cloud, to simply turn on and off infrastructure. Turn-up a new stack based on Zero Trust principles, migrate, turn off the old stack; this is all cost efficient in the no-capex world of public cloud in particular, and would be much more costly with hardware-based data centres. Cloud infrastructure also has constructs to aid the design and networking for Zero Trust, because traffic can be steered over a virtual network to anywhere, without the physical constraints of moving traffic through a traditional data centre.
Implementing Zero Trust in cloud still needs the ability to define critical assets, reduce the attack surface area, and provide pervasive visibility. Cloud adoption can increase agility, improve speed to market, and make deployment simpler and more consistent, but only if security does not become an inhibitor. To implement Zero Trust into cloud infrastructure and ensure security is seamless and automated, we need to use an Infrastructure-as-Code methodology. Anyone adopting DevOps culture will have a strong emphasis on automation, feedback loops, and deploying with continuous integration and deployment, and security must work in these ways to avoid being a hindrance. If developers have to think about security, how they deploy and integrate it, how to attach is, then there is already friction and we may see security getting left behind or even bypassed.
Ideally, the most obvious and default path which developers take is the one that is secured by default, by providing templated approaches, APIs to integrate into code, automated policy creation and automated testing. Security should be something that happens through the entire lifecycle of a project or development, a seamless consumable service, not something that happens at the end of a cycle when it is too late and too hard to retrofit. Developers should be able to check early and often that what they are doing is secure, so security should be present as soon as any workload is spun up, and follow the development stack through its lifecycle. That also means we should be deploying security in the same way as the application stack, with the same toolsets, without creating any friction; Zero Touch.
Security in public cloud is a shared responsibility; in an IaaS model for example, the cloud providers have excellent physical and digital security for the infrastructure itself, you have responsibility for securing the operating systems, networking, access control, applications, source code, and the data inside all of those. Infrastructure-as-code is an architecture style that allows us to define traditional network, server, compute resources in source repositories; it provides consistency, controls drift from desired state, maintains changes, and brings repeatable predictable deployment (great for Dev->UAT->Prod, and Region1->Region2).
Security also needs to be consistent across all cloud environments; each cloud provider has their own implementation of security controls, with different formats of configuration and features; a common security capability across all clouds will scale and provide consistent protection no matter where a workload or application is deployed. Portability and transferability are likely to be very low if cloud provider native tools are relied upon, and maintaining policy and controls across multiple toolsets is unlikely to scale well. An independent security toolset therefore may give the best results, as long as it has the ability to be programmatically deployed, can be provided using templates, not hinder the infrastructure-as-code methodology. The toolset should also be able to respond to the dynamic nature of could environments; no longer should firewall rulebases be defined by IP addresses, they should be consuming metadata from the cloud infrastructure to understand the classification, type, role and logical location of workloads and use that information to provide security controls. Security controls have to work in this dynamic way, otherwise there is no way to achieve Zero Trust given how fast things move and change in cloud infrastructures.
Dynamic provisioning of security and automation are also key when we consider that adversaries are also automating their attacks. Automation is key to them, in order to gain maximum efficiency of time and cost, to make sure as many attacks land and achieve their objectives for any given duration or budget. Given this is the case, it would seem natural that fighting automated adversaries with manual controls would likely be a losing fight. As well as automating controls to ensure security is not subverted or left behind by the rest of the fast-moving business, it's also needed to fight modern adversaries effectively. The infrastructure-as-code mentality also drives up consistency and drives down human error, whilst making security a Zero Touch item for development teams.
Zero Trust and automation are two topics which are discussed with almost every organisation I'm working with today, and they are both topics near to my heart. Over the last year I've been continually developing real-world examples and demonstrations of how these can be achieved, in particular a demonstration which for a new application stack requested by a developer:
- Defines the Zero Trust protect surface, the micro-perimeter, an enforces least privilege access
- Provides a segmentation gateway
- Uses dynamic resource definitions for security controls, not static attributes
- Defines granular policy around the key assets
- Is templated, but customisable for each use case
- Includes deployment of security, alongside workloads as they spin up
- Utilises automation toolsets (Terraform, Ansible) for deployment and ongoing configuration management
- Also, spins up an attacker machine and automates some attacks