With ever-increasing application architecture complexity, infrastructure-as-code is your key to boosting your cloud security posture.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
IaC scripts should get similar treatment as any application software. A secure SDLC, access control, testing using PaC, and secure deployment must be part of IaC security strategy. This helps in application security as well as data protection. As businesses are adopting the cloud more and getting into complex, multi-cloud architecture, reusable, modular, hardened IaC patterns are the best way to manage growing demand.
Monika Chakraborty is a security consultant at Synopsys. Monika has 20+ years of experience in a variety of roles including developer, team lead and project manager. She currently works with customers in multiple industries on vulnerability assessments, secure code reviews and strategic planning in secure development. She has been CSSLP certified since 2013 and has been an eCPPT (eLearnSecurity Certified Professional Penetration tester) since 2012. Monika focuses on software security initiatives that help businesses to improve secure development processes.