- Software Development
- Top 5 Security Risks for Infrastructure-as-Code – InApps 2022
Top 5 Security Risks for Infrastructure-as-Code – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Top 5 Security Risks for Infrastructure-as-Code – InApps in today’s post !
Read more about Top 5 Security Risks for Infrastructure-as-Code – InApps at Wikipedia
You can find content about Top 5 Security Risks for Infrastructure-as-Code – InApps from the Wikipedia website
Accurics sponsored this post.
Piyush is co-founder and chief technology officer at Accurics. He is a technologist, entrepreneur, and engineering leader with almost 20 years of experience building large-scale IaaS, endpoint, and data center security products. During his career, he has been an entrepreneur and co-founded multiple technology startups.
Infrastructure as Code (IaC) technology is increasingly being adopted by organizations to provide capabilities to rapidly provision and deploy cloud environments. Examples of IaC technologies include Terraform, AWS Cloud Formation templates, Azure Resource Manager templates, Chef, Puppet, Red Hat Ansible, Helm Charts, Kubernetes YML files, and OpenFaaS YML.
With the power of IaC comes the responsibility of managing security risks, which can be introduced if best practices are not followed. Insecure IaCs result in insecure cloud environments that could ultimately lead to compliance violations and data breaches in the cloud. According to the most recent Verizon Data Breach Investigation Report, cloud misconfigurations was one of the top reasons for incidents and breaches.
So what are the top security risks that are introduced due to insecure usage of IaC? In this post, we will take a look at the top five and follow up with the remaining in a subsequent article.
1. Network Exposures
Insecure IaC configurations can expand the attack surface, which enables reconnaissance, enumeration, and sometimes even the delivery of cyberattacks to a cloud environment. Configuring open Security Groups, publicly accessible cloud storage services, public ssh access, and databases that are accessible from the internet, are examples of common IaC misconfigurations that increase the attack surface in the cloud. Below is a sample IaC snippet that highlights code with these issues.
Tip: Perform static security analysis of IaC and eliminate risks early in the cloud deployment lifecycle. Detecting and fixing these issues early is highly cost-effective and reduces your residual risks.
Today, IaC templates are used to provision compute and containerized instances by including base images stored in trusted registries. This presents an opportunity to detect and address any known vulnerabilities in such base images early and dramatically reduce the cost of remediation. The following examples illustrate the use of vulnerable AMI and Docker images.
Tip: Perform vulnerability assessment of images referred to within IaC files and detect vulnerabilities early in the development lifecycle.
3. Unauthorized Privilege Escalations
Today, IaC is used to provision full-stack cloud environments that may include Kubernetes, containers, and microservices. Developers often use privileged accounts to provision cloud apps and other layers, which introduces risk of privilege escalation. If this risk is combined with hard-coded secrets and network exposures, a serious breach path is exposed to attackers.
Tip: Ensure least privileges principles are enforced in IaC and detect privilege creeps in IaC.
4. Configuration Drifts
While developers might be following IaC best practices, an urgent situation may force an operations team to make a configuration change directly in the production environment. This behavior breaks the immutability of cloud infrastructure which is based on the premise that infrastructure is never modified after it is deployed. If something needs to be updated, fixed, or modified in any way, new infrastructure has to be provisioned through code. More importantly, the configuration change may introduce risk which results in the posture of the cloud drifting from the secure posture defined through IaC before the infrastructure was provisioned.
Tip: Maintain immutability of infrastructure by monitoring for posture drifts between provisioned cloud infrastructure and IaC, and mitigate changes that introduce risks.
5. Ghost Resources
Tagging of cloud assets is a critical requirement to ensure compliance and governance. Untagged resources built using IaC result in ghost resources that can cause challenges in detecting, visualizing, and gaining observability within the actual cloud environment. The result is cloud posture drifts that can go undetected for long periods of time, as well as challenges in remediating risks. Aside from the security ramifications, untagged resources also make it extremely difficult to detect the impact on operations such as cost, maintenance, and reliability.
Read next: 5 More Security Risks for Infrastructure-as-Code
Feature image by PHOTOCREO Michal Bednarek via Shutterstock.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.