Improving cloud security posture with infrastructure-as-code

The growing popularity of cloud services such as SaaS applications, data storage, media streaming, and more brings with it an increase in application architecture complexity. Applications are not always easily portable from on-premises to the cloud. “Lifting and shifting” applications does not work in most cases, and applications often need to be re-architected to make best use of cloud resources. Multi-cloud and hybrid cloud scenarios complicate this even further. To tackle this issue, organizations need a well-documented security strategy, not only for applications, but also for managing the underlying platform.

Infrastructure-as-code (IaC) offers the capability of declaratively defining cloud-based architectures, and it can be treated the same as the application code running on it. A cloud security strategy should include a secure system development life cycle (SDLC) for IaC design, development, testing and deployment to the cloud.

Why you need a secure SDLC for IaC

Black Duck helps organizations improve their cloud security posture by assessing the maturity of their cloud adoption processes and proposing a roadmap of activities. In most cases, we find that organizations lack a robust documented process for cloud infrastructure deployment.

Although the cloud is not a new technology anymore, it is still maturing. Cloud services providers offer new services clients demand them, and that can make it hard at times to keep up with the level of change. Without a documented and approved plan, all activities can happen on an ad hoc basis. This lack of proper process can lead to resource misconfigurations, insecure access, disclosure of secrets in code in repository, and more.
 

Resource misconfigurations

Cloud resource misconfigurations are one of many threats in cloud infrastructure that can lead to business risks. For example, if a network security group with an Azure-based architecture has a rule that allows anyone on the internet to access an Azure VM using the SSH port, that channel can be used to access any cloud resource that the VM has access to. SSH ports are used for administration of cloud-based architecture, so opening this channel to the internet increases the attack surface.
 

Open source components

Modern cloud applications are developed using mostly open source libraries. If any of these software components include vulnerabilities, the application itself becomes vulnerable. Using these components in an application increases the attack surface for hackers.

These applications are packaged with a base image to run on containers or virtual machines, and threat actors try to exploit the vulnerabilities to access the underlying host machines. Scanning the base images and application images stored in repositories and registries can help detect vulnerabilities.
 

Insecure access permissions

The IaC deployment pipeline should be secured to ensure cloud platform integrity as well as the security of the applications running on it. For example, access to overly permissive credentials contributes to continuous integration pipeline poisoning.
 

Improving security posture

IaC has changed how organizations think about building and securing infrastructure. The applications as well as the underlying platform can be software-defined and version-controlled, include automated security checks through policy-as-code and guardrails like manual approvals, and have vulnerabilities remediated before deployment.

Developing secure SDLC processes for IaC

Like any application and system development, cloud-based architectures need to be designed following secure guiding principles that are derived from business requirements as well as regulatory compliance requirements. Development of an IaC security strategy is the most important milestone and first step.

The strategy must specify how security in embedded at each stage, from development to deployment, as well as at runtime. For example, during code development, integrated development environments (IDEs) plugins can identify resource configurations that violate a security policy. Developers can immediately make changes in the code before committing to the code repository.

An IaC secure SDLC process must ensure that cloud resources are securely configured before they are provisioned. Code and patterns should be designed to ensure that they are reusable, maintainable, auditable, and scalable. Secure coding guidelines must be developed to help developers know what security controls should be embedded in code for security to be built in.
 

Implement checks against security policies

Automated security checks can be embedded in repositories, deployment pipelines, and at runtime to avoid the need for manual checks against policy requirements. This is known as policy-as-code (PaC). PaC can perform security checks quickly and without the risk of human error. It can also be version controlled just like IaC and application code. If the platform engineering team, for example, is responsible for developing IaC, a team such as the information security team should be responsible for developing and deploying PaC. Native tools provided by cloud service providers such as Azure Policy may be adopted for PaC implementation support. Alternatively, third-party cloud-native application protection plan (CNAPP) tools such as Orca can be plugged in to a CI/CD pipeline at runtime to enforce PaC.
 

Use tags

Tags for resources can be leveraged to set the context of a resource. Doing do helps ensure that resources are configured appropriately. For example, if an S3 bucket is holding public data, it may not need encryption and may be publicly accessible.
 

Guardrails

To ensure that the development and deployment process of IaC is secure by design, security guardrails must be implemented. These controls detect any drift or deviation from the expected outcome and prevent it. They also provide vulnerability and recommendation feedback to development teams, which can then make necessary changes to mitigate the vulnerability. This is done using automation, reducing the chance of manual error and improving security, since development teams will not be allowed to bypass any security policies embedded in the pipeline. Any policy exception, then, must go through a manual review process and be recorded.

Some examples of these guardrails are

• Store IaC files in a central trusted repository or registry where code scans can be implemented, and prevent tampering of code stored in the repository.
• Consider the repository the only trusted source to the CI/CD deployment pipeline.
• Restrict access to both the repository and the pipeline to ensure that security policy code can’t be changed due to unauthorized access.
• Follow the rules of least privilege and separation of duties for repository, registry, and pipeline access permissions to ensure that users are granted only enough permission to perform the tasks appropriate to their role.
• Implement two-factor authentication where possible.
• Establish the policy-as-code approach in the pipeline to identify any misconfiguration.
• Harden all virtual machine images as well as the base image for containers.
• Perform scans to identify insecure software components in images.
• Establish a manual review and approval process for the pipeline.
   

Secure third-party tools

Security scans in CI/CD pipelines typically use third-party open source tools. It is good practice to use a licensed product plugged into the pipeline. Ensure the tools have enough permission to scan the code but are not allowed to access any other cloud resources or components.