Improve Your Cloud Security Posture with Infrastructure as Code
Cloud services like software-as-a-service apps, data storage and media streaming, are becoming more common, which makes application architecture more complicated. Not all applications are easy to move from a local server to the cloud. Most of the time, “lifting and shifting” apps don’t work, and apps need to be redesigned to make the best use of cloud resources. This is made even more complicated by multicloud and hybrid cloud situations. To deal with this problem, organizations need a well-documented security plan, not just for applications, but also for managing the underlying platform.
Infrastructure as Code (IaC) lets you define cloud-based systems in a declarative way, and it can be treated just like the application code that runs on it. A cloud security plan should include a safe system development life cycle for code-based design, development, testing and deployment to the cloud.
Why You Need a Secure SDLC for IaC
Although the cloud is not a new technology anymore, it is still maturing. Cloud-service providers offer new services based on clients’ demand, 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 repositories and more.
Resource Misconfigurations
Cloud resource misconfiguration is 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. SSH ports are used for the 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 those 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 the way organizations think about building and securing infrastructure because it means that 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 using secure guiding principles that are derived from business requirements as well as regulatory compliance requirements. The first step must be the development of an IaC security strategy. This strategy must specify how security is embedded at each stage, from development to deployment, as well as at runtime.
For example, during code development, integrated development environment (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 into a CI/CD pipeline at runtime to enforce PaC.
Use Tags
Tags for resources can be used to set the context of a resource. Doing so 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 are 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:
- 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 other cloud resources or components.
Conclusion
IaC scripts should get similar treatment as any application software. The IaC security strategy must have a secure SDLC, access control, testing using PaC and secure deployment. This helps in application security as well as data protection. As businesses are adopting the cloud more and getting into complex, multicloud architecture, reusable, modular, hardened IaC patterns are the best way to manage growing demand.
How Synopsys Can Help
Synopsys 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.
