By Crystal Morin, Cybersecurity Strategist
It should come as no surprise that developers prefer building cloud-based applications because the cloud makes it easier to deploy and run apps. According to Stack Overflow’s 2023 Developer Survey, a majority of developers – from students to professionals – are working in cloud environments. Why is the cloud the place to be? Rather than having to requisition hardware or put together a business use case in advance, developers can quickly test their ideas with cloud software deployments. Throw automation into the mix and the entire process, from development through deployment, is faster and simpler.
However, these same benefits are attracting adversaries. According to the our Threat Research Team’s 2023 Global Cloud Threat Report, attackers are using cloud automation too, enabling them to initiate cloud attacks less than ten minutes after finding credentials.
So how can you secure your cloud infrastructure, and what processes should you have in place from an architecture perspective? Where can you make life easier for your team but harder for attackers?
Take away the low hanging fruit
Attackers are looking for gaps in both architecture and infrastructure that they can exploit for initial access. Once they’ve gained access, they will look for privilege escalation opportunities, which may exist in your automation or management tools. Some of these security gaps are quite obvious and can be easily closed.
Infrastructure as Code (IaC) tools like HashiCorp’s Terraform or AWS CloudFormation are used by developers to automate software and application deployments. To do so, an IaC uses stored credentials or secrets to provide the appropriate permissions levels to the systems involved. An attacker can steal these credentials to move laterally across multiple cloud applications. Similarly, attackers use the API calls GenerateCredentialReport and GetCredentialReport to instantaneously generate and download user reports with passwords, access keys, and more.
Cloud attackers can also access an organization’s infrastructure from a cloud user’s account, if the victim’s on-premises servers are connected to the cloud service provider. In a case I witnessed while on the Threat Research Team, an attacker used the API call SendSSHPublicKey to access EC2 instances and then pushed their Secure Shell (SSH) public key to the specified EC2 instances. Anyone with the corresponding private key was able to connect directly to the systems via SSH, creating a route for the attacker to exploit and take control of the machines involved.
This type of lateral movement can be hard for security professionals to track, as it crosses over from one area of infrastructure to another. Moving from an AWS account to the EC2 infrastructure means that the AWS CloudTrail logging service cannot provide further data on the attacker’s activity. To understand what’s happening across both cloud and compute instances, you need to monitor both your cloud control plane API, such as CloudTrail, and your EC2 workloads at runtime. To restrict these kinds of attacker accesses and movements in your cloud environment, there are three things you can do to improve your security.
First, do not rely solely on your cloud service provider for security alerts. A managed cloud threat detection service will provide you with more timely alerts for potential issues and misconfigurations in a complex environment, rather than leaving you with an excessive amount of noise stemming from normal environmental activity.
Next, remove excessive permissions that users have but no longer use or require. Typically, attackers look for administrative accounts to more quickly and easily expand their footprint within a cloud environment, or to install malicious software like cryptomining tools or ransomware. If you adopt a combination of a least privilege model, a secrets management service, and a cloud infrastructure and entitlements management (CIEM) approach, you can efficiently track and manage permissions.
Finally, it’s important to clean up your cloud infrastructure and environments too. What purpose do the services and applications running serve? Much of your cloud estate will be needed over time, but there may be components that are no longer required and can be removed, such as those used for testing. Knowing and tracking your infrastructure and environmental inventory gives you a baseline – any deviations from this are worth investigating. At the same time, an inventory will help you track applications and services that need to be remediated in the event of a security issue or misconfiguration being discovered.
Keep an eye on runtime
The traditional security approaches of static and vulnerability scanning containers and software packages in your cloud infrastructure will catch a majority of potential attacks, but they are not quite enough. Many threat actors have mastered evading these defensive approaches by hiding malware in seemingly innocuous packages or containers.
Our Threat Research Team analyzed more than 13,000 container images on Docker Hub and discovered 819 containers that included malware. Of these, more than 10% were not discovered by static analysis or vulnerability scanning. Instead, this malware was only apparent after the software started running and exhibited malicious behaviors, such as connecting to suspicious IP addresses, trying to install TOR, or deploying a cryptomining tool.
To discover and stop this hidden malware prior to deployment, you have to conduct runtime analysis. The open source runtime analysis tool Falco can provide this necessary insight across running containers, cloud environments, Kubernetes pods, and the host machines that support these environments.
Most cloud-native applications now use container images to make deployment easier and repeatable. As these images evolve and change over time, there are iterations and versions of the original image. Attackers use this same behavior to obfuscate their malware. In the image code, they will point to a version to download from a GitHub repository with the malicious code embedded. While one code version may be perfectly legitimate, another may be malicious and this will be detected with runtime analysis.
Runtime analysis can also track container drift over time. As more code is added to running containers, the image that you have in place today may look very different from the initial image that you have stored centrally. Tracking and monitoring these changes can highlight potential problems with the current image, such as misconfigurations that have been introduced. It will also show where you should update your central container images in your library so that they don’t need so many additions to work effectively.
Despite the security challenges posed, the future of software and application development remains in the cloud. Automation in the cloud offers both the speed and simplicity that organizations need in order to develop faster. Though looking for threats via static analysis remains as a part of the equation, addressing excessive permissions, having visibility across your entire environment, and prioritizing runtime security cannot be overstated.
Morin is a cybersecurity strategist at Sysdig. She was originally a threat research engineer on the Sysdig Threat Research Team, where she spent her time discovering and analyzing cyber threat actors who took advantage of the cloud. Morin began her career as a linguist and intelligence analyst in the United States Air Force. Prior to joining Sysdig, she spent four years as a contractor for Booz Allen Hamilton, researching and reporting on terrorism and cyber threats.