New research by infrastructure-as-code provider Accurics Inc. has found that poorly configured and managed cloud services – mostly resulting from the use of default security profiles or overly permissive configurations – continue to threaten the security of cloud development projects.

The research indicates that the misconfiguration issues that created headlines two years ago following numerous incidents of data being left exposed on public-facing servers have yet to be resolved.

At issue is default security settings, which vary by cloud platform. Developers can easily overlook the need to change default settings or make changes at the runtime level that are at odds with those at the IaC layer, leaving an opening for attack.  Accurics conducted the research by scanning more than 1,800 security policies of cloud instances managed by its own products and open source configuration managers.

The findings – which have changed little since the company released its first report nearly a year ago  – indicate that organizations still have work to do training their developers in the security nuances of IaC, an increasingly popular approach to running enterprise cloud environments that uses scripts to automate processes that were previously done by hand. Automation improves efficiency by allocating resources according to demand, but it also introduces risk because scripts can’t anticipate every potential failure and breach scenario.

Shared risk

Developers who are familiar with working on-premises environment may be unaware of the vulnerabilities introduced by shared infrastructure and let their guard down, said Om Moolchandani, Accurics’ chief technology officer.

For example, an attacker who takes over one server in a data center won’t necessarily be able to find others that aren’t on the same subnetwork, Moolchandani said, but misconfiguration problems in the cloud can make it possible for attackers to define the network to suit their purposes. “The benefit of cloud is the ability to configure at scale and, unfortunately, that works to the attackers’ advantage as well,” he said.

Researchers found that the mean time to remediation of configuration errors is 25 days, giving attackers plenty of time to expand their presence. That expands to 149 days for violations of application load balancers and elastic load balancers, which handle most of the user interaction with the cloud back-end services.

“One surprising finding of our research is that the most critical parts of our infrastructure, which we need to keep the most secure, often require the most time to fix,” the report says.

Policy drift

One new complexity IaC has introduced is the risk that changes made directly to a runtime configuration instead of at the IaC layer can cause the two security policies to get out of whack, a phenomenon called “drift.”

These inconsistencies take an average of nearly eight days to detect and five days to fix in production, the report says, although drift problems have been known to go undetected for as long as five years. “As more IaC is adopted, drifts will be reduced. These are the pain points in the learning curve,” Moolchandani said.

The long remediation times for load-balancing problems reflect the fact that load balancers are critical to nearly everything an organization does in the cloud. “Organizations can’t have downtime on load balancers so the window of opportunity [for remediation] frequently isn’t available,” Moolchandani said.

Kubernetes risks

The report also raises an alarm about Kubernetes, the popular orchestrator for the self-contained software modules called containers. Nearly half of the Kubernetes security failures researchers identified were caused by insecure default configurations with improper use of the default namespace being the most common mistake.

“User components should not run in the default namespace in order to segregate them from those system components,” the report says. “If a user component running in the default namespace were compromised, attackers could gain access to the system components or secrets.”

Kubernetes users who implement role-based access controls can also fail to define those roles at the proper granularity, resulting in too few roles having too many permissions,” a mistake that was present in about 35% of Kubernetes security failures.

“The problem is that Kubernetes is designed to host applications and the intention [of Kubernetes developers] is to provide a smooth experience on day zero,” Moolchandani said. “If these hardening features were turned on by default the applications would require additional testing. That’s one philosophical reason the Kubernetes community doesn’t enable these features automatically.”

Photo: Unsplash