As enterprise CISOs try and maintain security across their entire global threat landscape, they are finding themselves in a love/hate relationship with their various cloud environments. For many, though, it’s more of a hate/despise relationship.
Clouds can appear to be a seamless extension of existing operations, but they are in reality controlled by various cloud teams that are spread across the enterprise — and that may be at odds with the cybersecurity team’s directives and needs.
As such, the very nature of cloud use in the enterprise can deliver a wide range of insidious cybersecurity problems that can be difficult to detect. We spoke with a range of cloud security experts about under-the-radar cloud security issues most likely to surprise the enterprise SOC.
Temporary resources are a bigger threat than you think
Few things in the cloud deliver as permanent a headache as temporary resources. That is mostly because they are difficult to scan — given that they are so short-lived — making them ideal places to hide malware.
These ephemeral resources, such as temporary storage instances or dynamic provisioning of resources that exist only to perform a specific function and then terminate, are becoming increasingly common in cloud environments.
“The temporary aspect of ephemeral resources might lead security teams to underestimate the potential security risks, assuming these resources pose less of a threat due to their short lifespan,” says Cache Merrill, founder of software vendor Zibtek.
But once these resources are compromised, they can become the attacker’s best friend by serving “as entry points or temporary havens for malicious activities without leaving much trace for forensic analysis,” Merrill says. “This can be particularly challenging because traditional security tools and practices are often configured for long-standing infrastructure and might not automatically extend to these short-lived components.”
According to Merrill, the chance of typical security scans missing ephemeral attacks is “super high. Worst case scenario? You leave read-write access open to the world.”
IT inventory excuses don’t cut it in the cloud
Security specialists often avoid dealing with performing inventory of IT assets on-prem. What many don’t realize is that taking inventory in the cloud is far easier and there are no excuses for avoiding doing it anymore, argues Scott Piper, principal cloud security researcher at Wiz.
“A lot of folks have scars from dealing with inventory from before.Historically, doing IT inventories was very difficult in a world where you needed to physically trace wires and get eyes on devices. Then you needed to try to understand the software they ran and how they were configured, which required getting agents on them,” Piper says. “That’s a difficult problem because you need an agent that works for the OS with testing and approvals for the potential performance and reliability risks, figure out how to authenticate to the device in order to install the agent, additional possible configuration changes for the network communications they need to perform, trouble-shoot any problems if the agent stops calling in, and more.”
Conversely, the cloud sees everything as an API, which makes taking inventory much more straightforward. It may be far from fun, but security must overcome years of ingrained avoidance.
“Identifying all your resources is one set of APIs. Scanning a server for all the applications and libraries installed can be done by snapshotting the disk with an API and then spending as much time as needed evaluating that data without having to worry much about the performance of that scanning,” Piper says.
Cybersecurity pros who “believe that despite the value an inventory provides, the difficulties in obtaining that inventory aren’t worth it” are doing their companies’ cybersecurity posture as disservice in the cloud, Piper says, as such inventory avoidance can deliver severe cybersecurity problems.
“Because they are not focusing on inventory, they are not seeing the misconfigurations. The inventory that they don’t know about may have critical configuration issues that they are therefore not resolving,” Piper says.
Cloud bills help track attacks — but with caveats
Some attackers aren’t interested in stealing enterprise data via ransomware or shutting down operations via DDoS. Instead, they are saboteurs looking to punish the enterprise for whatever reason. One such method includes denial of wallet (DoW)attacks designed to force your enterprise to run up lots of extra cloud charges.
But it’s not just increases in cloud spend that can be an early indicator of malicious activity.
“A big drop in consumption can tell you that someone is bringing down your cloud — and tell you that before your monitoring systems will,” says Doug Saylors, a partner with technology advisory firm ISG. The attackers “could be removing backups for the last 90 days.”
While tracking cloud spend can deliver cybersecurity intelligence, the nature of cloud billing — especially when new features and services are constantly being added — makes real-time sleuthing challenging.
“Hyperscalers are bringing so many products to the market,” Saylors says. “Sometimes the cyber and IT teams find out about those products way beyond initial development.”
As for DoW attacks, they typically work by “repeatedly triggering API endpoints to intentionally raise cloud computing bills,” says Drew Firment, chief cloud strategist at IT training company Pluralsight.
“As the size of datasets grow, so does the potential financial impact of DoW attacks that exploit vulnerable endpoints and trigger large and expensive data transfers,” Firment says. “To reduce exposure, organizations should implement API Gateway rate limits to prevent abuse of endpoints, as well configure web application firewall policies to limit the number of requests from a single IP address or range.”
Brian Levine, Ernst & Young’s managing director for cybersecurity strategies, adds that a lack of internal transparency over cloud use can be another problem for CISOs.
“Knowledge that should be shared between multiple teams, and the lack of someone senior making sure it gets shared effectively and in a timely fashion, is a common enterprise pain point,” Levine says. “As vendors of cloud services come up with additional security offerings and packages, it can become confusing. What do we need and what is an upsell? It’s a hard analysis to do.”
Levine gave an example of cloud platforms that charge enterprises extra to record and save logs — something that’s crucial to conducting post-event analysis and forensics, especially when attackers deliberately delete or doctor logs they can access.
Your IDP strategy is likely lacking
Identity provider (IDP) outages are relatively rare and don’t last very long. Plus, switching to a backup service can cause bigger disruptions for end-users — given the possibility of requiring a behavioral change — than simply waiting a few more minutes to see whether the primary system gets restored.
But because there’s no way to determine when restoration will happen, enterprises still need an IDP backup strategy, says Martin Kuppinger, principal analyst for German consulting firm KuppingerCole Analysts. Unfortunately, for the reasons cited above, many companies forego having one.
“How long can you withstand an outage of IDaaS/SaaS services when all your authentication depends on it? You need to have something in place to allow you to authenticate such services when your primary IDP is not available,” says Kuppinger, who advises having a second IDP that runs on-prem or separately from the cloud environment used by the primary IDP.
SaaS is a security issue you’re not fully dealing with
SaaS securityholes are sneaky and insidious, quietly adding a massive increase in risk without many SOC staffers noticing.
“SaaS providers vary hugely in risk. SaaS apps are radically different in how much risk they present to the organization. The biggest are very good. The next couple of tiers are usable but there is a long tail of SaaS apps that are very hard to assess,” says Gartner analyst Charlie Winckless.
“This issue is compounded by the fact that many CISOs have a massive focus on the three big hyperscalers and ignore SaaS,” he adds. “Code repositories are often in SaaS and may be open or much less secure than you expect.”
Dangling DNS pointers can be big problems
DNS is another seemingly innocuous issue that can become highly problematic in the cloud, Gartner’s Winckless says.
“It’s easy in the dynamic nature of cloud to be exposed by DNS. [Let’s say your team] sets up a site in Azure with an azurewebsites.net DNS and creates a CNAME for yourself and points it to the site,” he explains. “If you delete the site, which is common, and not the CNAME, an attacker can masquerade under your dangling DNS. This isn’t cloud-unique, but the cloud dynamism makes it much easier to accidentally leave yourself with the dangling DNS pointer.”
When someone provisions a resource in the cloud, it is given a name “but nobody is going to remember that name,” Winckless says, so it gets thrown into DNS. “An attacker can register that underlying domain and put whatever they want there and it looks so much more” like a legitimate enterprise file.
API access is a security incident waiting to happen
APIs may be the essence of cloud structure, but they also provide many onramps for attackers.
“Local API keys in apps are a surprisingly common yet overlooked cloud security gap. Say, for example, an employee is terminated and you disable that user’s single sign-on,” says Paul Querna, CTO of ConductorOne, an identity governance firm. “In many cases, there’s a local API key that will continue working even after SSO has been disabled. That’s because local API keys operate independently of the user’s SSO status and are not automatically revoked when SSO is turned off. This means that the user might still have access to some systems or data, which poses a serious security risk.”
ISG’s Saylors agrees, emphasizing custom code that accesses APIs as a security issue. He gave an example of an enterprise with presences in all major cloud platforms.
“Let’s say someone is using those providers and they happen to have a common identity platform, maybe SailPoint. If SailPoint is passing a data stream to AWS and Microsoft and maybe others, it could permit access to all that client’s information in one of those hyperscaler environments. It might allow limited data access in the cloud. Now let’s say somehow an attacker is targeting that AWS API. If that client was using the same credentials across those cloud platforms,” it could provide extensive access, he says.
IMDSv2: What you don’t know could kill your cloud
In March 2024, Amazon quietly rolled out an update to a critical piece of the AWS platform: the Instance Metadata Service (IMDS). Some SOCs “might not even realize that they are using [IMDS]” and therefore they are exposing their operation to a serious “security threat related to metadata exposure,” says Pluralsight’s Firment.
“AWS uses IMDS to store security credentials used by other applications and services, and makes that information available using a REST API. Attackers can use a Server-Side Request Forgery [SSRF] to steal credentials from IMDS, which allows them to authenticate as the instance role for lateral movement or data theft,” Firment explains. “AWS introduced a newer version of IMDS, version 2, to improve the security of unauthorized metadata, although many organizations are still using the original IMDSv1 as the default. To help CISOs close this potential security hole, AWS recently announced the ability to set all newly launched Amazon EC2 instances to the more secure IMDSv2 by default.”
IMDSv2 “was launched by AWS in November 2019 but the ability to set the default to the new version was not introduced until March 2024. As a result, many organizations continued to use the original vulnerable IMDSv1. Interesting to note that the default only applies to new instances launched, so existing instances with IMDSv1 still need to be reconfigured,” Firment says.
“This is a pretty significant threat for most organizations. There’s probably not an awareness of the need to switch everybody to the new version,” he says, adding that the risk is that attackers “could grab credentials and move laterally within your organization.”