Credit: Dreamstime
Many organisations are automating their cloud infrastructure deployments through code. This allows them to establish a secure configuration baseline early in their DevOps lifecycle, but the security posture of most cloud resources later drifts due to undocumented changes that often remain undetected.
A new study from cloud security company Accurics found that in as many as 90 per cent of cases the configuration of cloud resources was modified by privileged users after deployment.
While many of those changes might have legitimate business reasons, others might be the result of malicious lateral movement activities following compromises. Insecure configurations are the top cause of data breaches involving cloud resources and cloud-hosted data. If they're not detected and left unaddressed, they can be an easy entry point for attackers.
Infrastructure as code and a false sense of security
According to Accurics, almost a quarter of all configuration changes in cloud environments are now made via code. This is part of a DevOps process known as infrastructure as code (IaC) or continuous configuration automation (CCA) that has seen increased adoption over the past few years.
Most cloud services providers allow customers to provision new resources or cloud instances via machine-readable definition files, or templates, and third-party tools are available that work with multiple clouds.
The data in Accurics' report comes from customer surveys, CISOs and design partners combined with open-source research and the company's own telemetry from analysing hundreds of thousands of cloud resources deployed in real-world environments.
When implemented correctly, IaC templates can strengthen security, because they reduce the possibility of human errors that often occur with manual deployments, especially when many settings are involved. They can be part of the process of shifting security to the left and integrating it earlier in the DevOps pipeline.
However, to get those benefits, organisations must ensure that their IaC templates result in cloud resource configurations that follow best practices and comply with various standards. Unfortunately, that's not always the case.
An analysis by security firm Palo Alto Networks of IaC templates collected from GitHub repositories and other places identified almost 200,000 such files that contained insecure configuration options. Some of the common issues identified included:
- The absence of encryption and logging for data storage
- Services like SSH and RDP directly exposed to the internet
- Credentials that didn't meet industry minimum standards
- Containers without CPU or memory resource limiting
- Cloud storage without secure storage enabled
Accurics found that 67 per cent of the configuration mistakes detected in environments were high-severity risks and included things like open security groups, overly permissive identity and access management (IAM) roles, and exposed cloud storage services.
Over 40 per cent of resources did not meet all the Centre for Internet Security (CIS) critical security controls, 18 per cent did not meet PCI-DSS requirements, 19 per cent were in violation of SOC 2 standards, and 10 per cent of did not meet HIPAA requirements.
"I think that 24 per cent of configurations being made through code is good," Sachin Aggarwal, co-founder and CEO of Accurics, tells CSO. "What is not good is that most of this code gets provisioned into the actual running environment without any initial security risk assessment.
"That creates a problem because now you did start on a good journey of creating your DevOps pipeline and getting your infrastructure-as-code in early. Basically, you're designing your cloud with good intent, but then you're not doing any security assessment early on in the process where you do have an opportunity to implement and embed security into your code."
The cloud configuration drift problem
Making sure that IaC templates contain safe configuration options is only the first step toward a good security posture in the cloud. Continuous monitoring of the deployed cloud resources and instances for any post-deployment configuration changes that could impact their security is also very important.
According to Accurics' findings, posture drift is a common phenomenon seen in over 90 per cent of cloud deployments that were provisioned through code.
"The reality is that privileged users do make changes directly to cloud infrastructure in production without updating the code that was defined to provision it," the company said in its report.
"In some cases, the changes are authorised and legitimate, whereas in other cases, the changes introduce risk. Either way, the cloud posture drifts from the secure baseline defined through code which was intended to be the single source of truth."
For example, the manual addition of more IAM roles than were initially provisioned is a common practice that exists in almost all environments, Aggarwal says. It's also common for privileged users to add a new resource or delete a resource from a running environment.
Accurics found that 77 per cent of the cloud resources that drifted from their secure baseline included instances (37 per cent), application load balancers (19 per cent), security groups (15 per cent) and cloud storage services (5.5 per cent).
The reason for some of these drifts is partly cultural and the result of the work habits of administrators and infrastructure engineers. Just like DevOps itself involves a cultural change, the practice of manually changing configurations without documenting them could decrease in frequency as time goes on as a result of new policies.
However, there are also other reasons for manual changes, including an attacker trying to escalate their privileges, so monitoring running cloud instances and resources for configuration changes will remain important.
The longer it takes to detect an insecure and undocumented configuration change made directly into a running environment, the harder it is to fix or revert it later because other changes might depend on it and because the original intent of the person who made the change might get lost. According to Accurics' report, only four per cent of issues reported in production are being addressed.
"This is unsurprising since tracing an issue back to the developer who misconfigured the infrastructure in question is difficult to do and requires redeployment of the cloud--an expensive proposition," the company said.
A parallel could be made to the code reuse practices that have accelerated modern software development allowing companies and independent developers to more easily create applications by using third-party libraries, components and frameworks.
However, giving developers free reign on which third-party components to use created a vulnerability tracking and patching nightmare for organisations because many don't have a software bill of materials and have lost track of the original reason why a particular version of a particular library was used in a particular application.
The growing use of various container and serveless technologies and different provisioning templates could result in a similar situation. A survey by the Cloud Native Computing Foundation (CNCF) last year found that 41 per cent of organisations were using serverless technologies and 84 per cent of organisations were using containers. This was before the Covid-19 pandemic which most experts believe has accelerated the adoption of cloud computing services.
Accurics also found that more than 80 per cent of organisations use more than one type of infrastructure as code technology, such as Terraform, Kubernetes YAML, Dockerfile and OpenFaaS YAML.
