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.
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.
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.