Infrastructure-as-code templates are source of cloud infrastructure weaknesses – TechCentral.ie

(Image: Stockfresh)

High percentage of IaC template misconfigurations in cloud deployments vulnerable to attack

Print

Read More: GitHub Infrastructure infrastructure as code Palo Alto Networks security

In the age of cloud computing where infrastructure needs to be extended or deployed rapidly to meet ever-changing organisational needs, the configuration of new servers and nodes is completely automated. This is done using machine-readable definition files, or templates, as part of a process known as infrastructure as code (IaC) or continuous configuration automation (CCA).

A newanalysis by researchers from Palo Alto Networksof IaC templates collected from GitHub repositories and other places identified almost 200,000 such files that contained insecure configuration options. Using those templates can lead to serious vulnerabilities that put IaC-deployed cloud infrastructure and the data it holds at risk.

Just as when you forget to lock your car or leave a window open, an attacker can use these misconfigurations to weave around defences, the researchers said. This high number explains why, in a previous report, we found that 65% of cloud incidents were due to customer misconfigurations. Without secure IaC templates from the start, cloud environments are ripe for attack.

There are multiple IaC frameworks and technologies, the most common based on Palo Altos collection effort being Kubernetes YAML (39%), Terraform by HashiCorp (37%) and AWS CloudFormation (24%). Of these, 42% of identified CloudFormation templates, 22% of Terraform templates and 9% of Kubernetes YAML configuration files had a vulnerability.

Palo Altos analysis suggests that half the infrastructure deployments using AWS CloudFormation templates will have an insecure configuration. The report breaks this down further by type of impacted AWS service Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (RDS), Amazon Simple Storage Service (Amazon S3) or Amazon Elastic Container Service (Amazon ECS).

For example, over 10% of S3 storage buckets defined in templates were publicly exposed. Improperly secured S3 buckets has been the source of many publicly reported data breaches in the past.

The absence of database encryption and logging, which is important to protect data and investigate potential unauthorised access, was also a commonly observed issue in CloudFormation templates. Half of them did not enable S3 logging and another half did not enable S3 server-side encryption.

A similar situation was observed with Amazons Redshift data warehouse service. Eleven percent of configuration files produced Redshift instances that were publicly exposed, 43% did not have encryption enabled, and 45% had no logging turned on.

Terraform templates, which support multiple cloud providers and technologies, did not fare any better. Around 66% of Terraform-configured S3 buckets did not have logging enabled, 26% of AWS EC2 instances had SSH (port 22) exposed to the internet and 17% template-defined AWS Security Groups allowed all inbound traffic by default.

Other common misconfigurations found in Terraform templates include:

Kubernetes YAML files had the smallest incidence of insecure configurations, but those that did were significant. Of the insecure YAML files found, 26% had Kubernetes configurations that ran as root or with privileged accounts.

Configurations allowing containers as root provide attackers with an opportunity to own virtually any aspect of that container, the Palo Alto researchers said. This also makes the process of performing container escape attacks easier, thus opening the host system to other potential threats. Security and DevOps teams should ensure that containers do not run with root or privileged accounts.

The types of IaC template misconfigurations and their prevalence the absence of database encryption and logging or publicly exposed services is in line with the type of issues detected by Palo Alto Networks in real-world cloud infrastructure deployments in and covered in past reports:

This suggests that the use of IaC templates in automated infrastructure deployment processes without first checking them for insecure configurations or other vulnerabilities is a big contributing factor to the cloud weaknesses observed in the wild.

Cybercriminal groups often target cloud infrastructure to deploy cryptomining malware that takes advantage of the processing power paid for by the victims. However, some of these groupsare also venturing beyond cryptomininganduse hacked cloud nodes for other malicious purposes.

It is readily apparent that attackers are using the default configuration mistakes implemented by weak or insecure IaC configuration templates, bypassing firewalls, security groups, or VPC policies and unnecessarily exposing an organisations cloud environment to attackers, the Palo Alto researchers said. Shift-left security is about moving security to the earliest possible point in the development process. Organisations that consistently implement shift-left practices and procedures within cloud deployments can quickly outpace competitors. Work with DevOps teams to get your security standards embedded in IaC templates. This is a win-win for DevOps and security.

IDG News Service

Read More: GitHub Infrastructure infrastructure as code Palo Alto Networks security

Originally posted here:
Infrastructure-as-code templates are source of cloud infrastructure weaknesses - TechCentral.ie

Related Posts

Comments are closed.