UNDERSTANDING THE SHARED RESPONSIBILITY MODEL

Contents Introduction ..............................................................................3

How the Shared Responsibility Model Works................................4

Navigating the Shared Responsibility Model................................5

1. Identity and Access Controls.........................................6

2. Network Security Controls............................................7

3. Virtual Server Protection...............................................8

4. Workload Protection.....................................................9

5. Data Protection...........................................................11

6. Threat Intelligence......................................................11

How the Cloud Providers Help....................................................11

Summary..................................................................................13

2UNDERSTANDING THESHARED RESPONSIBILITY MODEL

3UNDERSTANDING THESHARED RESPONSIBILITY MODEL

Introduction In the not so distant past, security concerns were often cited as an obstacle to public cloud adoption. Enterprises were concerned that they would be unable to secure cloud-based applications, data, and workloads against loss, corruption, or theft at the same level as they could on their on-premises infrastructure.

Today, enterprises are no longer deliberating whether or not to migrate to the public cloud. According to the Flexera (formerly RightScale) 2020 State of the Cloud Report, a little more than nine out of ten companies are currently active on one or more public clouds. More specifically, Check Point’s 2020 Cloud Security Report shows 68% of organizations use two or more public cloud providers. Statista forecasts that by 2021, 94% of all data center workloads will be in the cloud. In short, although security is still viewed as a cloud challenge—along with compliance, governance, and cost containment—it is no longer considered a showstopper.

This shift in perception whereby cloud security is a challenge rather than a barrier is partially a result of the cloud providers’ investments in and commitment to security services and solutions that address the new challenges posed by security in the cloud, such as visibility, automation, and posture management. The providers, however, have also made it clear that the responsibility for cloud security is shared between them and the users. In this shared responsibility model, the providers are responsible for security of the cloud, while the users must take care of security in the cloud. In other words, the providers are responsible for the security of their physical infrastructure resources and services while the customers must secure all the assets (applications, data, containers, and so on) that they run on that infrastructure.

The importance of cloud users understanding their responsibilities within the shared responsibility model is underscored by Gartner’s forecast that “...[t]hrough 2025, 99% of cloud security failures will be the customer’s fault.” They also predict that 90% of the companies that fail to establish and enforce appropriate cloud security policies and controls will experience a breach of sensitive data. This supports the 2020 Cloud Security Report finding that 59% of organizations will increase their security budget within the next 12 months and 27% of that budget will be allocated to cloud security.

This white paper describes the shared responsibility model across the different cloud service models (IaaS, PaaS, and SaaS, as well as containers and serverless), with an emphasis on the cloud customer’s role in

upholding its end of the model.

In this shared responsibility model, the providers are responsible for security of the cloud, while the users must take care of security in the cloud.

4UNDERSTANDING THESHARED RESPONSIBILITY MODEL

How the Shared Responsibility Model Works There are generally three categories of responsibilities in the shared model: responsibilities that are always the provider’s, responsibilities that are always the customer’s, and responsibilities that vary depending on the service model (IaaS, PaaS, SaaS, containers or serverless).

The security responsibilities that are always the provider’s are related to the safeguarding of the infrastructure itself as well as access to, patching, and configuration of the physical hosts and the physical network on which the compute instances run and the storage and other resources reside.

The security responsibilities that are always the customer’s include:

• Identity and access management: Perhaps the most fundamental customer responsibility is to manage users and their access privileges, with the overriding goal being to limit to a minimum the privileges granted to the different users and user groups.

• Accounts: It is the customer’s responsibility to safeguard its cloud account(s) from unauthorized access in general and hijacking in particular. These controls include multi-factor authentication for root user accounts, frequent rotation of root user passwords, minimizing overly-permissive permissions of APIs, and proactive monitoring of account activity.

• Data: The customer must establish and maintain a map of its cloud-based data (and meta-data), dynamically categorize those data assets by sensitivity/criticality according to its governance policies, and implement the appropriate data protection processes. Those processes, which should be as automated as possible, include backup/recovery, failover/failback, archiving, and disaster recovery, encryption, private and personal data (PII) protection, and more.

• Compliance: The organization must ensure that its cloud assets comply with all relevant regulatory policies such as NIST, CIS, HIPAA, PCI:DSS, GDPR and so on.

One of the tricky parts of the model is that the division of responsibilities differs across the IaaS, SaaS, and PaaS service models. The diagram below (from Microsoft Azure but relevant to all the providers) shows that, in the PaaS service model, the customer is only responsible for the security of its applications and its data, with the provider taking over responsibility for patching and configuring runtime and middleware code as well as the guest operating systems. In the fully managed SaaS model, the provider steps in to take responsibility for the security of the service’s application code and data.

5UNDERSTANDING THESHARED RESPONSIBILITY MODEL

In short, the shared responsibility model lets the provider worry about security basics, freeing up the customer to focus its resources on business-critical issues such as improving the organization’s security incident management. However, since there can be confusion as to where the lines of responsibility fall, it is incumbent on each enterprise to learn how to navigate the model responsibly.

Navigating the Shared Responsibility Model Note: Although this section uses AWS as a reference, the concepts and best practices apply to all of the cloud providers

AWS has published guidelines to help its customers architect a value-capturing cloud infrastructure that stands on five essential pillars: operational excellence, security, reliability, performance efficiency, and cost optimization.

The security pillar of the cloud architecture focuses on assessing risk and implementing mitigation strat- egies in order to protect cloud information, systems, and assets. AWS identifies six cloud security design principles:

1. A strong identity foundation for granular control over who can do what.

2. Data lifecycle traceability, for upholding data integrity and assisting in cloud forensics.

Figure 1: How the lines of responsibility shift across service models (source: Microsoft)

6UNDERSTANDING THESHARED RESPONSIBILITY MODEL

3. A layered security approach that achieves Defense in Depth (DiD) across networks, applications and data.

4. Automate security best practices, for a consistent and well-orchestrated security posture.

5. Data protection both in-transit and at-rest.

6. Readiness for security events in order to quickly identify and respond to security incidents.

In this section, we take a closer look at customer responsibilities and best practices in six areas that are key to establishing and maintaining the cloud security pillar: identity and access controls, network controls, server protection, application protection, data encryption, and threat intelligence.

1. Identity and Access Controls

Although the cloud providers offer supporting tools and services, identity and access management (IAM) is always the responsibility of the customer. It is entirely up to the customer to prevent unauthorized access to cloud assets.

Some of the IAM best practices that cloud users should implement include:

• Consistent policies: Work at the group/role rather than at the individual IAM level so that it is easier to implement consistent access and authentication policies. Working with groups and roles also makes it easier to modify and update IAM definitions in the face of dynamic business requirements.

• Keep privileges minimal: Grant access only to those assets and APIs that are essential to carry out the group/role’s tasks as required by their jobs.

• Authentication: The more extensive the privileges, the higher the required levels of authentication. Admin accounts, for example, should always be subject to two-factor authentication. In addition, strictly restrict access to the root account which, by definition, has access to every cloud resource.

7UNDERSTANDING THESHARED RESPONSIBILITY MODEL

• Policy-based access rules: Use policies to restrict access, such as date/time conditions that restrict access to a user group’s usual work hours, or allowing access only if the request comes from a trusted IP address.

• Good IAM hygiene: Strictly enforce strong password policies. Establish processes that terminate users and revoke permissions that are no longer active or relevant. Wherever possible, provide time-limited access credentials that expire automatically, ensuring that credentials are never left floating in cyber- space where they can be misused.

• Monitoring: Constantly monitor IAM activity in order to quickly identify anomalous behavior that could be indicative of an internal or external threat.

2. Network Security Controls The security of the physical network infrastructure is the responsibility of the provider. The customer, however, is responsible for the secure configuration of that infrastructure running their services, as well as monitoring the traffic that enters and exits the network to their services.

When configuring the network infrastructure and implementing network controls, it is important to adopt a zero trust approach whereby all users, devices, and network packets are considered a threat until verified otherwise.

Some cloud network configuration best practices include:

• Isolation: Deploy business-critical resources and applications within a logically isolated section of the provider’s cloud network. In AWS and Google Cloud this is called a Virtual Private Cloud (VPC); in Azure a virtual network (vNET). Also, consider using a physical or logical perimeter network segment (DMZ) as another layer of isolation between your virtual network(s) and the internet.

• Micro-Segmentation: Use subnets to create secure zones that segment workloads from each other. Ap- ply granular security policies at the subnet gateways to control traffic between zones, as well as between east-west traffic within zones.

• Dedicated links: In hybrid architectures, use dedicated secure WAN links to protect the traffic flowing between on-premises and cloud resources.

• Customize the routing configurations: By default, instances can connect with other instances in all sub- nets of the virtual network, as well as to the internet. Use static user-defined routes to granularly control access to virtual devices, virtual network gateways, virtual networks, and public IP addresses.

• Security appliances: Going beyond the network and transport layers, secure higher levels of the stack by deploying and configuring network appliances (virtual and/or physical) such as firewalls, intrusion detec- tion/prevention solutions, and vulnerability managers. See Application Protection below for more tips.

8UNDERSTANDING THESHARED RESPONSIBILITY MODEL

3. Virtual Server Protection The cloud provider is responsible for patching and configuring the bare-metal servers that host the virtu- al machines, containers and serverless workloads. It is up to the customer, however, to ensure that these workloads are correctly provisioned and secured.

Attackers constantly probe cloud instances for vulnerabilities, knowing that successful access exposes all the cloud assets that are running on these servers.

Following are best practices to enhance the security of virtual servers:

• Cloud Security Posture Management: When provisioning virtual servers, use governance and compli- ance rules, as well as templates that enforce the organization’s server security policies, such as firewall, anti-virus, and host intrusion settings. Then continuously audit for configuration deviations. Automate remediation of these deviations where possible.

• Change management: Have clear processes in place that control changes to virtual server configura- tions. Ideally, lock down server configurations so that they cannot be changed accidentally or maliciously.

• Software updates: Regularly update the guest OS and other relevant software such as server control panels, to minimize a compromise through software vulnerabilities.

• Safeguard SSH (Secure Shell) access to the virtual server: Switch SSH to a non-default port; use SSH public/private keys so that only users with a private key can read encrypted data; disable SSH access to the root account.

• Carefully manage the root user, whose unlimited privileges make it an enticing target: Immediately upon provisioning the virtual server, define an admin user (with extra privileges as necessary) and use that user only to perform all routine server operations.

• Maintain good server hygiene: Remove or turn off unnecessary services; block all ports except those needed by the OS and installed components, such as HTTP, HTTPS, and SSH; use a unique key for each external service; and enforce a strong password policy.

• Scanning, monitoring, and logging: Use the virtual server’s own logs and other cloud-native monitoring and logging solutions to scan for and identify misconfigurations and anomalous behavior, such as brute force login attempts.

9UNDERSTANDING THESHARED RESPONSIBILITY MODEL

4. Workload Protection Workloads running applications are highly vulnerable to attacks, with the top three security risks (according to OWASP) being injection (SQL, NoSQL, OS, LDAP), broken authentication and session management, and the exposure of sensitive data.

There is very little that the provider can do to protect web applications, placing the responsibility squarely on the shoulders of the customer.

Here are some best practices that can mitigate the security risks posed by your applications—including containerized applications:

• Secure coding practices: With today’s distributed applications, it is up to the developers to ensure that all application components (including third-party, open-source modules) uphold secure coding prac- tices, such as validating inputs, default denial of access, sanitizing data sent to other components (to protect against injection attacks), and more.

• Configuring a web application firewall (WAF): As opposed to a regular network firewall that blocks ports, a WAF actually inspects the traffic to and from web application servers. It is important to use a next-generation WAF designed for cloud-native applications, that automatically updates WAF rules when traffic behavior changes, and is deployed closer to microservice architectures that run work- loads.

• Minimize over-permissiveness: Application APIs play an important role in how an application commu- nicates publicly or internally with other services in the cloud. Allowing broader permissions than what is required by these APIs exposes the application to a possible attack. Decide which users and services require which permissions, and minimize to their least permissive state.

• Source code scanning: Scan developed source code as well as any utilized open source code for vulner- abilities, to minimize impact of a compromise in a runtime production cloud environment.

• Application runtime protection: Deploy an automated tool that continuously scans your web applica- tions for security vulnerabilities such as cross-site scripting, SQL or command injection, traffic and API anomalies that deviate outside of known behavior, and non-secure web server configurations. OWASP provides a comprehensive listing of commercial and open-source application vulnerability scanners.

• Penetration testing: Somewhat related to vulnerability scanning, simulated penetration attacks are an essential best practice to secure web applications and websites against unauthorized access to sensi- tive data.

10UNDERSTANDING THESHARED RESPONSIBILITY MODEL

5. Data Protection Keeping data secure is a goal that is common to all of the key areas of focus described above (IAM, network, virtual servers, and applications). However, there are some specific data protection best practices that should be embraced, such as:

• Encryption of application data: It is important that application data be encrypted both in transit - using protocols such as Transport Layer Security (TLS) - and at rest. Most cloud data storage resources are encrypted by default, such as Amazon Elastic Block Storage (EBS) volumes.

• Secure file shares: Use secure protocols such as File Transfer Protocol Secure (FTPS) to encrypt data files in transit as well as their authentication metadata.

• Secure communications: Use Secure Socket Layer (SSL) to ensure that sensitive data is protected as it flows over server-client and server-server communication channels.

• Compliance risk management: Implement automated and continuous processes for auditing the secu- rity posture of the enterprise’s cloud assets per all relevant regulatory policies and recommended best practices.

• Good data storage resource hygiene: Watch out for loose access privileges to cloud data storage re- sources such as Amazon S3 buckets. Time and time again, misconfigured buckets are cited as the cause of leakage of highly sensitive data. In addition, make sure that when compute instances are terminated, their associated storage volumes are terminated as well. In addition to racking up cloud costs, orphan data resources can expose data to unnecessary risk.

Good data storage resource hygiene: Watch out for loose access privileges to cloud data storage resources such as Amazon S3 buckets. Time and time again, misconfigured buckets are cited as the cause of leakage of highly sensitive data.

11UNDERSTANDING THESHARED RESPONSIBILITY MODEL

6. Threat Intelligence With today’s elastic cloud environments and ephemeral cloud-native services, cloud threat intelligence is an essential pillar of cloud security. In order to detect both known and unknown threats in real-time, cloud users must implement tools and policies that support cloud intrusion detection, network traffic visualization, and user activity analytics. Cloud threat intelligence best practices include:

• Adding context to cloud logs: With data relationship and context being essential for effective threat hunting, the large and diverse streams of cloud-native monitoring and log data must be aggregated and given context. Log data should be intelligently cross-referenced with internal data (asset and configu- ration management systems, vulnerability scanners, etc.) and external data (public threat intelligence feeds, IP reputation and geolocation databases, etc.). Having tools that can build visual relationships and give context to the data will not only help visualize the cloud threat landscape, but also provide a quicker response time when incidents occur.

• Forensics and behavior analytics: In order to catch unknown threats quickly, AI-based anomaly detec- tion algorithms are essential for spotting suspicious activity that deviates from network and user activity baselines. These potential threats should then undergo forensics analysis, supported by a robust IOC (Indicators of Compromise) database.

• Actionable visualizations and queries: The cloud security team must be able to visually explore the organization’s network activity and traffic, as well as run queries to support deep investigation, incident response, and threat hunting.

• Alerts and auto-remediation: All of the above best practices make it possible to issue real-time alerts concerning policy violations and intrusion detection. Wherever possible these alerts and other events should be used to trigger auto-remediation workflows.

How the Cloud Providers Help Each cloud provider offers tools and services to help its customers monitor and secure their cloud resourc- es. It is good practice to integrate these cloud provider tools into your existing security stack in order to help fulfill your part in the shared responsibility model.

The following table provides a sampling of some typical cloud provider tools. Please note that these tools may change over time. Additionally, each cloud provider’s tool will probably not have the same features and capabilities as the other cloud providers’ tools in the same column.

12UNDERSTANDING THESHARED RESPONSIBILITY MODEL

Although cloud provider security tools provide benefits in their own right, it is important to remember that each provider’s tooling applies only to its own cloud services and environment.

When you consider that most enterprises today deploy with two or more cloud providers, this disconnect creates a lack of consistency and a potential security gap. Figure 3 shows an illustrative example of an enter- prise that moves 26 on-premises services to the cloud will end up with an equivalent set of services on each cloud provider infrastructure. Given the hybrid and multi-cloud environments favored these days, careful management and orchestration is required in order to avoid security and compliance gaps. It is important to consider third-party solutions that provide unified and consistent advanced security across multiple clouds. These solutions should also provide end-to-end security, data protection, visibility, advanced visualizations, and consistent control across public cloud providers, private cloud providers, and on-premises deployments.

Figure 2: Typical cloud provider tools to monitor and secure cloud resources

Figure 3: On-premises services are duplicated on each cloud provider when moved into the cloud

AWS

Microsof t A zure

Google Cloud Plat form

Firewalls Cloud Monitoring andThreat Detection Securit y Console

Google Cloud firewalls

Amazon GuardDuty AWS CloudTrail Logs

Azure Advanced Threat Protection

Microsoft Defender for Cloud

Event Threat Detection

AWS Security Hub

Microsoft Defender for Cloud

Microsoft Sentinel

Cloud Security Command Center

Azure Firewall Network security groups

Security groups Network ACLs

13UNDERSTANDING THESHARED RESPONSIBILITY MODEL

Worldwide Headquarters 5 Ha’Solelim Street, Tel Aviv 67897, Israel | Tel: 972-3-753-4555 | Fax: 972-3-624-1100 | Email: info@checkpoint.com

U.S. Headquarters 959 Skyway Road, Suite 300, San Carlos, CA 94070 | Tel: 800-429-4391; 650-628-2000 | Fax: 650-654-4233

www.checkpoint.com

© 2023 Check Point Software Technologies Ltd. All rights reserved.

Summary Enterprises must understand that they share responsibility with the cloud provider for cloud security. In the Shared Responsibility Model, the provider secures its own infrastructure resources and services while the customer safeguards its cloud-based applications, workloads, and data. In order to establish a strong security pillar in its cloud infrastructure, an organization must implement and maintain best practices in a number of key areas:

• Identity and access controls that grant access to authorized users and devices only, with permissions kept strictly to a minimum.

• Proper configuration of the provider’s network infrastructure, adopting a zero trust approach.

• Securing provisioned instances through careful configuration and change management, regular soft- ware updates, and more.

• Mitigating security risks associated with workloads running applications by building security into code and good vulnerability management.

• Protection for data and files at rest and in transit.

Although the cloud providers provide tools and services to help the customer uphold its end of the Shared Responsibility Model, it is up to the organization to ensure that it has visibility into and control of security across its entire hybrid/multi-cloud environment.

For more information and additional detail about cloud security solutions, please visit this webpage.