Top 5 Risks in Cloud Security Managed Services in 2023.

Over the past ten years, organizations have begun moving more towards cloud computing. The ability to scale solutions while staying cost-effective allows organizations to improve their agility, speed up application release timelines, and leverage additional computing resources on demand. While IT asset management becomes easier, the requirement of strong security to protect it remains.

The highest risk to cloud security is misconfiguration of cloud controls, which can expose sensitive data or resources to the outside world, leading to a data breach. However, there are other risks that organizations should understand and prepare for to avoid potential future threats.

Cloud misconfiguration is the biggest threat to a secure cloud environment. Configurations refer to control settings that are applied to both hardware and software in a cloud setting. These allow interoperability and communication between both elements. Misconfigurations amplify the risk of data breaches and unauthorized access due to multiple factors, such as:

• Complexity of cloud environments
• Lack of evolving technology expertise
• Human error resulting in unsecured settings and permissions
• Rapid deployment that interferes with the implementation of security features
• Dynamic nature of cloud environments causing visibility and control issues

If left unchecked, these cloud security missteps can rapidly snowball into an open cloud environment with exposed sensitive data and resources. For major CSP environments, this can be disastrous if not managed early. According to Qualys, among the major three CSPs, Amazon Web Services (AWS) has an average fail rate of 34%, Microsoft Azure stands at 57%, and Google Cloud Platform (GCP) averages 60%. These fail rates are based on CIS benchmark data, with a failure denoting some form of vulnerability or malware found. These fail rates are due to misconfigurations and unpatched vulnerabilities that could lead to an attacker gaining access to the cloud system.

Encryption is essential to keeping an organization’s data protected, but incorrect configuration will result in unprotected data, even with encryption covering your bases. Most CSPs offer encryption as a free service, and setting it up is as simple as clicking a checkbox. Despite the simplicity, encryption isn’t universally implemented.

Within Azure, 99% of the customer data disks are either not encrypted or are not using a Customer-Managed Key (CMK); with CMKs, 85% of the keys are not rotated. The same level of risk affects GCP environments. A staggering 97.5% of virtual machine disks for critical VMs have no encryption using Customer-Supplied Encryption Keys (CSEKs).

Like encryption, Identity and Access Management (IAM) is a critical security control, ensuring user authorization and only allowing access to the resources they require. All three major providers utilize poor implementation of IAM. Examples include 44% of AWS IAM users lacking multifactor authentication (MFA), while in Azure, scans for Enabling Authentication and configuring Client Certificates within Azure App Service fail 97% of the time.

All external-facing assets are exposed to attackers unless appropriate controls are implemented. Data is left as publicly accessible through many major cloud providers, a misconfiguration that is all too common. Improperly protected external-facing assets can result in a cascading impact on the effectiveness of other cloud services. The convenience of something like working on cloud assets without a VPN becomes a potential breach waiting for hackers to exploit.

Exploring new ways to approach cloud vulnerabilities leads to automation and benchmarking processes, which provide greater insights and context to organizations cloud services and how best to defend them. Organizations are attempting to prevent attacks from the earliest stages of an attack chain before progressing to more dangerous tactics.

Deeper statistics show that the exploitation of public facing applications and exploitation of remote services causes high fail rates per the CIS benchmark, indicating that organizations are relying on other compensating controls, such as patches for weaponized vulnerabilities, at a higher rate than for non-weaponized vulnerabilities. With cryptomining malware considered to be one of the highest threats to cloud environments, organizations should focus on mitigating controls like public facing applications and remote services to reduce their risk in the cloud.

The data shows that far too many cloud assets are external-facing and exposed to the internet. Roughly 4% of cloud assets within the nearly 50 million scanned in the Qualys study are external facing, which means they have a public IP address and are visible to any attacker.

While 4% may seem low, any number greater than zero is a cause for concern. If a bank admittedly had a 4% chance of assets being stolen at any given time, investors wouldn’t trust their money with them. Of the 2 million cloud assets that are in danger, 50.84% of them remain unpatched, essentially allowing anyone access to their data without putting up a fight.

Having cloud assets with public IP addresses allows attackers to scan your IP space for vulnerabilities and perform other reconnaissance activities that encourage them to target an organization’s infrastructure. Depending on the types of vulnerabilities and misconfigurations present in the cloud environment, this risk can increase exponentially.

Weaponized vulnerabilities are tools used for exploitation that are freely available to hackers. The existence of a weaponized vulnerability is the same as if someone gave their cloud access information to the attacker. These tools have the entry information necessary for attackers to uncover how to get in and how to move around your cloud without detection. One of the greatest threats to current cloud security is through Log4Shell.

The Log4Shell vulnerability exploits the functionality of Log4j, an open-source logging framework widely used in Java applications. Log4Shell allows attackers to attack Java code or leak sensitive information by manipulating specific string substitution expression when logging a string. This vulnerability is due to multiple factors.

First, because of the number of touchpoints, Log4j can affect many cloud services. Log4Shell can also be exploited through commonly used HTTP requests. Attackers place a malicious string to the HTTP request URL or HTTP headers, leading to cloud services with high volume of HTTP requests to be vulnerable.

Second, the characteristics of cloud environments are also an issue. Due to their scope, these environments can be challenging to comprehensively secure due to the rapid development and deployment cycles. The use of open-source software like Log4j and public exposure of services increases accessibility for attackers across the world.

Finally, due to the nature of cloud environments allowing multiple users to share the same infrastructure can add to the security risks. Legacy applications and systems may not have been designed with cloud security in mind, introducing further risks as these environments evolve. These are attractive targets for attackers, particularly automated exploit scripts that scan for unpatched and exposed systems. As the cloud network evolves, these unpatched areas will inevitably grow, increasing the chances of being exploited. Without proper security knowledge and training, misconfigurations and oversights are bound to occur.

When the risk-reward is great enough, exploitation is a consequence. Data suggests that the two greatest threats to cloud assets are cryptomining and malware, which are both designed to provide a foothold in your cloud environment,or allow lateral movement through your environment.

The main damage caused by cryptomining is based on wasted cost of compute cycles. The cloud environment is used as a method of creating cryptocoins for the attacker, costing organizations millions in energy and cloud resource allocation fees as a result.

Not accounting for generic coin mining software like XMRig, the top three categories of malware in cloud infrastructures during the Qualys study were Denonia, AndroxGh0st/Legion RCE, and SCARLETEEL. The data indicates that the bulk of malware that impacts an insecure cloud asset is a variant of cryptominers. While most are generic, unnamed software, Denonia is famous enough to hold a name in the industry.

Denonia malware is the first malware strain that specifically targets AWS Lambda. Because there are currently no controls in the CIS Hardening Benchmark for AWS that cover Lambda in particular, Denonia has a 56.8% success rate in bypassing controls.

AndroxGh0st works by targeting .env files to gain access to sensitive information such as important credentials, allowing greater lateral movement through organizations.

SCARLETEEL specifically targets high-risk external-facing cloud assets to gather credentials and subsequently launch a credential-stuffing attack for lateral movement and exploitation of a cloud environment. Some of these attacks may even impact on-premises assets depending on their connection to a cloud environment. However, the use of AI and automation should assist in preventing these attacks in the future.

For organizations, this leads to proactive infiltration security methods, as many types of malwares are difficult to find and capable of evading detection for months once they get in the cloud system. Legacy techniques aren’t enough to mitigate the threats posed by these types of malwares as they can’t create and deploy signatures fast enough to prevent infiltration.

A new approach that is gaining traction is the use of deep learning AI technology to quickly discover advanced malware in containers and complex network traffic flows. Deep learning can uncover unknown and unseen malicious software within a cloud environment quickly, giving response teams time to mobilize and manage the threat before it begins to fester.

The value of implementing automated patch management for organizations operating in the cloud can’t be overstated. Patch management accelerates the remediation process, which offers faster resolution times than if an organization weren’t using this tool. It also noticeably diminishes the number of unresolved vulnerabilities.

Automated patching approaches can be done in varying degrees, as some elements can’t be automated into remediation, such as correcting misconfigurations and replacing unsupported software. However, most functions of patch management can be automated and should be if possible. For example, there is an almost 8% difference in the patch rate and a two-day difference in time to remediate between those with and without patch management.
Nearly every studied instance of automated patching proves that it is more effective for remediation efforts than the use of manual solutions. As for aspects of the cloud that should be prioritized, the environments at the highest risk of attack are:

• Data-Hosting Apps
• Database Client Tools
• Relational Database Management Systems (RDBMS)
• Database Servers
• Security Software and Web Applications
• Web Servers

Each of these struggles to upgrade and migrate when they reach EOS, resulting in vulnerabilities that can and will be exploited by attackers. Should immediate remediation or upgrades/migration be required, oftentimes teams will need to test compatibility, perform regression testing, plan downtimes, and scan for threats and vulnerabilities. Without the use of automation, it takes far longer and results in less favorable results, leading to a greater risk in the future.