CompTIA CySA+ Cybersecurity Analyst Certification: Threat and Vulnerability Management - Threats And Vulnerabilities Associated With Operating In The Cloud

Objective 1.6  Explain the threats and vulnerabilities associated with operating in the cloud
Traditional network and application architectures have given way to the trend of moving infrastructures to the cloud. As you probably already know, using the cloud is nothing more than using the resources of someone else’s computing power, whether it be storage, CPU, network infrastructure, or even applications. Cloud computing simply means that you are using the resources of a cloud service provider. Typically, cloud infrastructures reside in large data centers, full of robust, resilient, high-powered computing networks. These large infrastructures are used to provide services to customers through various subscription models.

The key thing to remember in terms of security is that your data and your processing is not confined to your enclosed, protected network. No matter how complex a cloud infrastructure is, the bottom line is that your data resides on someone else’s computers. Therefore, you don’t have complete control over who accesses the data as well as how it is used, stored, and protected. On the surface that sounds very scary, but as you’ll see in this module, there are solid mitigations that can be put in place to protect your organization’s information.
In this module, we’re going to talk about cloud computing models and how they work, with specific emphasis on cloud threats and vulnerabilities. We will also discuss how to mitigate some of these threats and vulnerabilities.

Cloud Service Models
As mentioned, cloud computing is usually provided to customers through some sort of subscription-based model. Customers, whether they are individuals, small businesses, or even large multinational corporations, contract with cloud service providers for various services. This includes applications, infrastructures, data storage, security, and a multitude of other services.

The reason the cloud service models exist is that, from an economic point of view, it makes sense to reduce operating costs by reducing the amount of infrastructure the organization has to manage. This includes physical servers, data center space, and, of course, the people who would be required to run the infrastructure. In a cloud service model, all of this is outsourced to a cloud service provider.

The issues with using a cloud service model include data accessibility, service availability, performance, and shared responsibility. All of these different aspects of cloud computing should be detailed and resolved in the agreement between the organization and the cloud service provider.
The agreement or contract between the organization and the provider should include guaranteed service levels, responsibilities between both organizations, data protection requirements, legal liability, and so on.

Most larger providers, such as Google, Microsoft, and Amazon, have standard agreements that effectively cover these items since they have the power of money, infrastructure, and reputation to ensure that data is kept secure. Smaller cloud providers may require a little bit more scrutiny and negotiation with their contracts. In any case, there should be guaranteed service levels, as well as details regarding the responsibilities of both parties.
In the next few sections, we discuss the different models that organizations can employ when using a cloud service provider. Organizations can use any one or combination of these models to get the services they need, based on their unique requirements. These are the most common models found in cloud computing offerings, but sometimes there is no defining line between them. We will discuss different cloud service models, including software, platform, infrastructure, and function as different services offerings.

Software as a Service (SaaS)
Software as a Service (SaaS) is probably the cloud service that most non-technical people, including individuals, small businesses, and large businesses, have heard of. If you’re using a version of Microsoft 365, for example, as even many home users are, then you are using the SaaS cloud service. SaaS was probably the first major offering of cloud services. Essentially, the model involves you subscribing to general commercial off-the-shelf software, or even custom software, for a fee. The software resides “in the cloud” at the provider, and the software is accessible either through a web interface, a mobile device app, or, in some cases, even as a download. Although Microsoft 365 might be one of the most common examples of SaaS, you can get subscriptions to graphics suites, complex accounting software packages, and customer relationship packages. You can also get teleconference solutions and other remote productivity applications.
The advantages of SaaS are that you don’t have to maintain custom software, and the software is almost always kept up to date because there’s only one place to update it—and that’s the cloud provider. Usually, new features or improvements are automatically included in the subscription. Security is also an advantage because any issues that are discovered are quickly updated centrally in the cloud provider’s space. The organization doesn’t have to worry about patching; the cloud vendor provides all of the service and support for the software. You also don’t have the long-running problem of software piracy that you may have if individual copies of licensed software on CDs are kept at your business site. Collaboration is another advantage, in that multiple users can access the same software packages and share data between them seamlessly.

There are a few disadvantages of this model, but they likely don’t outweigh the advantages. One disadvantage is that you’re paying a monthly or yearly fee, versus buying the software license outright. Another disadvantage is that the organization, for the most part, cannot manage the software on its premises. Although it may manage the licensing to access cloud-based software, the cloud providers are pretty much in charge of updating the software, ensuring its availability, providing for its security, and so on. Although the cloud providers typically perform security patching updates as soon as vulnerabilities are discovered, there is a remote possibility that a zero-day vulnerability will be discovered and exploited before the vendor or the cloud provider is aware of it, which can affect millions of licensed users of the product.

Security vulnerabilities involved with SaaS are typically focused on identity and access management (IAM). This also includes data access by unauthorized persons. The organization has a responsibility to allow only those personnel authorized to access the software and the underlying data, but this is often not managed very well. Typically, there are more users from the organization who have access to the software and data than the cloud provider has on record, simply because the organization has given that access to more people than they have concurrent licenses for. While collaboration is a true advantage, it also can result in security vulnerabilities in that unauthorized persons may access data they are not intended to, because of the ease at which collaboration takes place. This makes it incumbent on the organization to manage authorization to access the cloud apps, as well as the data that supports them. Lack of the use of encryption by the organization can sometimes be an issue as well.

Platform as a Service (PaaS)
Platform as a Service (PaaS) is a step beyond SaaS. Rather than providing software for an organization to use, the cloud provider provisions a development environment so that the organization can develop its unique line-of-business applications. The organization can build its cloud-based applications for its use or to market to other businesses. Normally, an organization that would use the service cannot find a more specialized solution available as SaaS. They may have very unique data requirements, access control requirements, or interoperability requirements with other systems. In any event, PaaS gives them the advantages that a cloud service provider offers, while at the same time giving them more control over their development environment.
Since applications developed in a PaaS environment are more under the control of the organization, rather than the provider, it is incumbent upon the organization to build proper security into the cloud app, in the form of identification and authentication mechanisms, secure configuration, patching, encryption, and so on. Therefore, it makes sense that some of the chief vulnerabilities in a PaaS environment aren’t necessarily the cloud service provider’s environment but the security of the application developed in it by the organization. This makes it similar to typical in-house development models because the organization still must use a secure coding methodology and take into account vulnerabilities such as input validation, injection attacks, buffer overflow and other memory attacks, and so on.

Infrastructure as a Service (IaaS)
Infrastructure as a Service (IaaS) is also a widely used cloud service model. In this model, the cloud provider offers the organization the opportunity to manage its network without large overhead costs associated with acquiring, care, storage, and disposal of hardware assets. Cloud service vendors provide the hardware, network, and storage assets so that the organizational user can install and use any operating system, applications, and so on. The organization can move most, if not all, of its server services up to the cloud—on its Windows or Linux servers, for example. The cloud service provider can offer scalable solutions in the form of increased RAM, enterprise-level storage, multiple CPUs, and even GPUs that can be employed in a virtual server setting. The organization can then build its customized servers and network them together virtually using the cloud provider’s assets. Another advantage of this model is that hosts can be easily backed up and re-created from copies of the virtual machines if there are issues with malware or service loss.
As with the PaaS model, the more control over cloud assets you give to the organization, the more vulnerabilities that are traditionally seen in on-premises infrastructures appear. The IaaS model is no exception to that; organizations incur most of the same vulnerabilities they would have if they maintained their on-premises infrastructure. Additionally, other vulnerabilities can affect bare-metal hypervisors that could compromise the cloud provider’s customers. For the most part, however, vulnerabilities that result in attacks on IaaS infrastructures are more often the result of customer configuration and patching issues.

Serverless Architecture and Function as a Service (FaaS)
A recent addition to the cloud services that many providers offer is the serverless architecture, which means that the customer does not have to set up a server, real or virtual, but instead is provided various functions, which are abstracted from a particular server installation. In other words, the services the client requests are what is provided, regardless of the underlying server architecture. The customer isn’t paying for a Windows or Linux server, just the services that those servers could offer.

This leads to a new offering called Function as a Service (FaaS). The customer may want services that include messaging, storage, compute, or even network services such as DNS or DHCP, for example. The customer doesn’t care what server offers the services, so long as they are functional, accessible, robust, and secure. The advantage of this model is that most of the management of these functions is controlled by the cloud service provider; the customer does not have to provide the overhead associated with maintaining and managing the services. The different functions the customer wants are also dynamic; functions can be executed on the fly via code when the client requires them. An example of this service is Amazon Lambda.

Infrastructure as Code (IaC)
Infrastructure as Code (IaC) is another new, dynamic functionality offered by cloud service providers. It allows developers to dynamically change the infrastructure based on changes in their code. This functionality doesn’t rely on static servers or hosts but instead allows infrastructure to be created as it is needed and changed as necessary. For example, an application might require that the server is changed to a different VLAN or network; IaC can accomplish this. This is just a simple example, however. IaC services can change entire portions of a customer’s infrastructure based on how an organization needs to function, changes in architecture, and quick reaction to some environmental event, such as a natural disaster or malicious attack. A popular example of IaC is Amazon’s AWS CloudFormation services, which can provide templates for developers to use to rapidly change an organization’s infrastructure.

Note: Be familiar with the different services offered by cloud providers as well as their definitions.

Cloud Deployment Models
In addition to the various subscription models offered by cloud service providers, there are different physical and virtual models that an organization can use not only to get the services it needs but to ensure the security of its data and infrastructure. These models define the separation of infrastructure as well as data accessibility from other organizations and entities. In some cases, shared infrastructure works best for an organization, such as for a university. In other cases, such as a cleared defense contractor, strict separation from other organizations’ infrastructures is required. In the following sections, we discuss the different models that make this possible, which include public, private, community, and hybrid cloud deployments.

Public
A public deployment model is one in which the cloud provider owns all of the resources used to provide services to your organization, including hosts, network infrastructure, applications, and so on. Any organization can subscribe to resources in a public provider setup, but each organization has its unique piece of the public cloud infrastructure, so they are logically separate from your organization’s part of the infrastructure. Organizations may have their piece of the cloud infrastructure located on the same physical servers as your organization; however, public doesn’t necessarily mean that anyone can access your infrastructure. There is still separation and security provisions for organizations that buy a piece of a public cloud, such as the services offered by Microsoft, Google, and Amazon. The vulnerabilities for a public cloud are commonly found in the cloud provider’s infrastructure and policies since they are more likely to control more of the maintenance and management portions of the infrastructure. Any weakness suffered by the cloud service provider in this model is suffered by all of the organizations that subscribe to its services.

Private
In a private cloud model, the organization typically owns all the resources used to provide cloud services. Normally, larger organizations may elect to do this so they can keep control over the entire cloud infrastructure—and they have the money and resources to do just that. Organizations may choose to operate in a private cloud infrastructure for several reasons. This may include government or regulatory requirements because of the data they process (healthcare or sensitive financial data, for example). The organization is responsible for the maintenance and management of all the resources used in the private cloud, including servers, network infrastructure, applications, data storage, and, most importantly, the data itself. Because of this nuance, the threats and vulnerabilities for the private model include those that you might have for any privately owned or on-premises infrastructure, such as insufficient perimeter security, lack of access controls, weak authentication, excessive permissions, and so on. Additional threats inherent to cloud infrastructures in general may also be seen, including some level of lack of visibility by organizational infrastructure security personnel, vulnerabilities in cloud-reliant applications, and so on.

Community
A community cloud model is used when you have multiple organizations that have similar infrastructure requirements and may need to share data at some level (for example, multiple universities engaged together in various academic pursuits or research projects). It could include any group of organizations that need to share data and must have consistency in data types, formats, security requirements, and so on. Each organization can still maintain its security requirements for its data; the community cloud model is there to provide a common infrastructure for all the organizations. Vulnerabilities in this model typically are found in the implementation of the security and sharing policies for the different organizations that share the community cloud.

Hybrid
Hybrid models, which are becoming more common, are different combinations of the three preceding cloud deployment models. An organization could have a private cloud for some aspects of its operations as well as subscribe to public cloud services for other portions of the operations; as long as they are kept logically and physically separated, there is no issue. There can also be different combinations of both community and private clouds or community and public clouds. Organizations can also use these different cloud models as alternate processing capabilities or failover for their internal infrastructures. The point is, there’s no one-size-fits-all solution for all organizations, so the ability to be flexible and take advantage of a hybrid deployment model is often an advantage for an organization.

Exam tip: Be familiar with the different cloud deployment models and how they are advantageous to the organization.

Cloud Vulnerabilities
Now that we’ve discussed the basics of cloud services, including subscription models and deployment models, it’s time to discuss the issues organizations can face when using the cloud. These include threats to cloud computing as well as the inherent vulnerabilities found in these models. You’ll find that a great majority of these issues come from the shared responsibility model of a cloud deployment, in terms of who has responsibility for which part of security, privacy, and risk management. Many of these issues also come from the interaction of the cloud infrastructure with external components, such as programming and data interfaces, encryption services, and storage. Although we can’t cover every possible vulnerability you may encounter in a cloud deployment, we will discuss the more common ones you will most likely see on the exam. These include insecure application programming interfaces, improper key management, unprotected storage, logging and monitoring issues, and data accessibility by both authorized and unauthorized personnel.

Note: Many of these vulnerabilities are shared by either the cloud service provider or the customer organization, or combination of both, but it depends on what responsibilities each party has in providing infrastructure, maintenance, management, and security for the different cloud services and deployment models.

Insecure Application Programming Interface (API)
Cloud service providers allow interfacing with their services through application programming interfaces (APIs). These APIs allow the organization to connect different applications and services to those provided by the cloud and can also enable the organization to develop applications within the context of the cloud provider’s services. Unfortunately, APIs are not always secure, for various reasons.
One common reason is that access to the APIs is often uncontrolled; insufficient permissions or authentication may be involved in accessing the API by unauthorized personnel.

Here’s a list of some of the other issues involved with insecure APIs:
- Broken object-level authorization: Failure to authorize access on an object basis
- Broken user authentication: Failure to account for all the different ways a user could authenticate to the API, such as through other applications
- Excessive data exposure: Failure to limit the amount of data exposed to a user to only the data they require
- Lack of resources: Failure to control resources, such as memory, that are used when a user is accessing applications or data
- Lack of rate limiting: Failure to implement throttling to conserve resources
- Broken function-level authorization: Failure to restrict unauthorized functions
- Mass assignment: Failure to properly authenticate users and limit data access
- Security configuration issues: Failure to change default security settings
- Injection attacks: Failure to validate user input
- Asset mismanagement: Failure to manage the different data assets that an API has access to
- Insufficient logging and monitoring: Failure to monitor and log API actions with potential security consequences

Note: Any of these vulnerabilities could result in unauthorized or improper access to cloud-based services and applications from internal or external entities.

Improper Key Management
Managing cryptographic keys used to access encrypted data and systems is extremely important. If an organization fails to manage its encryption keys, it could result in unauthorized access to systems and data, or, almost as bad, prevent unauthorized users from accessing that same data. Encryption keys should be centrally managed, usually by the organization, since that’s not often a function of the cloud service provider. Although the cloud provider may provide encryption services, normally the service provider leaves it to the organization to determine who has access to applications, systems, and data. Data should be managed for encryption during storage and transit.

Encryption and decryption keys should be:
- Centrally issued and tracked
- Tied to the user’s credentials for non-repudiation purposes
- Created for only a limited duration
- Suspended or revoked if there is a suspected key compromise

Unprotected Storage
It goes without saying that the organization should securely manage its storage, even if that storage is located in the cloud. The security measures that an organization takes to protect its data in the cloud are not much different from those it must take if the storage is located on its premises. Even in a cloud model, if the organization doesn’t protect data storage, the data can be accessed by unauthorized personnel, modified, destroyed, or even stolen. The cloud service provider will usually have an interface or facility for the organization to use to protect data storage. At a minimum, the organization should ensure the following:
- It has assigned the correct rights and permissions to the data.
- Sensitive data is encrypted while in storage.
- Cloud-provided or organizational Data Loss Prevention (DLP) solutions are implemented.
- Data backups take place to secure backup storage.

Insufficient Logging and Monitoring
Very often, user actions are monitored and logged by a combination of the cloud provider and the using organization. They may monitor and log different actions, but together the service provider and the organization should be logging all access to applications and data that may have critical security ramifications. The shared responsibilities for monitoring and logging data access and use should be spelled out in the cloud service provider’s agreement. If there is a failure to monitor application, system, or data access, as well as audit this access and log it, then of course the possibility exists that unauthorized access, data compromise, and misuse of applications and systems will be undetected. The cloud service provider and the organization should jointly determine what should be monitored, how much detail should be in the audit logs, and whether certain events will trigger alerts for administrators on either side.

However, at a minimum, the organization should monitor and log the following:
- All access to sensitive data
- All privileged account use
- All configuration changes to the cloud and organizational infrastructures
- Denied actions, such as failed logins and denied data access or modification

Inability to Access
Yet another threat to cloud subscribers is the inability to access their applications and data. This could be for various technical reasons, including communication line failures and data center issues, but it could also be because of malicious acts, such as those from a compromised insider or external hacker. In any case, the wide gamut of security controls available to both the organization and the cloud service provider should be used to ensure that authorized personnel have access to systems and data whenever they need them. Availability levels should be guaranteed in the service level agreement (SLA) between the cloud service provider and the organization, but they must be implemented as strong security controls to ensure availability.

Exam tip: You should be familiar with these vulnerabilities and their potential mitigations, as they are specifically stated in the exam objectives.

REVIEW
Objective 1.6: Explain the threats and vulnerabilities associated with operating in the cloud In this module, we’ve discussed the threats and vulnerabilities associated with cloud computing. We discussed the various cloud service models, which essentially describe the types of “something as a service” that an organization can obtain from cloud service providers. These include simple application services (SaaS), computing and development platforms (PaaS), and network services (IaaS). These also include specific computing functions, such as perimeter security. They come in the form of functions as a service that are abstracted from a particular server platform. There is also Infrastructure as Code (IaC), which allows an organization to dynamically create and change its infrastructure based on its needs.
We also discussed the various deployment models commonly in use, including private, public, community, and hybrid models. Private models are contained internally to the organization for its exclusive use, and all assets used to create the private cloud are owned and controlled by the organization. Public models are used when an organization subscribes to a public cloud service provider, along with other organizations whose services may use some of the same physical infrastructure. Community models involve sharing infrastructure and possibly data between like organizations that have similar requirements, such as several different universities collaborating on a research project. Hybrid models can take the form of any combination of the previously mentioned models.
Different cloud service and deployment models suffer from some of the same threats and vulnerabilities that traditional on-premises models suffer from, but to varying degrees. These include access control, authentication, encryption, and other potential issues. However, the focus is on whether the provider may endure these threats and vulnerabilities to some degree more than the customer will, and this depends on the chosen services and deployment model.
Specific cloud vulnerabilities discussed in this module include insecure application programming interface services; poorly managed cryptographic key management; unprotected storage, which may have improper access permissions; mismanaged logging and monitoring functions by the organization; and availability issues, which may result in the organization not having effective access to its resources and data.