15. ENISA Cloud Computing: Benefits, Risks, and Recommendations for Information Security Flashcards
“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 = 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 do increased security certifications and capabilities 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”
“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 centre. For example, spending $1 million on physical security for 1000 servers in a traditional data centre equals a cost per unit of $1000 per server. In a cloud data centre with 100,000 servers, the cost per unit is $10.
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 defences 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 third parties (such as a 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.”
“Migrating from one SaaS application to another is not much different from application migration in your data center. Both will likely be the source of much effort.”
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.
