Physical Environment

The physical environment is composed of the server rooms, data centers, and other physical locations of the CSP. The identity of the CSP may vary by the different cloud security models, as follows:

• A private cloud is often built by a company on its own premises, such as an IT group that runs cloud services supporting multiple business units or departments. If this occurs, the organization is the CSP, and the units or departments are customers; though they are all part of the same organization, costs associated with cloud services are usually tracked in the same manner as using a public cloud. This allows the organization to be very granular in identifying resource usage. Private clouds can also be virtual, and major CSPs including AWS, Azure, and Google Cloud offer the ability to use their infrastructure in an isolated virtual private cloud (VPC).
• In a community cloud, a member of the community hosts the space and equipment needed and is responsible for physical security. The community member hosting the cloud is the CSP. Similar to VPCs, a community cloud may be built using a private section of a commercial CSP, and the CSP is responsible for physical security.
• In public clouds, the CSP is the company providing the service, such as AWS, Microsoft, Google, IBM, and so on. This commercial vendor is the CSP and is responsible for the physical security of their cloud infrastructure.

The physical environment is under the sole control of the CSP, and it is their responsibility to provide all physical security. This includes responsibility for monitoring, auditing, and maintaining a secure environment. Security risks that affect cloud infrastructure are the same as those affecting any data center, regardless of whether they are on-premises or provided by a third party. These include physical security of the equipment, access control to the facility, environmental controls like heating and air conditioning, and utilities at the site like water and electricity.

CSPs utilize common controls to address these risks. For physical security these include standard measures such as locks, security personnel, lights, fences, visitor check-in procedures, and the like. Identity and access management (IAM) for CSP technical personnel will require tools including a single sign-on (SSO) provider, logging of user actions, and multifactor authentication (MFA) to provide robust access controls and logging.

CSPs will address controls for data confidentiality and integrity in a similar manner to cloud customers, but with much broader controls. For example, ensuring that communication lines are not physically compromised might involve locating telecommunications equipment inside a controlled area of the CSP's building or campus. This makes it easier to guard against and detect any physical tampering, such as wiretapping or cutting communication lines.

Network and Communications

Physical networking gear is housed in facilities controlled by the CSP, and it is the CSP's responsibility to physically secure the device as well as logical security controls like proper configuration. Any components housed at the customer's facility (on-premises) are the responsibility of the customer. The largest area of concern is the public Internet that exists between these two. Since the Internet is a shared resource, the responsibility for securing data transiting the Internet falls to the individuals using it, so both the CSP and cloud customer must identify and implement ways of securing data in transit. This will most often involve the use of cryptography.

For this reason, the CSP must support secure protocols like HTTPS, and the customer must use the secure protocols. Encrypting data prior to transmission is also an effective method for preserving confidentiality and may involve the customer encrypting the data before it leaves the customer's network or using a VPN to securely transmit data over untrusted networks like the Internet. At each end of the transmission pipeline, both the customer and the CSP are responsible for the firewalls and other systems needed to maintain secure communications. Some organizations may find the use of dedicated communication lines a more effective way of protecting their data in transit, avoiding the use of untrusted networks.

In the shared security model, the CSP provides tools for secure computing, logging, encryption, and so on. However, customers do retain responsibility for activating and configuring these features to meet their needs. In all service delivery models, it is the responsibility of the customer to connect to and transmit data to the cloud service securely.

Consider, for example, that you are a company shipping a product. You have many ways in which you can accomplish this.

• You could create your own fleet, leasing aircraft from a supplier but providing your own pilots and cargo personnel. In this case, it is similar to an infrastructure as a service (IaaS) environment. The supplier is responsible for the aircraft provided, but not how you use the aircraft or the safety and security of your product.
• In a different approach, the supplier may provide the aircraft and pilots, and you handle the storage and security of the cargo. You remain responsible for the safety and security of your product, and the supplier provides a safe aircraft operated by qualified personnel, equivalent to a platform as a service (PaaS) environment.
• In the simplest method, you drop off the package with the supplier. Once it's in their possession, the supplier is responsible for the security and delivery of the package. They are not responsible for the manner in which the product is packaged or the condition of the product when it is dropped off with the service. Although they make a best effort to deliver the package in good condition, it is possible for the package to be damaged, so compensating controls like insurance are recommended. This is similar to using a software as a service (SaaS) environment.

This package delivery example is a useful metaphor for the security of data in transit with the IaaS, PaaS, and SaaS delivery models. Each model has potential benefits in terms of the amount of flexibility offered, which is offset by associated costs.

• In an IaaS service model, the customer is responsible for configuring the environment as well as enforcing company policies in the use of systems, as if the systems were on-premises as well as the connection to the CSP. The CSP is responsible for the technology provided but not how it is used, and the cost of that responsibility remains with the customer.
• In a PaaS module, the CSP is responsible for the physical components, the internal network, and the tools provided. The customer is responsible for the proper use of those tools and the connection to the CSP. Services provided by the CSP are likely to be cheaper than what the customer could do in house, due to the shared resources, but the customer also gives up some control.
• In a SaaS model, the customer remains responsible for access to the cloud service in a secure manner—using appropriate technologies to connect with and transmit data to and from the service securely. Once the data is in the CSP, the customer has less control over it, but the shared nature of the cloud means these services are available at significantly lower cost.

Compute

The compute resources are the infrastructure components that deliver virtual machines (VMs), disk, processor, memory, and network resources. These resources are owned by and under the direct control of the CSP. The security issues are the same for these resources in a cloud environment as they are on-premise with the additional challenge of multitenancy.

The CSP in every delivery and service model remains responsible for the maintenance and security of the physical components. These are owned and supported by the CSP. The customer in every delivery and service model remains responsible for their data and their users. Between the physical components, there is a vast array of software and other components. Who is responsible for each of these remaining parts varies by service and delivery model and sometimes by the CSP. The contract between the customer and the CSP should spell out the responsibilities for each part of the cloud environment. Typical responsibilities will be described for each service model (IaaS, PaaS, and SaaS).

In an IaaS environment, the CSP provides the hardware components and may provide networking, virtualization, and virtualization operating systems. The CSP is responsible for the security of any software components it provides, such as virtualization and operating system (OS) software, and the CSP is also responsible for the versioning and security of those components.

When the CSP provides the virtualization and OS software, some of the software configuration may be left to the customer, such as controlling access to the VMs the customer creates in the cloud. When this is the case, the customer is responsible for the security implications of the configuration they choose, and in IaaS the customer has the most responsibility for security. Other than the hardware components and system software provided, the customer remains responsible for all other security for the tools they install, software they develop, and, of course, all identity and access management, customer records, and other data. These responsibilities include patching and versioning of the software installed or developed by the customer and the security of data at rest and in motion.

In a PaaS environment, the CSP takes on more responsibility for providing services, and the corresponding security requirements. In addition to the responsibilities of IaaS, the CSP takes on security responsibility for services including operating systems, database management systems (DBMSs), or whatever other platforms are being offered in the cloud environment. While the customer has some ability to configure these services, all services provided by the CSP will usually be maintained by the CSP, including patching and versioning. The customer is responsible for the configuration and use of all systems and services provided as well as the patching and versioning of any software they install or develop on the platform. The customer is always responsible for the security of their data and users. The contract with the CSP should address these issues.

In a SaaS environment, the customer is usually responsible for only the customization of the SaaS service, as well as the security of their users and the data used or produced by the service. The CSP is responsible for the security of all other compute resources.

Virtualization

There are two types of hypervisors that provide virtualization. These are Type 1 hypervisors, also known as bare-metal hypervisors, and Type 2 hypervisors, also known as hosted hypervisors. Among the major CSPs the Type 1 hypervisor is more common, such as the Xen hypervisor provided by AWS and the Hyper-V hypervisor provided in Azure.

Type 1 hypervisors run directly on a physical server and its associated hardware components, rather than running on top of a traditional OS. In this scenario, the hypervisor provides the OS functionality, with VMs running atop the hypervisor. The hypervisor and virtualization environment are managed with a management console separate from the hypervisor. VMs running on a Type 1 hypervisor can move between physical machines, and when done properly, it is invisible to the end user. In addition to Hyper-V and the XenServer hypervisors, other common Type 1 hypervisors include VMware vSphere with ESX/ESXi and Oracle VM.

Type 2 hypervisors are more complex, as they run on top of a traditional OS. At the bottom is the hardware, and running on top of that is a host OS, such as Windows, macOS, or Linux. The hypervisor runs as a program on top of the OS; examples include Oracle VM VirtualBox, VMware Workstation Pro/VMware Fusion, Parallels Desktop, and Windows Virtual PC. These are not usually used for enterprise solutions because they are less efficient than Type 1 hypervisor environments, but Type 2 hypervisors are frequently used for individual needs or environments like testing where absolute efficiency is not as important. Management of the VMs is built into the Type 2 hypervisor, and usually includes options like specifying individual VM compute, storage, and memory parameters.

The security of the hypervisor is always the responsibility of the CSP. The virtual network and virtual machine may be the responsibility of either the CSP or the customer, depending on the cloud service model as described in the earlier “Compute” section.

Hypervisor security is critical. If unauthorized access to the hypervisor is achieved, the attacker can access every VM on the system and potentially obtain the data stored on each VM. A VM escape is a type of attack in which a malicious user can break the isolation between VMs running on a hypervisor by gaining access outside their assigned VM. In both Type 1 and Type 2 hypervisors, the security of the hypervisor is critical to avoid hypervisor takeover or VM escape. In a Type 2 hypervisor, host OS security is also important, as a breach of the host OS can potentially allow takeover of the hypervisor and all associated VMs as well. Proper IAM and other controls limiting access to those with both proper credentials (authentication) and a business need (authorization) can protect your systems and data. In a cloud computing multitenant model, there is another challenge: once an attacker gains access to be on a server hosting multiple VMs, they can compromise systems or data belonging to however many customers are running workloads on that server. Security of the hypervisor is the responsibility of the CSP, and a robust set of controls should be in place to provide customers with assurance that their virtualized systems are safe.

CSP hypervisor security includes preventing physical access to the servers and limiting both local and remote access to the hypervisor. The access that is permitted must be logged, and hypervisor maintenance or administrative access should be thoroughly monitored. The CSP must also keep the hypervisor software current and updated with patch management procedures.

The virtual network between the hypervisor and the VM is also a potential attack surface. The responsibility for security in this layer is often shared between the CSP and the customer. In a virtual network, you have virtual switches, virtual firewalls, virtual IP addresses, etc. The key to security is to isolate each virtual network so that only permitted traffic is able to move between virtual networks. This isolation will reduce the possibility of attacks being launched from the physical network or from the virtual network of other tenants, preventing attacks such as VLAN hopping, while preserving desired system communications such as access by a web server to application servers in a different VLAN. The security of the network virtualization hardware and software is the responsibility of the CSP, while proper VLAN configuration for a specific application is the responsibility of the customer.

A control layer between the real and virtual devices such as switches and firewalls and the VMs can be created through the use of software-defined networking (SDN). In AWS, when you create a virtual private cloud (VPC), the software-defined networking creates the public and private networking options (subnets, routes, etc.). To provide security to the software-defined network, you will need to manage both certificates and communication between the VM management plane and the data plane. This includes authentication, authorization, and encryption.

The security methods for a virtual network are not that much different from physical networks. However, certain tools may be better suited to certain tasks in a virtual environment, and some legacy tools may not function at all. For example, some network monitoring tools require a device plugged into the mirror or span port of a switch so they can analyze traffic. However, a virtualized network does not provide such a capability, so these types of tools will not provide any security benefit. Using security tools designed specifically for virtual environments or even tools designed explicitly for cloud security are recommended.

The final attack surface in the virtualization space is the VM itself. Responsibility for VM security may be shared, but it is usually the responsibility of the customer in an IaaS model. In the PaaS model the security of the VM is the responsibility of the CSP if the platform is also the responsibility of the CSP, as in a hosted database platform. The CSP is responsible for securing the VM used to provide the hosted database in this model, while the customer would be responsible for secure configuration of the database. If the customer is creating VMs on top of a virtualization platform, then security of any VMs created remains the responsibility of the customer. In a SaaS model, the VM is created and used by the CSP to provide a service, and the responsibility of VM security rests on the CSP.

Storage

Various types of cloud storage technologies are discussed in Domain 1, “Cloud Concepts, Architecture, and Design.” Cloud storage has a number of potential security issues, and the importance of the shared responsibility model with respect to cloud storage cannot be overstated. Data spends most of its life at rest, so understanding who is responsible for securing cloud storage is a key undertaking. At a basic level, the CSP is responsible for physical protection of data centers and the storage infrastructure they contain, while the customer is responsible for the logical security and privacy of data they store in the CSP's environment. The CSP is responsible for the security patches and maintenance of data storage technologies and other data services they provide, while the customer is responsible for properly configuring and using the storage tools.

CSPs provide a set of controls and configuration options for secure use of their storage platforms. The customer is responsible for assessing the adequacy of these controls and properly configuring and using the controls available. These controls can include how the data is accessed, such as over the public Internet, via a VPN, or only internally from other cloud VLANs. The customer is also responsible for ensuring adequate protection for the data at rest and in motion based on the capabilities offered by the CSP. For example, the CSP may provide the ability to encrypt data when it is written to the storage device. If the encryption is done using a customer-provided key, then keys must be securely generated and stored to safeguard the data. Similarly, many cloud storage tools can be configured for either public or private access. Failure to properly configure secure storage using available controls is the fault of the customer.

In a cloud environment, you lose control of the physical medium where your data is stored, but you retain responsibility for the security and privacy of that data. These challenges include the inability to securely wipe physical storage and the possibility of a tenant being allocated storage space that was previously allocated to you. This creates the possibility of fragments of your data files existing on another tenant's allocated storage space. You retain responsibility for this data and cannot rely on the CSP to securely wipe the physical storage areas.

Compensating controls for the lack of physical control of the storage medium include only storing data in an encrypted format and retaining control of the keys needed to decrypt the data. This permits crypto shredding when data is no longer needed, rendering any recoverable fragments useless.

Management Plane

The management plane provides the tools (web interface and APIs) necessary to configure, monitor, and control your cloud environment. It is separate from and works with the control plane and the data plane. If you have control of the management plane, you have control of the cloud environment; similar to system administration tools, it is a high-value target of attackers and should be tightly controlled.

Control of the management plane is essential and starts with limiting and controlling access. An attacker who can gain access to the management plane will have free rein over your cloud environment. Since virtualized infrastructure is all accessible through management plane tools like a cloud console, the impact of a compromised account or malicious access is significant.

The most important account to protect is root, or any named account that has administrative/superuser functionality. The start of this protection is the enforcement of a strong password policy. The definition of a strong password is an evolving question that has recently been addressed by updated guidance in NIST in SP 800-63, Digital Identity Guidelines. The most important factor in a secure password is length—longer is better, so passphrases are preferred over passwords—and secure use practices like not sharing passwords or reusing them across sites or services. Human factors include making passphrases easy to remember but difficult to guess, which discourages bad habits like reuse.

A strong password policy needs to be coupled with other measures for the critical root and administrative accounts due to the broad access they grant. MFA should be implemented for these accounts and may take the form of a hardware token that is stored securely or other methods like an authenticator app on a trusted device like the user's smartphone. In general, software solutions add some protection, but not as much as the hardware solutions. Widespread MFA is also relatively new, and novel attacks against it are still developing, so any solution should be routinely reviewed as part of risk assessments to ensure that it is still providing adequate security. SMS was considered an acceptable method for MFA, but attackers found simple ways to capture the codes being sent, which rendered the protection meaningless.

Role-based access control (RBAC) or access groups are another method to limit access to these sensitive accounts. Using RBAC or access groups makes management of these groups and permissions important. If rights are not deleted when an employee changes positions or employment, access can become too broad very quickly. Another step is to limit access to users connecting from a known on-premises network or through a VPN, if remote work is required. This approach, however, is rapidly being replaced by zero trust network architecture (ZTNA), which does away with trusted networks in favor of verifying every user request. This minimizes risks associated with trusted insiders or malicious users who have gained unauthorized access to secure networks.

Another method for limiting access is to use attribute-based access control (ABAC), also called policy-based access control. Using this method, a variety of attributes can be used with complex Boolean expressions to determine access. Typical attributes such as username are one part of the policy, which can also include attributes like the usual time a user logs in, location they log in from, or even details of the device they are connecting from. ABAC can be used to ensure that only authorized users connecting from a corporate-managed endpoint are allowed access. If the user is accessing a system from a new geographic location, ABAC can be configured to require additional proof of the user's identity, such as an MFA prompt. Many social networks implement such a feature to prevent stolen devices from gaining access to social media accounts—even if the authorized user has traveled and taken a device with them, they must prove their identity by answering security questions since the device is not logging in from the normal, expected location.

Each of these methods can make accessing critical root or administrative accounts more difficult for both legitimate users and malicious users alike. How tightly you lock down these accounts is in direct proportion to the value of the information and processes in your cloud. As with all security measures, it requires a balance to create as much security as possible while maintaining reasonable business access.

Root and administrative accounts are typically the only accounts with access to the management plane. The end user may have some limited access to the service offering tools for provisioning, configuring, and managing resources, but should not be allowed access to manage the entire cloud environment. The degree of control will be determined by each business, but end users will normally be restricted from accessing the management plane. The separation of management and other workforce users makes the creation of separate accounts for development, testing, and production an important method of control.

In instances where the management functions are shared between the customer and the CSP, careful separation of those functions is necessary to provide proper authorization and control. In a Cisco cloud environment, the management plane protection (MPP) tool is available. AWS provides the AWS Management Console.

These are some of the methods that can be used to protect the cloud management plane. A layered defense is important, and the amount of work used to protect the management plane is, in the end, a business decision. The cloud security professional must be aware of the methods available for protection in order to be a trusted advisor to the business in this matter. Major CSPs including AWS and Azure publish security reference architectures, which detail best practices for utilizing each cloud's particular services and offerings. This includes security configurations, identity and access controls, and best practices like creating separate management plane accounts for production, testing, and staging environments.

Logical Design

The logical design of a data center is an abstraction. In designing a logical data center, the customer utilizes software and services provided by the CSP, and a chief concern in provisioning such a data center is implementing security controls appropriate to the data that will be handled in the cloud. The needs of a data center include access management, monitoring for compliance and regulatory requirements, patch management, log capture and analysis, and secure configuration of all services used.

In a logical data center design, a perimeter needs to be established with IAM and monitoring of all attempts to access the data. Access control can be accomplished through various IAM methods, including authentication and authorization, security groups, and VPCs, as well as the management consoles. Each major CSP offers services equivalent to software firewalls, traffic monitoring, and security monitoring like intrusion detection systems (IDS), which can be implemented to monitor data center activities and alert on potentially malicious behavior.

All services used should have a standard configuration that is reviewed and approved for use by the organization. This configuration is determined by the business and specifies how each approved cloud service is to be configured and can be used, and it is similar to hardening guides or configuration baselines in on-premises environments. Using a standard pattern/configuration makes administering and maintaining cloud services simpler and provides a consistent level of security. Deviations from approved configurations should be approved through an exception process that includes analysis of the risk presented by the deviation and any additional mitigations required. Secure baseline configurations can provide a more secure environment for the data center, and it is essential to monitor these configurations to detect drift. If unexpected changes occur, they should generate an alert and be investigated.

Connections to and from the logical data center must be secured to provide data in transit security. This may be achieved by VPNs, Transport Layer Security (TLS), or other secure transmission methods. With an increasingly remote and mobile workforce, remote access is increasingly important, and a careful logical design can help to provide a secure data center environment while also enabling a remote workforce to accomplish tasks regardless of location.

Physical Design

Physical design is the responsibility of the owner of the cloud data center. This is generally the cloud vendor or CSP. Physical design considerations are the same as for on-premises data centers, but the CSP's task is generally more complex due to the size and requirement for multitenant access.

Environmental Design

The environmental design, like the physical location of a data center, is the responsibility of the CSP or cloud vendor, with the exception of the private cloud deployment model. Environmental design primarily impacts the availability of cloud resources, such as adequate cooling necessary to keep electrical equipment running. For the cloud customer, reviewing the basic design of a vendor or CSP's environmental controls can be part of the risk analysis of the vendor. Similar to physical security controls, this review may not be performed in person, instead relying on a third-party audit of the CSP's environmental design.

Environmental design is in many cases concerned with utility services needed to keep computing equipment running, as well as providing for habitation by support staff. This includes electricity needed to power the hardware comprising the cloud, as well as lighting needed by support personnel working in the facility. Some data centers will make use of water for cooling, while others will use air handling to provide cooling for electronics. These are also required by human occupants of the building, and guarding against leaks is a primary concern where water is needed for human occupancy but could cause damage to electrical equipment.

Risk Assessment

The process of risk management is fundamental to information security, since the entire practice involves mitigating and managing risks to data and information systems. Cloud-based systems can pose a challenge to risk management for a variety of reasons. Many organizations assume that the CSP is in charge of all security concerns and that customers have no responsibility.

This is untrue, as demonstrated by the explicit shared responsibility guidance published by most CSPs—they are responsible for some things like physical and environmental, but the customer ultimately owns the risk to their data and must manage it accordingly. Doing so can pose another challenge, as cloud providers are third-party vendors to most organizations. Assessing and mitigating risks posed by third parties requires modified risk management practices, and the customer must also be proactive in addressing their assignments under the shared responsibility model.

Cloud Vulnerabilities, Threats, and Attacks

The primary vulnerability in the cloud is that it is an Internet-based model. Anyone with access to the Internet has the potential to attack your CSP, your cloud provider, or you. Even organizations that deploy their own connectivity to a cloud provider could be at risk if the CSP's public-facing infrastructure comes under attack. A private cloud is unlikely to face such an attack, but this protection comes at higher cost than public cloud services.

Any attack on your CSP or cloud vendor may be unrelated to you as an organization, so typical threats considered when assessing risks may not be adequate to address the threat model of a cloud environment. Threat actors may be targeting the CSP or another tenant of the CSP, or the CSP might be vulnerable to location-based threats due to weather or geological conditions in another part of the world. Customers of the CSP may simply be collateral damage; a denial-of-service attack against the CSP becomes an attack against all the cloud customers as well.

Risks can come from the other tenants as well. If protections keeping customer data separate fail, your data may be exposed to another tenant, who could be a competitor or bad actor. Even if the data exposed is not used maliciously, it is still a breach and may trigger legal or regulatory issues. Encryption is the best protection, with customer-managed keys that make any exposed data worthless to outsiders. The customer may also consider not storing their most sensitive data in the cloud, and a hybrid cloud approach with data stored in public cloud platforms can be an effective mitigation.

There can be an additional risk from the cloud vendor. Employees of cloud vendors have been known to exfiltrate customer data for their own purposes. Contractual language may provide the only remedy should this occur, though CSPs do design their services to minimize these risks—otherwise no customers would trust them with sensitive data or systems. Prevention becomes the best defense. As with other tenants, encryption with the customer managing their own keys (separate from the cloud) prevents data exposure.

The Cloud Security Alliance publishes the “Egregious 11: Top Threats to Cloud Computing.” This is a list of common threats and risks to cloud computing, as well as recommended mitigation strategies that cloud customers can implement. The full list is available here: cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-egregious-eleven.

Risk Mitigation Strategies

There are several approaches to risk mitigation in cloud environments. The start of security is with the selection of a CSP, and a set of documented requirements and comparison of CSP offerings against those requirements is a key due diligence activity. Choosing a CSP that is incapable of meeting the organization's security and operational needs is inherently risky, so selecting a qualified CSP is an essential first step.

Once the CSP is selected, the next step is designing and architecting systems and services. Security should be considered at every step and designed in from the beginning. CSPs offer a wide range of services, so well-documented requirements can once again be useful. If encryption of data at rest is important, then the customer must choose a cloud storage offering with adequate encryption capabilities to start with and then properly configure the service to meet the organization's needs.

The next risk mitigation tool is encryption, which is an essential countermeasure for data security when, as is the case in cloud computing, data is outside the organization's control. Encryption should be enabled for all data at rest and data in motion. Most CSP offerings include encryption service; depending on the type of service, there may be some configuration action required by the customer. Data in transit must be protected using TLS, IP security (IPSec), VPNs, or another encrypted transmission method, while data at rest can often be encrypted by the CSP's storage platforms using customer-controlled keys. In addition, limiting the ingress/egress points in each cloud service can provide monitoring capabilities to ensure that data security measures are adequately applied.

Each major CSP provides the ability to manage your secure configuration, monitor changes to cloud services, and track usage. For example, AWS provides Inspector, CloudWatch, CloudTrail, and other tools to assist your management of your cloud environment. However, just like other tools, it is incumbent on the customer to properly use them for implementation and monitoring of security. If you log all system activity but never review it, then suspicious activity will go unnoticed.

Physical and Environmental Protection

The location housing the physical servers in a cloud environment must ensure adequate protection against physical threats, like natural disasters, as well as provide necessary environmental controls to ensure that systems remain operational, such as power and HVAC. These controls are usually the purview of the CSP, meaning that a third party is responsible for them, though in a community or private cloud delivery model the organization consuming cloud services may have responsibility.

The primary consideration is the site location, as it will have an impact on both physical and environmental protections. A data center along the waterfront in an area subject to regular hurricanes or flooding is likely to be routinely damaged by these threats. If possible, a less susceptible location should be chosen; otherwise, additional locations and redundant system architecture may be required. For large CSPs, this risk is easily compensated for; the globally dispersed network of data centers utilized by a modern CSP results in data centers that are unlikely to be affected by the same threats.

Once facilities are constructed, there are additional physical and environmental requirements that must be addressed. Cloud data centers share requirements with traditional colocation providers or individual data centers. These include the ability to restrict physical access at multiple points, ensuring a clean and stable power supply, adequate utilities like water and sewer, and the availability of an adequate workforce.

A cloud data center also has significant network capability requirements. All data centers require network capabilities, but a CSP typically serves more customers than other data centers. More than one ISP and redundant cabling into the facility may improve the reliability of connectivity.

The customer has no control over the physical location of a cloud data center, except for a private or community cloud where the customer is also a service provider. Customers of public clouds do have some control over where their data is stored and processed, as most CSPs offer services that can be restricted by geography. To the extent possible, the customer should review the location of cloud data centers and be aware of the cloud vendor's business continuity and disaster recovery plans, as a CSP outage will lead to a loss of system availability. The ability of the cloud vendor or CSP to respond to disasters directly affects the ability of the cloud customer to serve their customers. Ensuring that cloud applications are properly architected to be resilient against loss of a single cloud data center is also an effective control against physical and environmental risks.

System, Storage, and Communication Protection

Properly securing information systems can be a difficult task due to the sheer number of elements that make up a system. Breaking systems down into components and applying security controls at this level can make the overall task more manageable. Information systems commonly comprise processes and operational technology like servers and applications, storage media where data resides, and communication pathways used to place information into the system and retrieve it when needed.

One source for controls is NIST Special Publication 800-53, “Security and Privacy Controls or Information Systems and Organizations,” which contains a family of controls specific to systems and communications. Section 3.18, “System and Communications Protection (SC),” is a comprehensive set of guidelines for addressing system- and communications-specific risks, and similar controls can be found in ISO and other control frameworks. The NIST SC control family includes 51 specific controls, including the following:

• Policy and Procedures: This is a primary control, as policies and procedures serve as a foundation and guide to other security activities. They establish requirements for system protection, and define the purpose, scope, roles, and responsibilities needed to achieve it.
• Separation of System and User Functionality: This is a core control. Separation of duties is a fundamental security principle, and separating system administration functions from regular end user functions can prevent users from altering and misconfiguring systems and communication processes.
• Security Function Isolation: Separating security-specific functions from other roles is another example of separation of duties. Security functions can include configuring data security controls like encryption and logging configuration, as well as separate hardware-based security modules for high-security systems.
• Denial-of-Service Protection: A DOS attack is a threat to all information systems and specifically those that rely on network connectivity as cloud services do. Preventing a DOS attack involves dealing with bandwidth and capacity issues and detecting attacks. Most CSPs offer DOS mitigation as a service, and there are also dedicated providers like Akamai and Cloudflare.
• Boundary Protection: This control deals with both ingress and egress protections. This includes preventing malicious traffic from entering the network, as well as preventing malicious traffic from leaving your network, protecting against data loss (exfiltration), and applying protection mechanisms like routers, gateways, or firewalls to isolate sensitive system components.
• Cryptographic Key Establishment and Management: Cryptography provides a number of security functions including confidentiality, integrity, and nonrepudiation. Ensuring that keys are securely generated, stored, distributed, and destroyed is crucial, especially in cloud environments where physical control is lost over storage media and information system components.

Cloud computing has a shared security model, and which controls are the responsibility of the CSP and which are the responsibility of the customer should be carefully reviewed and understood. For example, the CSP should have a strategy to maintain service availability in the event of a DOS attack, but organizations can also choose services or architect applications to utilize an alternate cloud region or CSP if one is not available.

The cloud customer can also implement controls for system and communication protection, like redundant connectivity in the event of a network outage. This can be achieved via multiple ISPs serving an office building, or users might be assigned cellular hot spots that can be used when wired communications are unavailable. In addition to availability considerations, data confidentiality and integrity in transit must be addressed. Encryption tools like TLS or a VPN can be used to provide confidentiality. Hashing can be implemented to detect unintentional data modifications, and additional security measures like digital signatures or hash-based message authentication code (HMAC) can be used to detect intentional tampering.

Protection of business data remains a critical issue, and since data spends a significant amount of time on storage media, this is a crucial area of focus. Encryption is, once again, a primary method of providing security for data at rest and is also a key area of shared responsibility. The CSP is responsible for maintaining adequate hardware security as well as configuring storage media to utilize encryption.

Cloud customers must choose and configure storage solutions to meet their needs, such as disabling public access to cloud storage. For added protection, client-controlled encryption may be used, and this requires the customer to securely provision, store, and manage encryption keys. Public cloud storage may be inappropriate for very high-security systems or highly sensitive data, so architecting a hybrid cloud with private data storage can be a viable option.

Identification, Authentication, and Authorization in Cloud Environments

Organizations with existing IAM solutions may choose to extend those solutions to newly acquired cloud systems. Organizations may also choose to acquire a SaaS IAM, sometimes known as identity as a service (IDaaS), and this is appropriate for organizations making a clean start with cloud computing services rather than migrating. This is a business decision that must account for existing technology, future growth, and the availability of adequate solutions that meet the organization's needs.

Some CSPs offer their own IAM solution that integrates with other services offered by the CSP. This includes AWS IAM for AWS cloud environments, and Azure AD in the Microsoft Azure cloud. Use of these solutions is simple if all cloud services are running in the respective CSP's environment, but they may be less optimized for other services. The decision to use such an IAM should balance the benefits of efficiency with potential risks like vendor lock-in, single point of failure if all critical services are in the same CSP, and the security capabilities of the CSP's IAM solution.

IAM practices can be generally described by the acronym IAAA, which stands for Identification, Authentication, Authorization, and Accountability. IAM systems should provide capabilities in each of these areas, and some cloud-specific considerations for each are as follows:

• Identification: Users assert an identity by providing something unique, such as a username or employee ID number. An organization with different IAM solutions for cloud and on-premises environments may face difficulty with visibility into user activity but may also encounter compatibility issues between legacy on-premises IAM and cloud environments. Modern IDaaS tools were built with broad compatibility in mind, and they may provide the best solution to bridge on-premises and cloud.
• Authentication: Users must prove the identity they assert, typically by providing authentication material like a password, PIN, or biometric scan. Common authentication material like passwords can be managed with an IAM solution, and additional security options like multifactor authentication (MFA) should be considered where additional security is required. IDaaS providers offer MFA solutions like smartphone apps that generate MFA codes from Microsoft, Okta, and Google.
• Authorization: Users who are successfully identified and authenticated are granted access to the resources for which they are authorized. Managing authorization across cloud systems can be challenging as different clouds will implement different permission models and require unique administration. For example, an organization that utilizes Google Workspace for collaboration, Dropbox for file sharing, and Salesforce for customer management will need to administer user authorization in three separate tools. Solutions like a cloud access security broker (CASB) can be implemented to centralize this control and provide a meta later for administering user access that is automatically configured on various target services by the CASB.
• Accountability: Users who take action on a system are held accountable for following policies and procedures. Accountability is typically enforced with adequate logging and monitoring of system activity, which is covered in a later section on audit mechanisms.

In any IAM deployment, user education is important. End users often take actions that can weaken IAM controls, such as reusing or sharing passwords. An employee may use the same username and password on all work-based systems. If a vendor or CSP system is compromised, then other corporate systems will be similarly compromised since attackers have valid access credentials. The cloud vendor may not notify you of a compromise of the IAM for an extended period of time, if they are even aware of a compromise. This puts your business systems at further risk.

Cloud applications and platforms are, by definition, accessible from anywhere. While this supports a globally distributed workforce, it can also make identifying suspicious user behavior more challenging. In a legacy environment all users access an application hosted in a data center from their workstations in an organization-controlled facility, but a cloud-based SaaS application can have users logging in from various countries as they travel. This makes it more difficult to identify potentially malicious behavior, since a user logging in from a different country is no longer inherently suspicious activity.

More flexible authentication capabilities provide one answer to these challenges. For example, users who log in every day from the same IP address and browser are likely authentic, correctly authorized users. By contrast, a user who logs in from Argentina one day, China the next day, and Canada the day after could be a traveling salesperson, or it could indicate a user whose credentials have been stolen, and attackers are attempting to use the stolen credentials from various countries. Conditional authentication policies, such as requiring MFA when a user logs in from a different country or workstation, are a common feature of cloud computing platforms. They strike a balance between usability and security; requiring MFA at every login is an inconvenience to users, but it is warranted for users whose activity is highly irregular.

Audit Mechanisms

It can be more difficult to audit systems and the processes of a CSP, just as with any vendor that is outside the organization's direct control. A customer will not have broad access to the physical security of cloud data centers, vendor networks, or activity logs maintained by the CSP. This is due to both logistics and the presence of other tenants. Most CSPs have a number of data centers that are geographically dispersed and hundreds or thousands of customers. The logistics of customers performing physical security control audits make the practice virtually impossible, and similar challenges exist when performing system or network audits.

Broad access to the vendor network is also a security risk. If you have access to the network, you may intercept privileged information belonging to another customer, violating the boundaries needed in a multitenant environment. If the CSP provides one organization with access to data that violates these boundaries, other organizations will trust the CSP less with their sensitive data.

Some cloud services provide access to log data, some do not provide access, and many provide limited access to organization-specific data that does not violate the confidentiality of other tenants. These limited logs can be useful but may not provide all the needed details if a security incident occurs. Different service models will provide different levels of logging ability; for example, IaaS allows the customer to build virtually all the logging infrastructure they need, while SaaS logs may only provide information about user actions and customer-specific application details like patch deployments.

Business Continuity/Disaster Recovery Strategy

Business continuity planning is concerned with ensuring that the organization is able to continue functioning after an adverse event has occurred. The result of the planning process is a business continuity plan (BCP), sometimes called a continuity of operations plan (COOP). This is a proactive risk mitigation strategy, as the BCP contains likely scenarios that could affect the organization and provides guidance on how the organization should respond.

Not all the processes an organization executes will be covered in a BCP or COOP. Some processes are essential to the organization's continued functioning, such as the ability to handle payments or communicate critical information to employees, while others can be considered “nice to have,” such as internal communications about company social events. The business impact assessment (BIA) is used to determine which processes are critical and which are not. The impact of specific systems and processes is measured by the BIA, and any that are deemed critical to the organization's functioning must be prioritized in an emergency situation.

For example, many financial services firms are required to plan for pandemic readiness assuming that some percentage of staff are not available due to illness and that even healthy staff may be restricted from working in the office to contain the pandemic spread. In a scenario like this, the organization must have adequate remote work capabilities, such as a VPN, and necessary supplies for workers to utilize when working remotely. This ensures that critical functions of the firm, such as handling financial transactions, can continue even with reduced staffing levels. Cloud services can be easily integrated into this plan, as the broad network accessibility they provide means that workers can easily log in and work from any location.

Other common BCP scenarios include risks like natural disasters, loss of utilities, and civil unrest or war. If needed, the BCP is activated by formal declaration of a disaster, and the organization switches into contingency operation mode following the guidelines established in the BCP. The goal of the BCP is to maintain critical business processes and operations, which may involve alternate work locations, alternative business processes, or even the use of cloud environments in place of on-premises data centers if those facilities are unusable.

While a BCP keeps business operations going after a disaster, the DRP works on returning business operations to normal. Not all incidents will require the activation of both plans. A major ISP failure might activate the BCP and send workers to an alternate building while the ISP restores the connectivity. In contrast, a natural disaster like a tornado that destroys an office or data center will require activation of both the BCP and DRP.

If a tornado renders a primary data center unusable, procedures in the BCP are used to handle shifting to an alternate processing facility, such as temporary use of cloud computing. The DRP is activated to handle the process of cleaning up and restoring or replacing the destroyed facility. DRP operations are concluded when the infrastructure and facilities are returned to their normal, operational state; the BCP operations are concluded when the organization's processes return to the pre-incident state using the restored or rebuilt infrastructure.

A cloud data center that is affected by a natural disaster will likely activate multiple BCPs and DRPs. The cloud provider will obviously activate both plans to deal with the interruption to their service; one key element of the BCP is communicating incident status to relevant parties. In this case, the CSP must communicate to all customers impacted by the incident. In turn, the customers may activate their BCPs or DRPs as needed to handle the interruption to their services, such as migrating applications to another cloud region or possibly even another CSP for the duration of the outage.

The cloud supports the BCP/DRP strategy. The high availability of cloud services provides strong business continuity and can serve as a core part of an organization's BCP strategy. In effect, the cloud allows the business to continue regardless of disasters affecting the customer's business facilities. The high availability of cloud services also impacts DRP strategy, as the cloud can provide resilient services at cost-effective price points. Customers may focus more on resilient services that survive a disaster rather than processes to recover from disasters. As always when discussing security, BC and DR strategies should always prioritize the life, health, and safety of humans over systems and data.

The customer is responsible for determining how to recover in the case of a disaster and may choose to implement backups, or utilize multiple availability zones, load balancers, or other techniques to provide disaster recovery and resilience. A CSP can help support recovery objectives by not allowing a data center to have two availability zones. Otherwise, if you are using two zones and they are in the same data center, a single disaster can affect both availability zones. CSPs can also provide monitoring that can be used as an early warning system, such as a spike in traffic or utility issue that could lead to an incident. This gives any customers the ability to take preventative actions like shifting to other availability zones or activating alternate processes.

Business Requirements

Business-critical systems require more recoverability than is often possible with local resources and corporate data centers. Designing high availability or resilient systems in such an environment requires significant resources and is cost-prohibitive for many organizations. Cloud computing provides options to support high availability, scalable computing, and reliable data retention and data storage at significantly reduced cost.

Although it is cheaper to build highly resilient systems in the cloud, there are still costs associated with such an architecture. To justify system and architecture resiliency decisions, there are three important metrics that the organization should consider. These metrics are outlined in the following sections, and include RTO, or how long are you down; RPO, or how much data may you lose; and recovery service level (RSL), which measures how much computing power (0 to 100 percent) is needed for production systems during a disaster. This does not usually include compute needs for development, test, or other environments, as these are usually nonessential environments during a disaster.

Creation, Implementation, and Testing of Plan

There are three parts to any successful BCP/DRP, and each is vital to the success of the organization. These include the creation, implementation, and ongoing maintenance and testing of the plans.

Because of their inherent differences, BCPs require different roles and responsibilities within the business. Although frequently combined and considered a single practice area, the two plans do require different sets of resources and focus on different activities. If the business does not continue to function, which is the goal of the BCP, there is no reason to have a DRP as there will be nothing to return to normal.

The plans should each be developed with knowledge of the other, including key integration points, joint responsibilities between the BC and DR teams in the event of a disaster, and definitions of both common and unique resources. These plans will include many of the same members of the workforce and serve the same ultimate goal of helping the organization continue to function during and after a disaster, but they are separate plans.