Securing Cloud Infrastructure Demands a New Mindset
Credentials are the other prime target for criminals in the cloud: identities, permissions, keys, tokens, and passwords that can be exploited in myriad ways. Developer accounts have especially high value because they give direct access to cloud infrastructure. Public projects and container registries are also often targeted, as they frequently contain hard-coded, publicly accessible credentials.
As with misconfigurations, once bad actors get their hands on keys and other credentials, they can create new resources, often without anyone being aware of them.
While risks such as privilege creep and poor privilege control can be addressed through better policy enforcement, protecting credentials in the cloud is challenging due to the sheer complexity of the environment. Identity and access management (IAM), for example, must account not only for individuals and internal teams but also partners and other third parties as well as the full array of non-human resources.
Cloud infrastructure exploits in action
Several recent examples illustrate these various types of cloud attacks and the damage they can do. Just this year, a group called Storm 558 obtained Microsoft Azure keys and was able to impersonate any Azure user. Another group, Team TNT, gained entry to AWS services via malware, stole credentials, and used those to commit further attacks.
On the misconfiguration front, Microsoft’s AI research division was recently found to have leaked terabytes of sensitive data—including service passwords, keys, and internal messages—by accidentally sharing the URL for a misconfigured Azure Blob storage bucket. And Toyota discovered a misconfiguration in its cloud-based smart car network that gave cybercriminals access to vehicle serial numbers, camera footage and other private data… for more than a decade.
Detecting and mitigating these kinds of threats requires new attitudes and approaches from CSPs and cloud users alike. The Storm 558 Azure attack, for instance, could only be discovered with premium logging features, leaving many customers in the dark. Microsoft ultimately opened up log access so everyone affected could find and resolve the issue. Toyota, having presumed privacy by default, had no active way of scanning its cloud infrastructure to detect the misconfiguration that exposed its customers’ data. It needed whole new tools to secure its smart car network.
A strange new world
Even more disconcerting than facing new threats and risks is the fact that traditional IT security concepts and definitions don’t seem to apply in the cloud. Case in point: threat severity.
Standard classifications of threat severity don’t work because severity is highly contextual in the cloud. A low-severity threat on its own may not end up being so minor depending on what the attacker has access to, or which boundaries they can cross—for example, out of the cloud and into the enterprise data center in a hybrid cloud setup.
It’s also hard to address zero-day issues in the cloud. In the IT world, agencies recognize and give numbers to common vulnerabilities or exposures (CVEs). Once a threat is listed officially as a CVE, vendors take steps to address it. But issues in the cloud don’t get the same CVE classification—meaning vendors may not choose to work on a fix.
The basic nature of the cloud environment is also confounding. Enterprise security teams don’t have the visibility they would in a traditional network because they have to rely on what their CSPs let them see. Not all logging is accessible by default—and some isn’t available at all, even for a premium.
Visibility in the cloud is also compromised by how much abstraction there is. Service owners have little visibility in a serverless environment, and machines will talk to machines across clouds, making it hard to draw boundaries around activities. That makes it exceedingly hard to apply best-practice security principles like zero trust. (Not that it can’t be done, but the approaches need adaptation.)
So what can organizations do to protect themselves given the complexity of cloud infrastructure?
‘Shared fate’ is not the answer
While the shared responsibility model of cloud security is still widely embraced by CSPs, it clearly leaves too many gaps uncovered, resulting in a ‘shared fate’ situation in which CSPs risk reputational damage from successful cloud attacks and cloud users face financial losses, regulatory penalties, and bottom-line harms.
Greater communication and collaboration between CSPs and their customers, approaching security as a truly joint endeavor, is the only real way to go, ensuring cloud infrastructure, services, clusters, containers and code are protected.
A truly collaborative approach allows for better overall cloud security posture management while developing and deploying tools that can scan code for malware, misconfigurations, rogue containers, rogue cluster paths and more. It also makes it easier to cover the entire software development lifecycle, and to reach agreement on questions like how to classify and rank zero-day threats.
Limit cloud infrastructure risk together
As threat actors continue to target cloud infrastructure, CSPs and organizations alike need to focus on identifying and fixing misconfigurations and better managing credentials and permissions—especially developer credentials, which need to be protected. Just as important is starting from the assumption that breaches are happening, and to anticipate what might happen post-compromise. Trend Micro takes this approach with its cloud and cloud-native threat research, and regularly finds that hypothetical types of breaches are in fact happening in the real world.
With the right outlook and a spirit of real cooperation, organizations can work with their CSPs to get out of the ‘shared fate’ bind and proactively protect their vital cloud infrastructure.
Next steps
For more Trend Micro thought leadership on cloud security, check out these other resources:
Read More HERE
