Lessons learned from enterprise cloud security programs

By Karl Ots, CISSP

This article is adapted from author’s ISC2 Security Congress 2021 session of the same name, as well as his book Azure Security Handbook: A Comprehensive Guide for Defending Your Enterprise Environment.

The cloud computing model is maturing, moving from the experiments of early adopters to a mainstream computing platform underpinning established enterprises. With hundreds of existing services, a constant barrage of new announcements every year and a shortage of skilled practitioners, taming the beast of cloud security with traditional methods can seem overwhelming. In this article, we look at best practices and lessons learned based on my personal experience working on cloud security in Fortune 500 enterprises for more than a decade.

Cloud security shifts the security paradigm
In the world of on-premise computing, cybersecurity risks are perceived to be limited to the organization’s network. In the era of cloud computing, both the impact and likelihood of potential risks are significantly higher and extend far wider. Furthermore, with the corresponding advent of DevOps methodology, security is now the responsibility of everyone involved in the application development lifecycle, not just security specialists.

Application developers are no longer physically limited to services provided by central IT; they can adopt new cloud services on their own. At worst, this might lead into so-called shadow IT. At best, this expands the IT base of the organization exponentially.

At the same time, application developers are no longer protected by the outside perimeter of central teams: In the public cloud, they are responsible for far more. There is no corporate firewall, access control or centralized audit logging to fall back on. If developers have direct access to a cloud solution provider’s management console, day-to-day operations—such as vulnerability management, patching or monitoring—might fall under their responsibility, too.

As with any other paradigm-shifting technology, securing the public cloud is not as simple as extending or replicating existing security controls. There are several technical limitations, such as the changes in the network perimeter and the ability to access certain detection and monitoring capabilities. Some changes are required because business units and applications development teams are choosing the cloud due to flexibility, faster time to market or access to technologies that are not available in existing hosting platforms and technology stacks.

These differences eventually require a shift in how you implement security architecture. Rather than bolting existing controls, tools and processes on top of cloud workloads, enterprises have a unique opportunity to build security into the very platform that workloads are hosted in.

Shared responsibility model
To secure public cloud platforms, we need to understand each of them in detail. This requires both upskilling existing information security teams with cloud expertise and changing the way security responsibilities are assigned to customers and cloud service providers (CSPs).

Cloud security responsibilities are shared across various cloud service models: Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) and finally, on-premises computing (our own datacenter). As we move from on-premises to IaaS and further up in the cloud model abstractions, we give up control of configuring and operating said services. As we give up control, the CSP assumes the responsibility of securing these services.

A common misconception related to cloud security is rooted in incorrectly understanding these shared responsibilities. This can lead to omissions of key security controls, or even insufficient staffing levels. Therefore, I recommend you explicitly map out the shared responsibilities of every cloud service you are using.

Let’s look at managed Kubernetes services, such as Amazon EKS, Azure AKS or Google GKE, as an example (See Figure 1). While they are partially managed by cloud vendors, they are not provided as PaaS. The CSPs are responsible for creating, configuring and operating the Kubernetes control plane of your Kubernetes environment. This includes Kubernetes API servers, Etcd, kube-dns and other system components in the kube-system namespace. You are still responsible for significant parts of your Kubernetes service, such as access control, in-cluster network controls and patching of virtual machine nodes against vulnerabilities.

 

Figure 1: Shared responsibility model applied to managed Kubernetes services

Cloud security architecture components
Designing a cloud security architecture requires a careful balancing act between the cloud and existing on-premise internal and external security requirements. The COVID-19 pandemic has exacerbated and accelerated this situation for many security teams, as more cloud resources have been implemented quickly to support the move to distributed working.

Be careful when introducing cloud security controls. If existing controls disrupt and slow the cloud adoption down too much, business and application development counterparts might turn to so-called “shadow cloud” solutions. That is, they will provision their own cloud accounts (or subscriptions), often connecting them directly to the existing live environment.

Cloud security architecture components
To implement a cloud security architecture, conceptualize the required components as reusable and modular building blocks. Figure 2 below describes the concept of these architecture components.

Figure 2: Cloud security architecture components

• Workloads (or applications) are typically a collection of one or more cloud services. Depending on platform controls, these can be manually provisioned cloud services or instances of internal products.
• Products are an enterprise’s internal artefacts for cloud services, pre-configured to include the organization’s required controls. Typically, these are Infrastructure-as-Code artefacts, such as Azure Resource Manager templates, CloudFormation templates or Terraform modules.
• Landing Zone is your secured cloud platform. This is where you enforce security controls for your products to keep their secure state. There can be multiple landing zones. For example, migrated legacy applications might stay within a centrally managed landing zone within a spoke of centrally managed network. By contrast, new and experimental workloads might stay within a separate landing zone with more freedom to achieve fast time to market objectives, but offering less integration to shared services (such as networks). The secure landing zone components include identity and access management (IAM), monitoring and network controls.

Securing cloud IAM
The core question in successfully implementing a secure cloud landing zone is: How do you bring your existing cybersecurity controls and processes to the cloud world? To illustrate this, let’s consider Identity and Access Management (IAM).

Early on, you should focus on integrating cloud IAM with your existing IAM processes and tools. The cloud introduces a plethora of new access types, roles and non-personal user types. To avoid overloading an existing IAM organization, embrace automation. Using self-service tools and templates, you can create so-called “cloud account vending machines” that allow cloud application development teams to successfully provision required IAM resources, while following established security requirements.

Going further, you will also realize that most (new) deployments to your cloud environments are not performed by developers accessing the cloud using their own credentials. Instead, the preferred model for deploying to production would be to use a continuous deployment pipeline that performs the resource deployment. The benefit of this approach is that any changes to the application resources goes through the continuous deployment pipeline. From an IAM perspective, this adds an additional layer of abstraction and complexity (See Figure 3).

Figure 3: Pipeline deployments add a layer of complexity to cloud IAM

For this approach to work, you need to secure the identity used by the continuous deployment pipeline, or its credentials. You will also need to control access to modifying the continuous deployment pipeline. These are among the biggest lessons learned from working with enterprise cloud security programs.

Karl Ots, CISSP, is a cloud and cybersecurity leader with a decade of experience in Microsoft Azure security with large enterprises in fields such as technology, manufacturing, and finance. Karl has been recognized as global top technology visionary as a Microsoft Regional Director. He is a patented inventor, a LinkedIn Learning instructor and a Microsoft Azure MVP. In his current role, he serves as Head of Cloud Security at EPAM Systems, a global engineering and consulting company. He hosts the Cloud Gossip podcast.