Building secure applications goes far beyond just building secure code. When we talk about cybersecurity, some of the most important concepts to consider are “Defense in Depth” and “Attack Surface Reduction”.
If we make an analogy to a residence to make the understanding of these concepts easier, defense in depth would be like adding barriers which makes the action of an intruder harder. For example, raising the height of the walls, installing electric fences, changing the padlock for a stronger one, putting bars on the windows, etc.
In the case of attack surface reduction, we can exemplify like the action of reducing exposed points that could be exploited by a malicious agent. It would be something like keeping the car in the garage or keeping the lawnmower and bicycle that were in the backyard to prevent them from being stolen.
But what is Infrastructure as Code (IaS), and what does it have to do with these concepts? Even more, how can it help you — or not — to build and deliver software more securely?
IaC + AppSec
IaC is a practice in which infrastructure is described and managed as code. These scripts can be written in an easy-to-understand language that allows to refer to remote resources and assemble them like a jigsaw puzzle automatically rather than manually.
It is then possible to create and destroy complete server environments, network interfaces, connections, access rules, and information flows with a few commands in a matter of minutes.
Application security (AppSec) is the concept that deals with how to ensure that applications are designed, planned, built, and delivered securely, identifying and mitigating possible threats and vulnerabilities from the initial phase.
IaC can greatly enhance the secure software development lifecycle (S-SDLC) in several ways.
For example:
- Speeds up the development process and reduce manual errors, allowing developers to focus on more important tasks such as security;
- It can be audited and controlled, making it easy to ensure security and compliance policies are being followed consistently throughout the development cycle;
- Enable the creation and replication of consistent infrastructures, which can be used to quickly set up new environments for testing and development, reducing the risk of misconfigurations;
- Enable integration to CI/CD pipelines, facilitating the deployment of applications and updates securely and consistently;
- They can provide greater visibility into the development process, making it easier to track changes and identify potential security issues.
- If we conceptually analyze all the points mentioned above, we will realize that they are all related, in some way, with Defense in Depth and Attack Surface Reduction.
The dilemma presents itself
But at the same time that IaC can bring benefits by avoiding human errors before the recurring need to destroy and rebuild application infrastructure environments, it can also bring security issues.
See some examples:
- Misconfiguration of infrastructure components or misconfigurations introduced during upgrades can lead to security vulnerabilities that can be replicated multiple times, until the time an audit notices the flaw;
- Scripts may contain confidential information such as passwords or private keys which, if not adequately protected, could put the organization’s systems at risk;
- IaC may rely on external software libraries and dependencies, which may contain vulnerabilities or be used to introduce malicious code;
- IaC scripts are stored in version control systems, making them accessible to all authorized users. This can increase the risk of insider threats or accidental exposure of confidential information;
- IaC allows for rapid and automated deployments, which can lead to unintended consequences if changes are not properly tested and audited before deployment.
IaC provides a way to automate and manage the deployment and configuration of infrastructure components in a more secure and replicable way. It can help reduce the risk of security vulnerabilities and improve the security level of applications, since some important points are observed.
Like these below:
- It is necessary to use digital signatures to guarantee authenticity and avoid tampering or code substitution;
- There is a need to use a secret management system to store and manage sensitive information such as passwords and API keys to prevent unauthorized access;
- Another key point is the implementation of role-based access controls to limit access to sensitive information and operations in the CI/CD pipeline;
- It is important that the network is segmented to restrict access to the CI/CD pipeline from outside sources and limit the potential impact of a security breach;
- Encrypting communications between all components in the CI/CD pipeline to prevent eavesdropping and tampering is critical;
- Regular security assessments and penetration testing are required to identify and address vulnerabilities in the CI/CD pipeline;
- The network interfaces must be configured to allow only the necessary traffic for the communication of the different application modules and their data.
The solution to the dilemma
It is now clear that there is a conflict:
The use of Infrastructure as Code helps in the process of building software more securely by adding layers of security, automating the process, and avoiding human error. On the other hand, misconfigurations in infrastructure created by IaC can dramatically expand the attack surface.
The organization must make some important considerations during the evaluation process on the use of IaC, mainly regarding cost/benefit. A rational reflection is necessary on the real need to use this technology, on the costs to maintain it, and if it really is the right time for this change.
Many companies start the process of using IaC without planning and do not pay attention to the impact that the use of these tools can bring in terms of security. They execute these changes thinking about convenience and do not reflect on the consequences for the business.
Others implement Infrastructure as Code thinking about the security that automation can bring, but ignore the size of the new attack surface they’ve just created, much less to everything that will be needed to secure it.
IaC is a technology that needs mature and specialized teams, who constantly think about how to improve their scripts, using the information passed by pentesters and auditors. Therefore, it is a technology that has a high cost.
All of these variables, including the costs of the tools needed to implement IaC solutions, must be considered when deciding whether the organization really is at the right time to start using them.
