One of the key issues when talking about cloud computing and security is cloud security vulnerabilities. It’s good to be aware of the main cloud security risks as they may occur due to many reasons. Moreover, security-related weaknesses affect various areas imposing a huge financial burden on organizations and costing them a fair amount of other resources.
Many of the key risks of using cloud computing are similar to the local hosting - for example inside actors who perform malicious operations or phishing activities. However, there are some additional risks that should be considered when discussing cloud security. This list isn’t exhaustive by any means and its purpose is to bring your attention to some additional consideration when choosing your cloud service provider.
Table of contents:
- Risks associated with using APIs
- Misconfiguration of cloud services
- Shared tenancy
- Limited visibility of data storage
- Shared security responsibilities
- Inability to test CSP’s security measures
Risks associated with using APIs
This could be an article on its own but I will try to limit it to the core. Using APIs has been constantly becoming more and more popular due to its convenience and speed when exchanging information between applications. It also means that in recent years it has become one of the key attack vectors for malicious hackers.
According to OWASP, there are 10 potential vulnerabilities or risks directly associated with using APIs. The below list is created by The OWASP API Security Project, shared here without additional “Read more” links, and licensed under Creative Commons Attribution-ShareAlike 3.0 license.
API1:2019 Broken Object Level Authorization
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
API2:2019 Broken User Authentication
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.
API3:2019 Excessive Data Exposure
Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
API4:2019 Lack of Resources & Rate Limiting
Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
API5:2019 Broken Function Level Authorization
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
API6:2019 Mass Assignment
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
API7:2019 Security Misconfiguration
Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
API8:2019 Injection
Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
API9:2019 Improper Assets Management
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
API10:2019 Insufficient Logging & Monitoring
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Misconfiguration of cloud services
According to the NSA, the misconfiguration of cloud services is one of the most common reasons for compromising the data. This self-inflicted risk comes often from a lack of expertise and skills among the implementation team, who often worked for the company in its legacy local hosting setup. Any model of cloud computing carries different risks when it comes to misconfiguration issues however they share one in common - it requires data transfer to/from third-party infrastructure which is an additional point that requires control over how the data is streamed.
Shared tenancy
Every CSP (Cloud Service Provider) most likely hosts many tenants on its infrastructure given the business model of providing such services. This means that any potential attack targeting CSP may (and likely will) affect some of the tenants. Surely it isn’t the easiest of attacks to perform but the fallout can be devastating. Imagine a group of hackers escalating privileges to control the CSPs domain. Pivoting to the customers’ data hosted on that cloud may be just a matter of time. The isolation and encryption methods are essential to consider when choosing your next CSP.
Limited visibility of data storage
The idea of any cloud model (IasS / PaaS / SaaS) is based on storing some portion of the data on external infrastructure. This means that whether the data is accessed, deleted, or processed - it happens on a third-party server and the client has limited visibility of the actual location for storing the data. That can lead to some uncertainties (and eventually risks). For example, removing the data may still leave some trace of the contents on the CSPs servers that would not be visible or manageable by the customer.
Shared security responsibilities
Along with the data stored in the cloud, the customer also hands over some control of how the data is secured. Depending on the service type, the responsibility for properly securing applications, operating systems, and network traffic may be on the customer or CSP side. It means that there is no unified set of rules and policies to manage potential risks as well as it can raise some responsibility uncertainties during threat response.
Inability to test CSP’s security measures
Over the past years, there is a significant growth in the number of companies that use offensive cybersecurity teams (both external and internal) to test their security means. It helps to understand what the potential threats are, which attack vectors malicious hackers could possibly use and how vulnerable the organization is. Unfortunately, it is very unlikely that the CSPs would allow customers to perform similar controlled attacks on their infrastructure - also for obvious reasons - it may compromise or affect service provided to other tenants. Based on that, even when the customer tests its security level using the best methods available, the cloud service will be a potential risk as most likely it will not be put into the real-life scenario test.
And you, what other cloud security vulnerabilities can you trace? Which of them do you find the most threatening for modern organizations? How to prevent and fight them effectively?
