The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004.

—ENISA

As the opening quote states, the ENISA is an agency of the European Union that focuses on cybersecurity issues. As part of this, it created the “ENISA Cloud Computing: Benefits, Risks, and Recommendations for Information Security” document to support European member states and European Union stakeholders that adopt cloud services.

The ENISA document remains largely relevant because of its high-level view of the risks and vulnerabilities associated with cloud services. However, this document was written in 2009, so some risks and documented issues have been added since its publication. Additionally, some technologies such as containers didn’t even exist at that time. I have made every effort to focus only on aspects of the ENISA that remain applicable today and items that you are likely to be tested on as part of your CCSK exam. This said, I still recommend that you have the ENISA document available during your open-book CCSK exam.

Many of these items have already been covered in previous chapters of this book. This is because the ENISA document was one of the documents used as the basis for the CSA Guidance documentation. I will, however, include information from the ENISA document that has not been previously addressed. Many of the sections are presented in a quick-hit style so that you can digest the information quickly.

Security Benefits of Cloud

After reading the previous chapters, you should understand the incredible benefits that are possible with cloud implementations. You should also understand that these benefits are possible only when they are planned and architected properly. The following list of security benefits was compiled by members of the ENISA to highlight some of the more pertinent benefits of cloud computing.

Security and the Benefits of Scale

Security measures are cheaper when they’re implemented on a larger scale. This means that, from a provider’s perspective, economies of scale apply to security. Following are some benefits of scale:

•   Multiple locations Providers have the economic resources to replicate content and services in multiple locations. This enables customers to benefit from increased levels of disaster recovery (if architected for in advance, of course).

•   Edge networks I haven’t discussed edge networks previously. Gartner defines edge computing as “a part of a distributed computing topology in which information processing is located close to the edge—where things and people produce or consume that information.” With multiple locations available, you have the potential to minimize the physical distance between your branch offices and your processing. This is particularly true when you consider content delivery networks (CDNs) and additional points of presence that may be available with a cloud provider’s offerings.

•   Improved timeliness of response In Chapter 9, you learned how incident response can be dramatically improved by using infrastructure as code, by quarantining workloads through virtual firewalls (security groups), and by using other offerings possible in the cloud. These options need to be well architected and tested often.

•   Threat management Given the economies of scale surrounding security, as well as the potential reputational damages from security incidents, CSPs will often hire specialists in security threats to provide advanced security threat detection. This ultimately leads to customers benefitting from an increased security baseline in which they operate their workloads.

Security as a Market Differentiator

For many cloud providers, security is a selling point for marketing. You will often see this through the number of compliance standards that providers obtain. Not only does increased security certifications and capability enable providers to sell to companies in various industries, but it helps them market their products as well.

Standardized Interfaces for Managed Security Services

Cloud providers can offer standardized open interfaces to managed security service (MSS) providers. This enables these service providers to resell services to their own customers.

Rapid, Smart Scaling of Resources

Providers have a vast amount of scalable compute resources available. These resources can be reallocated to address threats by filtering incoming traffic and performing other defensive measures to protect customers (such as shielding customers from distributed denial of service attacks). The ENISA documentation also points out that providers can respond in a granular fashion, without scaling all types of system resources (for example, increasing CPU, but not memory or storage). This can reduce the costs of responding to sudden (nonmalicious) peaks in demand.

Audit and Evidence Gathering

I have already covered the increased audit capability in a cloud environment in many of the previous chapters (especially Chapter 4). The ENISA document does point to log storage in a cloud environment as being a cost-effective location to store log data to support audits.

Timely, Effective, and Efficient Updates and Defaults

Immutable (Chapter 7), snapshots (Chapter 9), and infrastructure as code (Chapter 10) technologies can be used to standardize and maintain security controls across all virtual machines in an Infrastructure as a Service (IaaS) environment. Of note from the ENISA document is the following statement: “Updates can be rolled out many times more rapidly across a homogeneous platform than in traditional client-based systems that rely on the patching model.” A homogeneous platform is owned and supplied by a single vendor. This means that using the tools mentioned earlier can deliver quicker update capability than the standard patching done in your data center today.

With Platform as a Service (PaaS) and Security as a Service (SaaS), updates to the platform will likely be performed in a centralized fashion, which minimizes the time window of the vulnerability.

Audit and SLAs Force Better Risk Management

Given the volume of security certifications faced by providers, it is highly likely that any new risks will be quickly identified during the multiple assessments and audits that will probably be performed throughout the year.

Benefits of Resource Concentration

This ties in with the economies of scale previously mentioned as a benefit associated with cloud providers. The cost of controls on a per-unit basis is likely much lower than a customer faces with a traditional data center. For example, spending $1 million on physical security for 1000 servers in a traditional data center equals a cost per unit of $1000 per server. In a cloud data center with 100,000 servers, the cost per unit is $10.

Top Security Risks

The top security risks according to the ENISA are not presented in any particular order of criticality. Because I have addressed these risks in previous chapters, here I provide quick summaries of the information delivered as part of the ENISA documentation. First, though, is a backgrounder on risk itself.

IT Risk Backgrounder

Both the ENISA document and the CSA Guidance assume you have some understanding of IT risk concepts. ENISA actually uses these concepts quite systematically to analyze cloud security. Although these concepts are are not included in the CCSK exam, it is worthwhile for you to be familiar with them, which will help you understand these documents and assist you in applying cloud security knowledge in practice. In my experience, understanding and applying these concepts will give you more options in securing IT and therefore in securing the cloud. It will also make your conversations easier.

Risk analysis should always start with the thing of value to be protected. This is called the asset. An example would be capacity on a storage disk or a set of sensitive data. All assets have vulnerabilities. According to ENISA, a vulnerability is “any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.” In our examples, disk capacity can run out, and sensitive data can get leaked. It is important that you understand that vulnerabilities exist, whether they are realized or not.

ENISA then states that a risk is the result of a threat that exploits a vulnerability. You should understand that the threat can be malicious (an intentional act) or otherwise (such as wear and tear or negligence). In either case, the result is a negative impact or an actual bad consequence. In IT, the negative impacts are typically categorized as loss of confidentiality, loss of integrity, or loss of availability. The damage is, in the end, to the business utilizing the IT, and it should therefore be explained in terms that matter to those stakeholders. This may well be a long scenario, but it is important that you create the full story. If you just say, “This machine can be accessed by a bad actor,” any stakeholder could answer, “So what?” If you go about saying that sensitive data is on that machine, which will subsequently get into the hands of the data protection authority, which will lead to them getting a fine or worse, you will get a different response.

In our examples, a storage disk filling up may lead, in the end, to a service no longer being available, which therefore means unhappy customers. Data leakage can lead to reputation loss or legal punishment. Risks, therefore, impact assets and, in particular, the assets’ value. The more likely or probable the risk and the higher the negative impact, the more important it becomes to do something about it. Risks with low probability and low impact are not the first concern.

Anything that reduces the likelihood and/or impact of a risk is called a control or countermeasure. For our examples, we could set up disk space monitoring or encryption of data. In reality, many engineering options exist. The cloud makes certain old controls difficult to use, but it also enables new controls, such as dynamic and granular network access controls. It is therefore difficult to say in general whether the cloud makes IT more or less secure.

Loss of Governance

You know there is a shared responsibility in the cloud. When the client cedes control to the provider, there may be a gap in security defenses if there is no commitment from the provider in a service level agreement (SLA). Contractual clauses (such as Terms of Use) may restrict customers from performing compliance activities that support governance.

If a provider uses their own third parties (such as an SaaS provider using an IaaS provider), you may have no governance capabilities whatsoever. If a provider is acquired by a different company, contractual clauses of the service may be changed by the new company. Such loss of control and governance may lead to an organization being unable to meet security requirements; they may suffer from a loss of performance or deterioration of quality of service, or they may experience significant compliance challenges.

Lock-in

The lack of portability leads to vendor lock-in. There are rarely tools available from vendors or other sources (such as open source) to facilitate the movement of systems and/or data from one provider to another. The causes of lock-in can be numerous. It can happen from annual SaaS contracts with very painful cancellation clauses, and it can happen because of technology issues, such as the inability to export data in a format that can be used in a different provider’s environment. Even when the core technology is standardized (such as containers and VMs), there may be significant differences in the providers’ management plane interfaces.

The ENISA documentation focuses on the lock-in associated with each service model. The following sections list the various types of lock-ins that customers may face when using the various cloud service models.

SaaS Lock-in

Much of the lock-in potential associated with SaaS has to do with the ability to export data in a format that can be used in another location. Providers will often store tenant data in a custom database schema. There is generally no agreement regarding how data is structured, but there are common formats in which data may be exported (such as XML).

Of course, when dealing with SaaS, you are dealing with a custom application. Migrating from one SaaS provider to another will likely impact end users. This will likely require retraining and can result in significant costs in a large enterprise. Additionally, any integration (such as APIs) with internal systems, and your existing SaaS solution will need to be re-created.

PaaS Lock-in

Although your organization’s use of PaaS solutions may consist of application development, you need to be aware of some portability aspects. The primary issue with PaaS lock-in has to do with the use of provider services, which are often accessed by an API and used to build complete application functionality. This is referred to as API lock-in in the ENISA documentation.

Application code itself may require customization if a provider does not allow particular functions that they may consider “dangerous” (such as functions that may access the underlying shared operating system layer). This may require that your developers understand these potential limitations and work around them by customizing code to work in a particular environment. ENISA refers to this as runtime lock-in.

Aside from application development, any data generated by PaaS systems may not be exportable in a format that can be easily consumed. The ENISA documentation refers to this as data lock-in.

IaaS Lock-in

When considering IaaS lock-in, you need to consider both workloads and data stored in the provider’s environment. The biggest issue to be aware of in either scenario is what the ENISA document refers to as a “run on the banks” scenario. In the event of a major issue with a provider, numerous customers may begin exporting systems and data simultaneously, leading to poor network performance that could drastically increase the time required to export data.

From a virtual machine lock-in perspective, although software and virtual machine metadata is bundled for portability, this is limited for use within the provider’s environment. Open Virtualization Format (OVF) is identified as the means to address virtual machine lock-in.

IaaS storage providers’ functionality and features can range widely. The main lock-in issue comes down to potential application-level dependence on specific policy features such as access controls. Such dependence may limit the customer’s choice of potential provider.

Isolation Failure

Multitenancy is a defining characteristic of the cloud. It requires a robust isolation capability wherever resources are shared, such as memory, storage, and networking. This isolation requirement is not necessarily just hardware-related. An SaaS offering that uses a multitenant database could also be the source of isolation failure. If this isolation fails, security fails. The impact of such a failure could lead to customers losing valuable or sensitive data and/or service interruption if the CSP shuts down access to address the failure. From a provider’s perspective, isolation failure could lead to business failure because of potentially devastating reputational failure and a resulting loss of customers.

Compliance Risks

Compliance with the regulations and industry certifications required for your organization may be challenged by procuring cloud services. Compliance risks may include the following:

•   A cloud provider cannot provide evidence of their compliance to regulations and/or industry standards your organization must meet.

•   A cloud provider does not allow audits and does not otherwise demonstrate compliance with regulations and/or industry standards your organization must meet.

Management Interface Compromise

Because accessing the provider’s management interface (aka management plane) is generally performed across the Internet, it can be accessed by anyone, including malicious users. Remember that access controls are your primary controls for securing the management plane and that multifactor authentication (MFA) should always be used for privileged accounts that access the management plane.

Data Protection

Checking how a provider handles data and ensuring that it is done in a lawful manner on behalf of customers may be difficult. This poses a data protection risk to your organization as a result, especially in the case of multiple providers storing information as part of a solution (such as federated clouds). This risk can be mitigated by reviewing any provider’s certifications and supplied security documentation.

Insecure or Incomplete Data Deletion

Deletion of data in a shared cloud environment presents a risk to customers. This is because of the nature of shared storage and the inability to confirm that data has been completely deleted from the provider’s environment. Additionally, as covered in Chapter 11, data dispersion is often used by providers. This type of storage will make multiple copies of data and spread them across multiple servers and multiple drives. This, along with the previously mentioned issues, leads to a higher risk for customers than they face with dedicated on-premises hardware.

Malicious Insider

Cloud service provider employees and contractors pose a significant risk to your organization when you use cloud services. Although the likelihood of realizing such risks is low, the impacts of doing so can be very high.

Five Key Legal Issues Common Across All Scenarios

Five key legal issues have been identified as common across all the scenarios. This information is found in “Annex 1” of the ENISA documentation. The information in the following sections is not specific to the cloud and is applicable to all forms of computing.

Money talks. Much of an organization’s capability to define contractual controls to meet legal obligations is based on the size of the provider and that of the customer. Very large providers will likely have a “take-it-or-leave-it” approach with smaller potential customers, but they may be more open to negotiate with larger potential customers. This is also true with large customers and smaller providers. Smaller providers will be more likely to negotiate terms with large potential customers but may not do so with small- and medium-sized business (SMB) customers.

Data Protection

The data protection referred to in the ENISA document is about processing integrity and availability. Much of this section focuses on Directive 95/46/EC (Data Protection Directive), which has since been replaced by the GDPR.

For your general understanding of this section, just remember that data that contains personally identifiable information (PII) needs to be strongly protected, because this type of data, if compromised, will lead to legal issues for your organization.

Confidentiality

You know that confidentiality is a main security principle, and you know that data should be accessed only by authorized individuals. This section of the annex contains a term that has not been previously covered: “know-how.” The ENISA defines know-how as something similar to documented trade secrets—how the customer does what it does, such as a manufacturing process.

Intellectual Property

Some cloud providers may contractually take ownership of any data that is uploaded to their systems. As a result, customers should ensure that intellectual property rights are regulated through dedicated contractual clauses in the Intellectual Property Clause and Confidentiality/Non-Disclosure Clause. These clauses should include penalties in case a provider does not properly protect such data and the ability for the consumer to terminate the agreement unilaterally.

Professional Negligence

The easiest way to think of lawsuits is to think about who has contracts with whom. The end user has a contract with the data controller, and the data controller has a contract with the provider (or data processor). If the end user’s data is compromised, they are suing the data controller, because that is the party to which they are contractually bound.

Limitation of liability and indemnity clauses may help the company directly using the processor to shift liability to the provider; however, the data controller is always legally responsible and accountable for the loss of any end-user data.

Outsourcing Service and Changes in Control

This part of the ENISA document is all about using a provider that outsources some (or all) functionality to another provider. This leaves you, the customer, with third and fourth parties that you need to be aware of.

ENISA recommends that any outsourcing carried out by the provider be clearly understood as part of your due diligence. Providers should offer guarantees or warranties regarding the performance of outsourced services. The ENISA also recommends that you request contractual clauses that state that your organization must approve of any changes the provider makes in their outsourcing agreements, or you have the ability to terminate or renegotiate terms.

Additional Items for the Exam

The following sections contain additional items from the ENISA document that you may be tested on as part of your CCSK exam.

Open Virtualization Format

The only reference to OVF in the ENISA document is the following sentence: “Migrating between providers is non-trivial until open standards, such as OVF, are adopted.” Now what, exactly, is this OVF they’re talking about? The OVF is an open standard by the Distributed Management Task Force (DMTF) that is intended to assist with portability of virtual machines by easing the ability to migrate server images from one environment to another.

Of note, you may also see open virtualization archive (OVA), which is essentially a ZIP file (actually a TAR file) that contains all of the files associated with OVF.

VM Hopping

VM hopping is an isolation failure in which an attacker moves from one virtual machine (VM) to another, which they are not intended to access. This would likely be related to a failure or compromise of the underlying hypervisor that should be providing VM isolation.

Economic Denial of Service

With the incredible scalability of cloud services, particularly IaaS, you have the ability to increase computing power automatically to meet increased demand (generally performed in IaaS through auto-scaling groups). However, when planning such elasticity, you need to consider the following question: What if you’re spending vast sums of compute power to respond to a denial of service attack?

Licensing Risks

Licenses still need to be addressed when used in a cloud environment, especially IaaS. Any server instance running commercial software should report back to a centralized license management system to protect against illegal usage of the software.

Risk Concerns of a Cloud Provider Being Acquired

The acquisition of your CSP can have a significant impact on your organization. The ENISA documentation states that this may cause nonbinding agreements with a provider (for example, things the provider is not contractually required to supply) to be at risk.

There have been real-life examples of CSPs having been acquired, when, in some cases, the new owner has decided to pivot the cloud services to serve only particular industries. In other cases, new ownership decided to terminate the offering a few years after acquiring the provider.

A provider being purchased is an example of your needing to monitor relationships continuously with all providers your organization is using. Failure to do this may introduce risk to your organization if a new owner makes substantial changes and/or changes business plans.

Data Controller vs. Data Processor Definitions

Recall from Chapter 3 that the data controller is the entity that determines the purposes and means of the processing of personal data in accordance with laws and regulations in an organization’s jurisdiction. The data processor is the entity that processes personal data on behalf of the controller.

Guest System Monitoring in IaaS Responsibilities

Guest system monitoring is the responsibility of the customer. In a nutshell, the ENISA document states that the customer must take full responsibility for their cloud-deployed applications. This, of course, includes monitoring of everything the customer is responsible for.

User Provisioning Vulnerability

Multiple vulnerabilities are associated with user provisioning in the ENISA document. So that we’re on the same page regarding the vulnerabilities listed in the document, there are several potential weaknesses regarding processes. This, of course, is not to say that all the vulnerabilities listed here exist; it means these are potential areas that need to be considered and protected from being exploited:

•   The customer cannot control the provider’s provisioning process.

•   The identity of the customer may not be adequately verified upon registration.

•   There may be delays between cloud system components having identities and profile content synchronized.

•   Multiple copies of an identity may be made, and these may not be synchronized.

•   Credentials may be vulnerable to interception and replay.

The ENISA document references this vulnerability as being applicable to the following risks:

•   Economic denial of service

•   Modifying network traffic

•   Privilege escalation

•   Social-engineering attacks

•   Loss or compromise of operational logs

•   Loss or compromise of security logs

•   Backups lost or stolen

Underlying Vulnerability in Loss of Governance

I addressed the risk of loss of governance in the “Top Security Risks” section earlier in this chapter. The ENISA document lists the following vulnerabilities and quick descriptions associated with a loss of governance:

•   Unclear roles and responsibilities This refers to inadequate attribution of roles and responsibilities in the cloud provider organization.

•   Poor enforcement of role definitions A failure to segregate roles may lead to excessively privileged roles, which can make extremely large systems vulnerable.

•   Synchronizing responsibilities or contractual obligations external to cloud Cloud customers may be unaware of their responsibilities.

•   SLA clauses with conflicting promises to different stakeholders SLA clauses may also be in conflict with promises made by other clauses or clauses from other providers.

•   Audit or certification not available to customers The CSP cannot provide any assurance to the customer via audit certification.

•   Cross-cloud applications creating hidden dependency Hidden dependencies exist in the services supply chain. Cloud provider architecture does not support continued operation from the cloud when the third parties involved, subcontractors, or the customer’s company, have been separated (for example, disconnected) from the service provider.

•   Lack of standard technologies and solutions A lack of standards means that data may be locked in to a provider. This is a big risk if the provider ceases operation.

•   Storage of data in multiple jurisdictions and lack of transparency Mirroring data for delivery by edge networks and redundant storage without real-time information available to the customer of where data is stored introduces a level of vulnerability.

•   No source escrow agreement Lack of source escrow means that if a PaaS or an SaaS provider goes into bankruptcy, its customers are not protected. A software escrow agreement may enable the customer to re-create a similar service with another provider.

•   No control on vulnerability assessment process Restrictions on port scanning and vulnerability testing are an important vulnerability, which, combined with a Terms of Use that places responsibility on the customer for securing elements of the infrastructure, is a serious security problem.

•   Certification schemes not adapted to cloud infrastructures Not all certifications contain cloud-specific controls, which means that cloud-specific security vulnerabilities are likely to be missed.

•   Lack of information on jurisdictions Data may be stored and/or processed in high-risk jurisdictions where it is vulnerable to confiscation by forced entry. If this information is not available to the cloud customer, they cannot take steps to avoid it.

•   Lack of completeness and transparency in terms of use This occurs when the provider’s usage policy is unclear or lacks detail.

•   Unclear asset ownership A customer failing to understand asset ownership could result in inadequate application of security baseline and hardening procedures, human error, and untrained administrators.

Risks R.1–R.35 and Underlying Vulnerabilities

For this section, I list the various risks that are identified by the ENISA and the risk rating as identified by the ENISA for each. Many of the more important risks and vulnerabilities have been previously addressed in this chapter. I recommend that you use this chart to gain an understanding of the high-, medium-, and low-level risks according the ENISA before taking your CCSK exam. There is no need to memorize this table, however.

Chapter Review

This chapter covered the key elements of the ENISA document that will form part of your CCSK exam. The ENISA document accounts for 6 percent of the total questions in your CCSK exam (87 percent is based on the CSA Guidance and 7 percent is based on the Cloud Controls Matrix [CCM] and Consensus Assessments Initiative Questionnaire [CAIQ]). In preparation for your CCSK exam, you should be comfortable with the following:

•   Understand the listed security benefits of the cloud from a business perspective.

•   Understand the top security risks associated with cloud computing.

•   Understand the top legal issues your organization faces across all scenarios.

•   Understand the listed risks and associated vulnerabilities.

Questions

1.   Which of the following is listed by ENISA as a way for SaaS or PaaS providers to protect their customers?

A.   Providers should have redundant storage in place.

B.   Providers should have a source code escrow agreement in place.

C.   Customers should have contractual agreements that list penalties for loss of code.

D.   All of the above are correct.

2.   According to the ENISA documentation, which of the following may be used in IaaS to address portability?

A.   OVF

B.   WAF

C.   IAM

D.   DAM

3.   Why is data deletion considered a top security risk according to ENISA?

A.   Because of the shared nature of storage

B.   Because of the inability to verify that data is adequately deleted

C.   Because SSD drives cannot reliably wipe data

D.   A and B

4.   Which of the following is not an example of vendor lock-in?

A.   Contracts with termination penalties

B.   Provider exports data only in a proprietary format

C.   Custom SaaS applications

A.   PaaS platforms that restrict available functions

5.   VM hopping is an attack that is possible in the event of what failure?

A.   Virtual storage control failure

B.   Hypervisor segregation failure

C.   Hypervisor isolation failure

D.   Inadequate security controls by the customer

6.   Which of the following could be considered a malicious insider as per ENISA “Top Security Risks”?

A.   Customer administrator

B.   Provider’s auditor

C.   Customer’s auditor

D.   All of the above

7.   A company administrator determines that the best approach to dealing with any sudden increases in network traffic is to create an auto-scaling group that will create an unlimited number of web servers to meet increased demand. What has the administrator created?

A.   The administrator has implemented an auto-scaling practice that is commonly performed to take advantage of the elastic nature of the cloud.

B.   The administrator has implemented an application load-balancing system.

C.   The administrator has implemented a network load-balancing system.

D.   The administrator has created an economic denial of service scenario if there is ever a denial of service attack against the company.

8.   Which of the following is not considered a vulnerability associated with the risk of loss of business reputation due to co-tenant activities?

A.   Lack of resource isolation

B.   Lack of reputational isolation

C.   Hypervisor vulnerabilities

D.   Object storage

9.   Which of the following is not listed in the ENISA documentation as a potential area that needs to be considered and protected from being exploited with regard to user provisioning?

A.   Credentials that may be vulnerable to interception and replay

B.   If the customer cannot control the provider’s provisioning process

C.   If the identity of the customer may not be adequately verified upon registration

D.   The customer’s ability to restrict access to the IAM system supplied by the provider to a specific range of IP addresses

10.   What should always be done to protect against possible management interface compromise where an attacker gains access to your cloud environment (select the best answer)?

A.   Connect to the management interface via IPSec VPN.

B.   Protect connections through the use of TLS.

C.   Implement MFA on all privileged accounts.

D.   Create separate accounts for administrators with access to the management plane.

Answers

1.   B. To ensure that SaaS or PaaS software is not orphaned or abandoned in the event of a provider’s failure, customers should seek to ensure that providers have a code escrow agreement in place with a third-party escrow agent. Although the other answers are good ideas for protecting customers, only code escrow agreements are listed in the ENISA documentation.

2.   A. The ENISA document calls open virtualization format (OVF) as potentially beneficial to address portability in an IaaS environment.

3.   D. Insecure or incomplete data deletion is a risk in cloud because of the shared nature of storage and the inability to verify that data is adequately deleted. Although SSD wiping is possible (only with vendor-supplied tools), this is not listed as a reason in the document. It is also not true that all providers use SSD for storage of customer data.

4.   C. All SaaS products are customized applications. This fact is not the source of vendor lock-in. What creates a lock-in situation with SaaS is the lack of ability to move data easily from one SaaS provider to another. If tools exist (generally they are limited) to move from one SaaS provider to another, vendor lock-in can be fairly easily dealt with. All the other answers are lock-in scenarios.

5.   C. Performing VM hopping is a result of hypervisor isolation failure. None of the other answers is correct. Remember that segregation is not the same as isolation.

6.   B. The ENISA document lists provider employees and contractors as potential malicious insiders. As such, the only possible correct answer is the provider’s auditor.

7.   D. The administrator has created an economic denial of service scenario if there is ever a denial of service attack against the company. This is because of the measured service characteristic of cloud computing, where companies pay for the resources they use. Load balancing will distribute traffic across only an established amount of servers, so B and C do not address what the administrator has established. Finally, although auto-scaling groups are common, there needs to be a set limit to the amount of servers that will be created.

8.   D. Object storage is the only answer that is not listed as an associated vulnerability to the risk of loss of business reputation due to co-tenant activities.

9.   D. The only possible answer not listed is that the customer can restrict access to the IAM system supplied by the provider to a specific range of IP addresses. This is because the IAM system is part of the management plane that can be accessed from anyone as part of the broad network access characteristic of the cloud. All other entries are listed as areas for consideration and protection.

10.   C. Privileged accounts should always access the management plane with MFA. The management plane faces increased risk of compromise because it is globally accessible; therefore, implementing a VPN of any sort is not listed as a potential safeguard. All users accessing the management plane should always have separate accounts, but D addresses repudiation, not security of the accounts accessing the management plane. Although all connections should be protected in transit (such as with TLS), B is not the best answer.