5 More Security Risks for Infrastructure-as-Code
Accurics sponsored this post.
Provisioning and managing cloud infrastructure through code — such as Terraform, AWS Cloud Formation templates, Azure Resource Manager templates and Kubernetes YML files — enables agility. It also provides an opportunity to embed security earlier in the development lifecycle and reduce the attack surface before infrastructure is provisioned. In order to enforce the right security controls, it is important to understand the top risks associated with infrastructure as code (IaC).
In our Top 5 IaC Risks post, we discussed five of those risks; in this follow-up post, we outline an additional five risks you should be aware of.
6. Compliance Violations
Many organizations that leverage cloud infrastructure are mandated to comply with a number of regulatory standards, such as GDPR, HIPAA, PCI, and SOC2. If policy guardrails based on these standards are not enforced on IaC, compliance failures will result. For example, SOC2 requires that an IAM password policy exists; so a policy guardrail should be implemented to ensure this is enforced in IaC (example below).
Some standards also require that IaC templates are assessed during the continuous integration (CI) and continuous deployment (CD) phase, such that policy violations result in the deployment being blocked.
Tip: Perform compliance checks on infrastructure as code (IaC), including assessment of builds to ensure cloud deployments are compliant from the get-go.
7. Data Exposures
Configuration of cloud storage infrastructure is a critical element of ensuring data security in the cloud. For example, databases or cloud storage services — such as Amazon Elastic File System and Amazon S3 — that are created without enabling encryption can pose risks (illustrated in the code below). While encryption is just one aspect of data security, there are a number of other misconfigurations that can create data exposures in the cloud. Automating storage infrastructure provisioning and managing through code (IaC) can exacerbate these issues.
Tip: Assess data security-related configurations in infrastructure as code and remediate them early in the development cycle.
8. Hardcoded Secrets
Hardcoded secrets or credentials is a common malpractice that involves storing plain text credentials, such as SSH keys or account secrets, within source code (sample code snippet below). This risk can enable unauthorized privilege escalation and lateral movement during a breach. It is very difficult to trace and contextualize hardcoded secrets in runtime environments. Unfortunately, provisioning and managing infrastructure through code makes it easier to hardcode secrets within it.
Tip: Scan infrastructure as code for hardcoded secrets and remediate issues before cloud infrastructure is provisioned.
9. Disabled Audit Logs
Audit logs play a critical role in assessing the security risks of sensitive or classified assets, as well as in the investigation of the root cause of incidents. Well-known examples of audit logging services are AWS CloudTrail and Amazon CloudWatch. This capability should be enabled when cloud infrastructure is provisioned. It is easy to omit this configuration when automating the provisioning of infrastructure through code, as illustrated by the code below.
Tip: Enable audit logs to enhance the security monitoring process and aid the identification of the threats.
10. Untrusted Image Sources
IaC templates are used to build environments that deploy and run code from external sources. However, these templates may inadvertently refer to OS or container images from untrusted sources. This can introduce security risks such as backdoors, man-in-the-middle attacks, malware, and crypto miners.
Tip: Scan IaC templates for image sources/registries and ensure that images are trusted and digitally signed.
Feature image by Alex Brylov via Shutterstock.