Looking to make it easier for security teams to detect and remediate misconfigurations early in the development cycle, Qualys this week announced that it would add infrastructure as code (IaC) scanning to its CloudView app.
We caught up with the company’s president and CEO Sumedh Thakar to learn more about IaC, how to manage it securely, and why Qualys identified misconfigurations as a major pain-point for development teams.
What are the challenges enterprises face in securing their cloud operations?
Thakar: Enterprises face many challenges when it comes to securing cloud operations – everything from a lack of qualified staff to justifying spending on security programs. However, most companies have a hard time establishing consistent security policies and oversight. Security teams are usually organized horizontally, but DevOps teams in most organizations are segregated by business functions. As a result, there’s very little collaboration or standardization between them and each team uses a distinct set of tools and cloud services in addition to having varying levels of expertise across different clouds.
Many of the individuals on DevOps teams are not trained or aware of security best practices. This creates a hole in the organization’s overall security posture and makes it difficult for security teams to develop and enforce security policies. Unfortunately, there’s no silver bullet for this problem. However, organizations can achieve better overall posture by embedding and automating security throughout the application cycle – development, deployment and post-deployment.
Can you give a brief definition of infrastructure-as-code?
Thakar: The most common way to provision infrastructure such as storage buckets, databases and firewall rules in the cloud is by using either console or the command line interface offered by the cloud provider. Essentially, IaC offers another way to provision the infrastructure, but by using code instead.
There are two major advantages to IaC. First, it ensures consistency in configuration. For example, if developers need to create an S3 that’s private and encrypted and they choose to complete this using a console or CLI, there’s a high chance that the operator may miss a step. However, doing this in code ensures that the S3 bucket always gets created with the specified configuration. Developers also like the ability to version the code. If there’s any change in the configuration, the developer can figure out exactly who changed the code and when it was done just by looking at the version history of the code. Think of IaC as a continuation of the DevOps practices now applied to provision infrastructure-as-a-service (IaaS).
So how can development teams secure IaC?
Thakar: IaC deployments are just as prone to security misconfigurations as manual configurations. To continue with the previous example of the S3 bucket – by making the S3 bucket private and encrypted, has it been secured? No. Access logging was not enabled and block public access settings and versioning were not set. Eight other configuration settings that should have been appropriately set to secure this bucket properly were not applied. IaC security assists DevOps teams in catching security errors before they provision the infrastructure, using an insecure IaC template.
How can IaC security help solve the issues enterprises face when trying to secure their assets in the cloud?
Thakar: For the last several years, the Verizon DBIR report has identified misconfigurations – errors that are unintended actions by an internal party – as one of the top reasons for data breaches. We have seen this come to fruition in the regular cadence of news around data leakage because of storage buckets or databases that were mistakenly left accessible without passwords or encryption.
Cloud Security Posture Management (CSPM) tools are typically used to secure public clouds. CSPM tools use the cloud service provider’s API – a source of truth for a cloud infrastructure – to report whether the configuration of the company’s resources meets the best practices prescribed by various industry groups. However, CSPM tools – while effective – often cannot prevent misconfigurations from creeping up in production environments. This happens because CSPM tools are reactive: they detect misconfigurations after the resource gets created with an insecure configuration. This presents an opportunity for hackers to potentially exploit the misconfigured resource in the timeframe from when it was misconfigured to when it’s detected and fixed. For organizations with stringent change policies, the time between the detection and remediation can take several days or up to several weeks.
Traditional CSPM tools catch these problems far too late in the cycle. So, we prevent misconfigurations from happening in the first place and fix the issues at the source. In many cases, this means fixing the misconfigurations in the IaC template used to create the resources. The question then becomes how to prevent the deployment of this template. The answer? Shift security left and embed security automation at each stage of the CI/CD process with built-in automated assessments. Development teams should perform IaC assessment throughout the pipeline – on the source code when it’s checked into the source code repository, during the integration phase, and before deployment.
What kind of realistic return on investment can companies expect from IaC security?
By assessing the security posture earlier in the development cycle, companies can dramatically reduce security risk post-deployment. Organizations can also gain cost savings via security automation.
