VMs

VMs are the most common compute mechanism in cloud computing environments. VMs emulate the functionality of physical hardware and allow cloud customers to run operating systems (OS) in a virtualized environment. In addition to the OS (and the OS kernel), your organization may include middleware or custom application code in your VM deployments.

Because virtual machines can include lots of different components, you need to pay close attention to how you asset manage, configuration manage, and vulnerability manage your VMs. Most large cloud platforms provide resources to support VM management, but it is ultimately the customer's responsibility to manage their Virtual Machine instances and the data processed within them.

One of the powerful features of cloud environments is the ability to scale resources, including VMs, up and down very quickly. While this ability is incredibly helpful to manage fluctuating resource needs, it can make asset management a nightmare. Agent-based solutions can be a big help in managing and securing your VM inventory.

Containers

Containers take the virtualization of VMs to the next step and package only the necessary code, configurations, and resources needed to run a particular application. Unlike VMs, containers don't run an entire OS — instead, they use the kernel of the VM or OS that they’re hosted on. In short: VMs provide virtual environments that allow organizations to run their applications, while containers isolate an application from its environment and allow the application to be run in multiple different environments. Containers are an increasingly popular technology, especially for multicloud or hybrid deployments.

You may hear the term container and think of storage because … well, because containers in the real world are used to store things. Remember, however, that this compute technology is actually used to run applications and process information.

Because containers allow you to scale up and down resources even more rapidly than VMs, asset management and configuration management are even bigger security concern for containers. Most container technologies come with support for managing your container deployment lifecycle, but it's up to you to ensure that you aren't spinning up containers that haven't been properly patched or managed.

Reservations, limits, and shares

The use of reservations, limits, and shares allow you to allocate a single host’s compute resources.

A reservation guarantees that a cloud customer has access to a minimum amount of cloud compute resources, either CPU or RAM. Much like a restaurant reservation ensures that you have a seat when you need it (except Washington, D.C. restaurants that still make you wait 30 minutes), compute reservations are used to make sure that your VMs have the right amount of computing and processing power when they need it. Reservations are an important feature in cloud environments because they can help protect customers against Denial of Service due to other resource-intensive tenants.

A limit acts just the opposite of a reservation and sets a maximum amount of cloud compute resources that can be used. In cloud environments, limits can be set either for a VM or for a customer’s compute utilization as a whole. Limits can help customers ensure that they don’t use more resources than they’ve budgeted for, and they can also help ensure that a single cloud tenant doesn’t use a tremendous amount of resources at the harm of other tenants. Limits may be configured as fixed (for example, “use no more than 16GB of RAM”), but I’ve most often seen dynamic limits used in practice; dynamic limits allow customers to temporarily use additional resources depending on given circumstances or requirements being met.

Limits are particularly useful in development environments, where cost may supersede any other consideration. Use limits in production environments very carefully to avoid potential Denial of Service.

The concept of a share is used to mediate resource allocation contentions. Resource contention is just a fancy way of saying that there are too many requests and not enough resources available to supply all those requests. When resource contention occurs, share values are used to allocate resources to all tenants assigned a share value. Tenants with a higher share value receive a larger portion of available resources during this period.

You should understand what resource contention is for your exam and know that shares are one way to negotiate and remediate it. However, you should also know that this occurrence is fairly uncommon in most large, mature cloud providers. Two of the key cloud computing characteristics, rapid elasticity and resource pooling (see Chapter 3), are focused on ensuring that large amounts of customers are able to share cloud resources with minimal disruption. CSPs with routine resource contention are very likely not built at a scale large enough for their customer base.

Volume storage

For volume storage, the hypervisor takes a chunk of the physical storage infrastructure and virtually assigns it to a VM. A logical unit number (LUN) is a unique identifier that’s used to label each individual chunk. A LUN can represent a single disk, a partition of a disk, or an array of disks, depending on how much storage space a cloud tenant provisions. In any case, LUNs are virtually mounted to the virtual machine for use as virtualized storage.

Volume storage is great when you need a fixed chunk of storage for with a filesystem, but keep in mind that volume storage can be used only with that filesystem and at runtime.

Object storage

Object storage is a bit newer of a concept than volume storage, and it gives developers additional options for storing and retrieving unstructured data. Instead of files being broken down into blocks, LUNs, or volumes, object storage deals with whole files that are accessed via network call. Object storage is ideal for images, documents, webpages, and any other data without a specific schema or structure.

Another key benefit of object storage is that cloud providers are able to charge for the exact amount of data you use (in other words: the total size of your objects is what you pay for), whereas with volume storage you’re likely to have volumes with more space allocated than you’re actually using at any given time. (Think of volume storage as having a 256GB hard drive with only 200GB being used.)

Location, location, location!

Determining whether a data center is secure begins with its geographic location. A secure data center design should consider the following:

• Geographical features of the area (tall trees, for example, are a wonderful and free barrier)
• Risk of natural disasters and weather events
• Geopolitical risk (it’s worth noting if you’re building in a warzone, for example)
• Access to and costs of telecommunications infrastructure
• Availability of utilities and other essential resources
• Labor costs and availability

While you can prevent or mitigate some of these concerns, it’s best to avoid any unnecessary risk when building a multibillion dollar facility to store your customers’ sensitive information.

Buildings and structures

After you select the ideal location for your shiny new building, it’s important that you design the actual building structure to reduce access control and other physical risks. Some important considerations include

• Materials and thickness of the building’s walls
• Number of ingress and egress points
• Type of perimeter fencing
• Types of locks and alarms used on external and internal doors
• Redundant electrical and telecommunications suppliers

The preceding list is just a start, but can help you begin to focus your attention on the most important building security concerns. A Building Management System (BMS) is a hardware and software control system that is used to control and monitor a building’s electrical, mechanical, and HVAC systems. A BMS is an important part of the physical design of any data center and helps data center personnel monitor plumbing, power, lighting, ventilation, fire suppression, and other critical building systems.

Physical security monitoring

It may seem obvious, but one of the most important aspects of physical security is ensuring that only authorized people can access the building and its critical areas. A secure data center should have a list of all authorized personnel and monitor their access to building resources. Visitors, such as vendors, should be appropriately verified, logged, and monitored as well.

Don’t forget about tried and true security measures, such as video surveillance. All building entrances and exits should be monitored and recorded, and all internal doors to controlled areas (like areas with servers, HVAC systems, and so on) should be actively monitored by CCTV. As great as video surveillance is, it would be pretty useless without security staff on hand to respond to any alerts or suspicious activities; secure data centers have round-the-clock security patrols and personnel standing by to respond to potential threats.

Physical testing and auditing

No matter how great you design your physical controls, it is essential that you have a policy in place to periodically test them. Conduct physical penetration tests at least annually to ensure the ongoing effectiveness of your physical security mechanisms. In addition to testing you should do on your own, external audits (SOC, PCI, FedRAMP, and others) very often require that cloud data centers be physically audited by licensed or accredited auditors.

Organizational risks

Organizational risks are inherently present whenever an organization outsources services to an external party — similar to third party or vendor risk. These risks may potentially impact business processes, existing company policies, or anything else that a company views as important.

A few noteworthy organizational risks to be mindful of are

• Reduced visibility and control: Customers who host and maintain their own infrastructure maintain complete control over their security (for better or for worse). If you run your own data center, you can change what you want when you want, and you have full visibility into your systems and services. Moving to the cloud means that you give up some of that control to the CSP. Customers must create a mature governance model prior to migrating to the cloud and find ways to mitigate or accept any residual risks related to control. Potential mitigations include SLA and contractual terms, as well as full utilization of monitoring tools available on your selected cloud provider.
• Staffing and operational challenges: Cloud migration can introduce challenges for existing IT staff who are not properly trained on cloud computing and security. Managing and operating a cloud environment may require substantial training for existing staff or even require entirely new personnel to be hired. The skills gap that may exist creates the potential for security risks that go unnoticed or unmanaged. Cloud customers must proactively evaluate their current staff and identify training and/or hiring needs prior to cloud migration.
• Vendor lock-in: Vendor lock-in becomes an issue when an organization has made significant investments in a cloud provider, but wants to move its data from that provider to another. The organization faces risks associated with greater time, effort, and cost to make the switch than planned. Vendor lock-in risk increases when cloud providers use nonstandard formats and APIs or lots of proprietary tools. Cloud customers can mitigate vendor lock-in risk by carefully evaluating potential CSPs for interoperability and open-source support.
• Financial management: Most organizations are accustomed to setting a strictly fixed IT budget every year; exceeding that budget usually means the CIO has some explaining to do. Even more confusing, though, some organizations actually have a use or lose policy that means if you fail to use all your IT funds this year, you can expect a lower budget next year. Moving to the cloud, where customers are billed for exactly what they use, can be a challenge for financial planning. Cloud utilization (and costs) can scale up and down on a monthly basis, rather than having a fairly consistent utilization from running your own data center. Further, on-demand self-service means that cloud customers must ensure that their users aren’t abusing the cloud services at their disposal.

Compliance and legal risks

Customers in highly regulated industries, such as financial services and healthcare, need to be concerned with data security and privacy regulations, like PCI DSS and HIPAA. When moving to the cloud, it is still the customer’s responsibility to ensure that their data meets those standards and regulations, as well as any contractual commitments they’ve made to their own customers. As part of these requirements, cloud customers may be required to know the following:

• Where does their regulated data reside
• Who accesses (or may access) the data
• How is their regulated data protected

When you move sensitive data to the cloud, you are relying on the CSP to protect it and help you meet your compliance obligations. Compliance and legal obligations are again where the Shared Responsibility Model comes into play, and cloud customers should look to their cloud provider for details on how they support compliance. By understanding a CSP’s role in compliance, customers can identify what responsibility they have to ensure their data is compliant with relevant regulations.

When moving to the cloud, you transfer some responsibility for protecting your infrastructure and systems. However, you’re not transferring liability. Unless your contract with the CSP states otherwise, you’re still legally responsible for ensuring compliance with legal regulations and requirements that impact your data.

Compliance is a huge point of contention for cloud customers, and it’s insanely important that you, as a customer, perform your due diligence when moving to the cloud. Some CSPs offer customers a document called a Customer Responsibility Matrix (CRM), which delineates the CSP’s responsibility from the customer’s responsibility for each requirement within a given regulation. CRMs are formally required for FedRAMP authorized CSPs, but I’ve seen them available to support HIPAA and other regulations as well.

Management plane compromise

The management plane is probably the most valuable attack target and the highest source of risk in a cloud environment. As a single interface with consolidated access to all your systems and resources, a management plane compromise can affect your entire cloud environment.

Because management planes are made available to customers through Internet-facing APIs, they’re widely exposed to attackers for exploitation. Malicious actors look for weak APIs and can exploit vulnerabilities to gain access to an organization’s cloud systems and data.

CSPs are responsible for securing their APIs — with special attention being given to management plane APIs. Cloud customers hold responsibility for ensuring that they use strong credentials and secure channels when accessing their cloud provider’s management console.

Incomplete data deletion and sanitization

When cloud customers delete their data, they’re relying on the cloud service provider to actually remove all traces of that data from the environment. Cloud customers have reduced visibility into where all components of their data resides, and they have very little ability to verify that all data has been securely deleted upon request.

Incomplete data deletion and sanitization can leave portions of a customer’s data available and potentially exposed to other CSPs tenants who share the same infrastructure. This potential data leakage is particularly concerning for customers managing sensitive information like PII, PHI, and cardholder data.

Whereas an organization operating their own data center is able to physically shred, incinerate, or pulverize storage media to ensure its destruction, cloud customers do not have this level of control. Instead, customers rely on SLAs, contracts, and data agreements in which CSPs commit to certain processes and timelines for secure data deletion. Customers must be mindful that data deletion and sanitization processes and terms differs from one CSP to another and must ensure that their selected CSP provides terms that meet the organization’s business needs, regulatory requirements, and legal commitments.

Insecure multitenancy

Multitenancy is a core property of public cloud, and it allows large CSPs to provide resources and services to thousands of customers in a scalable fashion. This architecture requires the cloud provider to use isolation controls to physically or logically separate each tenant from other tenants in the environment. Risks exist when these controls either do not exist or fail to function as intended.

Without proper separation between cloud tenants, an attacker can leverage one tenant’s resources to compromise another tenant’s environment. This compromise can include unauthorized access to data, Denial of Service, or other tenant-to-tenant attacks.

Securing multitenant infrastructures and ensuring effective separation between organizations is entirely the responsibility of the CSP. Logical controls, like strong encryption, are minimally required. In some cases, customers may require actual physical separation from other tenants and may request it through products like AWS Dedicated Hosts and Google’s sole-tenant nodes.

Resource exhaustion

Resource exhaustion is another risk related to multitenancy and resource pooling (see Chapter 3). Resource exhaustion presents itself when an organization is denied resources because the resources are being completely consumed by another tenant or tenants; resource exhaustion may be malicious or not. If one or more tenant within the shared environment provisions a large amount of CPU, RAM, or network bandwidth, it can leave other organizations lacking sufficient resources to process their workloads. Reservations, shares, and limits can be used to mitigate this risk.

Network, host, and application vulnerabilities

As with any computing system, cloud environments are made up of hardware and software that may contain security vulnerabilities. In terms of cloud infrastructure, CSPs are responsible for routine scanning and patching of hosts, network devices, databases and applications under their control.

Unpatched vulnerabilities present a risk to organizations and their data; unlike in traditional data centers, customers may not be aware of this risk because of the lack of insight they have into the CSP’s vulnerability management practices.

Chapter 6 provides examples of common cloud vulnerabilities.

Architectural risks

Architectural risks are directly related to the abstraction between physical hardware and virtualized systems. This abstraction creates an added layer of complexity that presents risks to virtual machines stored or running in a cloud environment.

Per CSA, some key architectural risks include

• Lack of visibility into and control over virtual networks: Virtualized traffic is not easily monitored with existing physical network monitoring tools.
• Resource exhaustion: This topic is discussed in the “Resource exhaustion” section of this chapter.
• Workloads of different trust levels on the same host: This risk is due to multitenancy and resource pooling. If sensitive data shares resources with less sensitive information, appropriate controls must exist to separate and appropriately categorize and secure each classification of data.
• Risk due to CSP APIs: This topic is discussed in the “Management plane compromise” section of this chapter.

Hypervisor software risks

As an essential component of virtualized systems, any vulnerabilities that exist within the hypervisor presents significant risk.

Per the CSA whitepaper, some key hypervisor risks include

• Hypervisor security: If not managed throughout its entire lifecycle, the hypervisor may contain exploitable vulnerabilities.
• Unauthorized access to the hypervisor: Because it’s the Holy Grail of virtualization, weak access control mechanisms present immense risk to cloud customers and their data.
• Account or service hijacking through the management portal: This topic is discussed in the “Management plane compromise” section of this chapter.

Configuration risks

Virtualization significantly speeds up the creation of computing environments. Without careful attention to secure configurations, large environments can be developed quickly and without proper security controls in place.

According to the CSA whitepaper, configuration risks include, but are not limited to

• VM sprawl: VM sprawl is the uncontrolled growth of VMs to the point where the cloud administrator can no longer effectively manage and secure them.
• Sensitive data within a VM: Because VMs are just files that can be moved from place to place, lack of strong security controls (like encryption and access control) poses a risk to any sensitive data contained within the VM.
• Security of offline and dormant VMs: This topic is discussed in the “Virtualization” section of this chapter.

While these risks are largely centered around virtual machines and the hypervisor, you should keep in mind that containers come with related virtualization risks. For example, a container’s underlying host OS may be compromised and pose risk to data within that container (or within the broader containerized environment)

Vulnerability and configuration management

Software vulnerabilities in the management plane and hypervisor are particularly concerning because of what we know about virtualization. In short, a vulnerability in one of these components may not only impact one customer, but potentially all tenants that share the underlying physical systems. For example, in a breakout attack, a hypervisor security flaw might allow one guest to break out of their VM and manipulate the hypervisor in order to gain access to other tenants.

To prevent breakout attacks and other software exploits, you must ensure that virtualization systems are hardened in accordance with vendor security guidelines and best practice recommendations. These best practices include disabling unnecessary services and applications that can increase the attack surface of your systems and also building comprehensive processes and controls for vulnerability remediation and patch management. You should automate as much of these processes as possible.

Pulling asset inventory information from your cloud APIs can help automate your vulnerability management and can ensure that you’re scanning and remediating your entire cloud environment.

The terms vulnerability management and patch management are sometimes used interchangeably, but they are not the same. Patch management is the part of configuration management that includes all processes for finding, testing, and applying software patches (or code changes) to your systems. Vulnerability management is the process of identifying, classifying, and fixing vulnerabilities that exist within your system. While some software patches may indeed result in vulnerabilities being fixed, many are related to product stability or other nonvulnerability related areas. Further, not all vulnerabilities can be fixed or mitigated by applying a patch. For example, some software weaknesses require disabling services or other manual configuration changes.

Access management

When it comes to access privileges, less is more — especially when controlling access to the hypervisor and management plane. Role-based access control (RBAC) should be enforced, and ideally only you (if you’re the CCSP responsible for your cloud environment), your cloud administrator, and very few others should have access to your CSP’s management console. The principle of least privilege means that you should set tight access restrictions that prevent unauthorized parties from modifying VM settings and accessing your sensitive resources and data.

Even with strict access controls in place, it’s important that you log, monitor, and audit the effectiveness of these controls. Any administrative access to virtualization systems should be tracked in very detailed logs that identify the following, at a minimum:

• Whether the access is successful or denied (multiple access denials is an indicator of foul play)
• Who originates the access (username, IP address, and so on)
• Where they are located (geolocation data can help identify misuse, especially if your management systems are generally accessed from specific locations)
• What access path was used (CLI or web console, for example)
• What privileged actions are taken (especially important to identify any pivots from one system to another)

Logging the proper details is a crucial control for detecting security compromises; preserving and analyzing those logs is just as important. Logs should be securely transported to and maintained on a separate system, where they are encrypted and tightly access controlled. Keeping your logs on a system that is separate from the systems being monitored adds a layer of protection against the logs being deleted or manipulated if the virtualization systems themselves are compromised.

Network management

Because network intrusions can affect hypervisors and management planes, proper network design is a fundamental requirement to protect virtualization systems. Secure network management includes suitable implementation and configuration of firewalls, IDS/IPS, and other security controls that prevent and detect anomalous or malicious network activity.

Connections to the management plane should occur over encrypted network sessions, for both cloud providers and cloud customers. Some regulations even mandate that specific encryption protocols or mechanisms be used for these connections. For example, US government agencies are required to use FIPS 140-2 validated cryptographic modules when connecting to the cloud, per FedRAMP requirements. I cover FedRAMP and FIPS 140-2 (and FIPS 140-3) in Chapter 3.

In the traditional data center model, network perimeters are pretty easily defined. You draw an imaginary line around your important internal stuff, and that’s your internal network. Another line drawn identifies the demilitarized zone (DMZ), which contains your perimeter devices that connect to the scary Internet. You may have some other zones in there, but the architecture at its core is this simple. In virtualized environments, the allocation of risk among systems differs from on-prem environments. When virtualization systems are not sufficiently protected by other controls, you can use additional trust zones as an added layer of protection.

I discuss the topic of zero trust in the “Logical design” section of this chapter. While zero trust is an emerging security concept that provides a great deal of protections for virtualized environments, the concept of trust zones has been around for a long time and must be understood for the CCSP exam.

A trust zone is a network segment that includes systems and assets that share the same level of trust. The DMZ and internal network in the preceding paragraph are common examples of trust zones. Network traffic within a trust zone can move freely, with few limitations. However, traffic into and out of a trust zone is closely monitored and tightly restricted. There are many strategies for developing trust zones, and it’s up to each CSP to identify the strategy that works best for their cloud. Figure 5-6 depicts one common example of a trust zone architecture that includes a web zone, data zone, and management zone. Use trust zones allows a cloud provider to plan security controls for each zone that meet the individual security needs of the systems in that particular zone.

As the preceding example shows, keeping your data zone (which may include customer VMs, databases, and so on) separate from your management zone (which includes the hypervisor and management plane) is a great idea. This segmentation helps ensure that a compromised customer VM is not able to affect other systems on the shared infrastructure.

When connecting into a management zone from another zone, you should connect from a bastion (or jump) host. A bastion host is a system that runs outside your security zone that is generally designed to serve a single-purpose (like connecting to the management zone) and has been extremely hardened for enhanced security. A bastion host might reside in your DMZ and be used to allow administrators access to the management zone via virtual private network (VPN). Because they are often the single connection into the highly sensitive management zone, bastion hosts must be stripped down of unnecessary functionality, protected with multifactor authentication, and monitored with auditing tools.

Identification

Identification is essentially the act of giving a unique name or identifier to every entity within your environment; entities include users, servers, networking hardware, and other devices — anything that needs to be granted some level of permission to resources needs to be identified. A username is the most basic form of identification.

Just about every organization has an existing identity system or service, with Microsoft Active Directory being by far the most common in large organizations. Many smaller companies, academic institutions, and nonprofits choose open source identity standards instead of proprietary ones like Active Directory. Because large cloud providers must appeal to the masses, open standards like OpenID and OAuth have become the standards for cloud identity management.

You should be familiar with the OpenID and OAuth standards for your exam, and understand what they’re used for at a high level. The nitty-gritty details are outside the scope of this book, but are worth investigating further.

One thing customers don’t want is to be forced to manage two (or more) separate identity systems when they move to the cloud. Federation is the process of linking an entity’s identity across multiple separate identity management systems, like on-prem and cloud systems. Federation enables a cloud provider’s identity system to trust an organization’s existing identity profiles and attributes and use that identity information to manage access to cloud resources. Figure 5-7 shows a typical federated identity structure, where each party has its own identity provider, and each system that accepts identity information is known as a relying party. I cover federated identity in Chapter 6.

Authentication

If identification is the act of uniquely naming an entity, authentication is the process of confirming that an entity is who they say they are. The password that is associated with your username is the most common mechanism used for authentication. Your password is something that only you should know (ask Netflix), which gives an authentication system reasonable confidence that it can confirm your identity when you enter it. Multifactor authentication (MFA) enforces stronger validation of a user’s identity, by requiring more than just a password (like a badge or fingerprint, for example). Using MFA is advisable whenever feasible, but should be considered a strict requirement for all privileged and high-risk access.

Authorization

Once your unique identity has been established and your credentials have been used to validate your identity, authorization is the process by which appropriate access privileges are granted. The relying party receives information about the entity from the identity provider and then makes the determination about what type of access to grant the entity, if any. The relying party determines this based on pre-set policies that govern which users and roles can access which resources.

You may come across tools like Okta, Onelogin, Azure Active Directory, and Duo. These (and many others) are examples of cloud-based identity management and active directory services that are growing increasingly popular.

Log collection

Log collection within a cloud environment can be a mixed experience if you don’t know what to expect. While most cloud environments provide capabilities that enhance your ability access some logs and automate log management, your mileage will vary based on your service model and other factors.

On one hand, cloud environments make it super easy for customers to locate and centrally aggregate log data for all their assets via the management plane. Some CSPs even offer dedicated services for monitoring, storing, and analyzing your log files. AWS CloudWatch Logs, for examples, centralizes your DNS logs, EC2 logs, and log data from your other cloud-based systems. So, you can see how leveraging the power of the cloud can be a plus when it comes to log collection.

On the other hand, the types of logs you have access to in cloud environments never completely match what you can get when operating your own data center. Because of virtualization, you’re not able to access hypervisor logs, which would expose too much about other tenants in the shared environment. You are largely out of luck when it comes to collecting logs for the underlying infrastructure, and the types of log data available to you decreases as you move up the service category stack (from IaaS to PaaS to SaaS). With IaaS, you’ll get all the platform- and application-level logs, as well logs for your virtual hosts (VMs) and virtual network. The PaaS service model generally has access to the same log data minus the virtual host and network logs. SaaS customers capture the least amount of log data and are usually limited to access information and logs that capture data about application usage.

When organizations migrate to the cloud, they benefit by giving up lots of the management responsibilities that come with operating a data center. Along with this benefit, cloud customers are making the decision to let go of some of the control that they may be used to. As a CCSP, it’s your job to ensure that your organization understands what they’re gaining and losing as it pertains to log collection.

Packet capture

Cloud-based packet capture faces many of the same challenges mentioned for log collection (see preceding section) and is again dependent upon the cloud service category being deployed. IaaS customers are able to conduct packet capture activities on their virtual machines, but PaaS and SaaS customers are limited to what their CSP is willing to share. As a CCSP, you must ensure that your organization understands what data is available in a given cloud and make an informed decision as to whether it meets your company’s risk tolerance and business needs.

Risks to traditional IT

Risk exists in every form of computing, traditional server model and modern cloud computing alike. Whenever a risk can potentially disrupt an organization’s ability to access their important data or conduct critical business activities, the company’s business continuity and disaster recovery plan should address it. BCDR is an important set of activities that is required to minimize the business impact during and after potential disastrous events occur.

Many risks to traditional IT infrastructures can be completely solved or at least partially mitigated by migrating to the cloud. Those risks include, but are not limited to

• Natural disaster risks, including damage from
  • Flood
  • Fire
  • Earthquake
  • Hurricane
  • Tornado
• Deliberate human risks
  • DDoS attack
  • Ransomware
  • Arson
  • Terrorist attack
  • Employee strike
• Accidental human risks
  • Fire
  • Explosion
  • Human error
• Indirect human risks
  • Equipment failures
  • Power outage
  • Telecommunication outages
  • Outage due to provider going out of business

While all these risks can potentially impact a cloud provider, the risk is substantially lower in cloud environments due to the vast nature of cloud infrastructures and the key characteristics of cloud.

Risks to cloud-based BCDR

Aside from risks that may trigger the use of a business continuity and disaster recovery plan, you must consider risks to a BCDR Plan itself. The following risks impact any BCDR Plan, including cloud-based:

• Cost and effort to maintain redundancy: Any BCDR plan requires some level of redundancy, which comes with a level of financial and operational risk. If you’re operating in a hot-hot configuration, you’ll need to ensure that both the primary and secondary sites are fully staffed, configured, and updated at all times. Maintaining this type of configuration requires that the primary and secondary locations remain in sync, which can be operationally challenging. Syncing primary and secondary locations is made easier with cloud infrastructures because the cloud allows near real-time syncing between regions, and you can have your data maintained in multiple regions automatically. This convenience does, however, come at a cost; the higher level of redundancy not only increases availability, but also your usage fees.
• Performance hit due to location change: If an outage to one cloud data center or region forces your resources to failover to another region, you can be faced with latency issues. Despite cloud infrastructures being developed and configured to run your workloads from multiple geographic regions, the way the Internet works means that the closer you are to your data, the faster you’ll be able to access it. Say that you’re a Texas-based company, your primary cloud region is in Oklahoma (very close to Texas), and your secondary region is in New York (kinda far from Texas). The latency and performance that you get when failing over to a region across the country may very well be noticeable (or even problematic, depending on the applications you’re running). This risk can impact the cloud customer’s perception of the CSP and may trickle down to affect any customers that use the cloud customer’s hosted services. You can mitigate these risks by selecting a cloud provider with multiple regions available to support your geographic needs.
• Decreased operations during/after failover: If you experience a complete outage of your primary site and must fully failover to your secondary site, you should be mindful of a couple potential risks:
  • The speed at which you recover may present a risk to your business operations. This risk is generally less of a concern for cloud environments because of rapid elasticity, but full failover and recovery is dependent upon you properly maintaining backups of data and virtual machine instances. Again, cloud can help automate much of this risk, but it is your responsibility to configure these things according to your organization’s needs.
  • If your applications contain custom code or API calls to/from external services or IP addresses, you run the risk of not maintaining proper functionality post-failover. This risk can be mitigated by ensuring primary configurations are saved and readily accessible should a BCDR event occur.

In addition to these risks, you need to consider certain risks that depend on the particular BCDR use-case. Three common BCDR use-cases leverage cloud:

• Scenario 1: Organizations use their existing IT infrastructure to run their primary workload, and have a cloud provider serve as their BCDR site. This scenario is a hybrid deployment.
  • Primary: On-premise; Secondary: CSP
  • Concerns: Cloud migration can be a complex process. If any organization procures a cloud provider strictly for BCDR purposes, they must ensure that their workloads are able to migrate to the cloud and operate seamlessly in a failover situation. Use of containers within the on-prem solution can provide added portability and help ensure compatibility when migrated.
• Scenario 2: Organizations run their infrastructure in a cloud environment, and use a separate region of the same cloud for BCDR.
  • Primary: CSP; Secondary: CSP
  • Concerns: This scenario generally comes with the least amount of risk. The organization must evaluate the CSP to ensure multiple cloud regions exist that will support their requirements. CSPs sometimes do not operate all cloud services in every region. Make sure that you select a secondary region that offers the functionality and performance that your organization needs to continue operating smoothly.
• Scenario 3: Organizations run their infrastructure in one cloud environment and use a completely separate cloud company for BCDR.
  • Primary: CSP1; Secondary: CSP2
  • Concerns: This scenario adds another potential risk, and that is the second provider’s compatibility and ability to execute as required. Depending on your service model and the types of services in use, you may have to accept minor differences in functionality during failover due to the two CSPs potentially offering different capabilities. Containers are very helpful in mitigating some of these risks in a multicloud solution.

No matter what your use-case is, BCDR is an important topic that deserves a lot of attention and planning. A full assessment of potential risks is a prerequisite to designing an appropriate BCDR plan for your organization.

Scoping and assessment

The first phase in BCDR strategy development is scoping and assessment. During this phase, your organization’s primary goal is to establish the scope of your plan, generate your complete list of BCDR requirements and objectives, and assess any known risks. To help you understand, I break each of these out to better explain each step within Scoping and Assessment.

Creating, implementing, and testing your plan

After scoping your requirements and conducting a risk assessment of your initial BCDR plan, you’re ready to create, implement, and continuously test your plan. These phases rely heavily on the research, analysis, and planning that is conducted during the first phase of BCDR strategy development.