By Rich Campagne, Sr. Vice President, Cloud Protection – Zscaler
By Henning Els, Sr. Solutions Architect – AWS
The notion of shared responsibility has become very popular in the public cloud, and rightly so. There are some elements of security that a Cloud Service Provider (CSP) like Amazon Web Services (AWS) should handle, and there are other areas the cloud customer is better suited to solve.
This division has been codified in the AWS Shared Responsibility Model.
At a high level, AWS is responsible for protecting the infrastructure on which the various AWS services run, also referred to as “security of the cloud.” The AWS customer is responsible for securing what runs on the AWS infrastructure, which may vary depending on the services used. This is referred to as “security in the cloud.”
This post is focused on helping organizations achieve their part of shared responsibility—security in the cloud. We start by introducing three areas of responsibility—configuration, access, and data—and then illustrate how tools from AWS Security Competency Partner Zscaler can address security and compliance issues in each of these areas.
Zscaler is a leader in cloud security, responsible for securing more than 400 of the Forbes Global 2,000 companies. These organizations and others running some of the world’s most complex networks quickly realize the benefits of Zscaler cloud-delivered security as a service.
Zscaler Cloud Protection provides a comprehensive approach to security “in” the cloud, partnering closely with AWS to ensure secure cloud migration for enterprises globally.
3 Areas of Responsibility for Security “in” the Cloud
The cloud customer’s responsibility for security “in” the cloud can be grouped into three major areas: configuration, access, and data.
Figure 1 – AWS Shared Responsibility Model.
This area involves ensuring cloud resources have proper configurations for authentication, data encryption, internet connectivity, and more.
With thousands of configurations across a wide range of cloud services, managing these securely becomes critical. Insecure configurations usually are the root cause to a security breach in the cloud.
Organizations typically set security guardrails and benchmark policies that are aligned to either compliance or security requirements, and then continuously monitor their cloud security controls to ensure they maintain a strong security posture.
The class of products that solves configuration-related challenges are referred to as Cloud Security Posture Management, or CSPM.
Every human and service in an AWS environment has an identity, and each identity has an associated set of permissions and entitlements.
With more than one way for an identity to inherit these permissions, it can be difficult to understand who has access to what resources, and what actions those identities are able to perform.
Despite this challenge, customers must be able to identify and remediate excessive permissions that humans and machines have by analyzing access policies, resource policies, actions, and roles. This is no small task when your AWS deployment might have tens of millions of individual permissions.
This is why another class of product known as Cloud Infrastructure Entitlement Management, or CIEM, has started to enjoy wide adoption.
Sensitive data is distributed and stored across multiple cloud environments, applications, cloud storage, and services. This can lead to data visibility, control, access, compliance, and remediation challenges.
Because organizations don’t always know where sensitive data exists in their AWS environment, it’s difficult to know where to focus additional data protection efforts for their most sensitive data. Organizations must identify and protect sensitive cloud data across their cloud footprints, leveraging automation to ensure consistent enforcement in dynamic cloud environments.
Data Loss Prevention, or DLP, can help identify, classify, and protect sensitive data from loss or theft.
Ensuring a Secure Deployment with Zscaler Workload Posture
The Zscaler Workload Posture platform was designed and built to make it simple to secure cloud configurations, access permissions, and data protection across multi-clouds. The solution combines CSPM, CIEM, and DLP.
Let’s take a quick look at a couple of examples in each area.
Cloud Security Posture Management (CSPM)
Assuming you have already onboarded your AWS accounts into the Zscaler platform, you’ll likely want to start with evaluating how your security posture compares to either your own security policies, or to one of the 18 major industry and geopolitical regulatory frameworks supported by Zscaler, including NIST, CIS, HIPAA, PCI, GDPR, and more.
Enabling this functionality is simple. Start by authorizing CSPM to access one or more of your AWS accounts or organizations. From there, the system automatically uses available APIs to build an inventory of every resource running across your organization’s AWS footprint. This process typically completes in minutes or hours, depending on the size of your deployment.
From there, the system analyzes the security posture and context of every configuration to detect security policy violations. There are more than 3,000 pre-built policies in the system, mapped to a broad range of categories including encryption, network connectivity, secrets management, identity and access management, and more.
These findings are prioritized and charted into a Policy Risk Matrix, which maps every policy violation based on risk impact and risk likelihood.
The 3,000 policies are also mapped to a broad range of cybersecurity frameworks, such as CSA and NIST, laws and regulations like GDPR and HIPAA, and industry benchmarks such as PCI DSS and ISO 27001.
This mapping takes the hard work out of manually mapping controls for a particular AWS service to your specific regulatory environment. Instead, you can focus your team’s efforts on remediating issues and working with your development and DevOps teams to ensure ongoing compliance moving forward.
The image below shows an example of an organization’s alignment to cloud security best practices, as well as the ISO 27005 risk-based prioritization of their configuration-related risks.
Figure 2 – ISO 27005 risk-based prioritization of AWS configurations.
With out-of-box support for 18+ compliance frameworks, continuous compliance monitoring is simplified. The image below shows an example of NIST CSF v1.1 report.
Figure 3 – NIST CSF v1.1 report.
Drilling down further into one of the critical incidents in this example shows that a server is still vulnerable to the Heartbleed security vulnerability.
Figure 4 – Recommendations for resolving Heartbleed vulnerability.
Clear, detailed remediation procedures are provided for assignment to the appropriate resource(s) to fix the issue in question.
These procedures can be consumed directly through the system, used to create a ticket in a third-party ITSM or similar system. In many cases, remediation can be done automatically via API integration with AWS.
Figure 5 – Recommended remediation procedures via AWS CLI.
Cloud Infrastructure Entitlement Management (CIEM)
Once you have a handle on secure configuration of your cloud workloads, the next step is to identify the excessive and risky permissions that often creep into cloud environments.
CIEM uncovers who and what can access cloud resources, down to granular-level single permissions. The product eliminates complexity by reconstructing a complete permission path from an identity to a resource, and by enabling rich analytical capabilities across multiple cloud platforms, such as searching, grouping, and reporting cloud permissions.
The information is continuously updated from multiple sources, and includes users, APIs (non-human accounts), roles, policies, actions, resources, permission usage, and more across multiple cloud platforms.
The product automatically resolves simple (roles, policies), complex (boundaries, conditions, ABAC), and very complex (elevations, escalations) permission configurations, enabling a simple and human-friendly permission presentation.
Zscaler applies unsupervised anomaly detection (a proprietary “Genetic Algorithm”) and clustering (“K-means” clustering algorithm) to detect and remediate the riskiest permission misconfigurations.
Smart Groups continuously learn the organization, infrastructure, permissions, and permission usage, and creates “smart groups” of users, APIs (non-human accounts), resources, and permissions based on hundreds of parameters. The engine then utilizes Smart Groups, along with other information, for extremely accurate detection and remediation of the riskiest unused permissions and other permission misconfigurations, without any manual configuration.
Here, you can see that our example AWS environment has a number of identity-related risks that should be addressed.
Figure 6 – Permissions-related incident reporting.
Drilling down into one of these risks, you can see that an Amazon Elastic Compute Cloud (Amazon EC2) instance running in us-east-2 has the ability to perform critical AWS Identity and Access Management (IAM) actions inherited via the “IAMFullAccess” policy in this account.
It is very risky, and completely unnecessary, to grant such permissions to a non-human resource. This is the type of access-related risk that should be remediated as quickly as possible.
Figure 7 – Access graph visualizing EC2 instance with IAM privileges.
Data Loss Prevention (DLP)
With configuration and access risks in check, the third and final step is to identify and protect sensitive data in the cloud.
The DLP engine, as with the other modules, uses API connectivity to AWS, in this case to scan data stores such as Amazon Simple Storage Service (Amazon S3) for certain types of sensitive information.
There is a broad catalog of policies for common types of sensitive data, including PHI, PCI, secrets, source code, login credentials, and more. In addition, you can create your own custom detection policies in the system. It detects based on keywords, regular expressions, exact data match, index data match, pre-built detection engines, and more.
In this example, we’ll configure the platform to identify and protect payment card data. We have configured several DLP policies to scan a particular AWS account for payment card data. For some matches, we are taking an action to remove external access. For others, we are reporting the incident internally without taking any particular remediation action.
Figure 8 – Data loss prevention policy example.
In this post, we explored three critical parts of the AWS Shared Responsibility Model the customer is responsible for: configuration, access, and data.
With Zscaler Workload Posture, customers can quickly and easily identify, remediate, and continuously ensure a strong security posture across all three areas.
If you’re interested in learning more, you can watch a video overview of the Zscaler Workload Posture platform that powers the examples illustrated in this post. Alternatively, you can dig deeper on CSPM or on DLP.
If you think you’ve learned enough and want to move forward, Zscaler Workload Posture is available on AWS Marketplace.
Zscaler – AWS Partner Spotlight
Zscaler is an AWS Security Competency Partner whose cloud services create fast, secure connections between users and applications, regardless of device, location, or network.
*Already worked with Zscaler? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.