Can Immutable Infrastructure Make Cloud Self-Healing?

Agility can be considered one of the cloud’s best features, but also one of its worst since the transient nature of the infrastructure makes securing it a moving target. Piyush Sharrma, co-founder and CTO at Accurics says infrastructure should be immutable, and the only way to secure it is through immutable security.

One of the best things about cloud computing is the agility because organizations can scale up or down, add new technologies and even switch between providers with relative ease. One of the worst things about cloud computing is the agility because the transient nature of the infrastructure makes securing them a moving target. It’s a singularly odd characteristic about the cloud, and perhaps not the only one.

For example, many enterprises have taken full advantage of the benefits offered by this paradigm to regularly add new technologies to the mix. Cloud stacks now feature serverless, containers, service mesh and more. Programmable infrastructure gives organizations the freedom to develop and deploy applications significantly faster than was previously possible —  researchOpens a new window reveals that nearly a quarter of all infrastructure is defined and managed programmatically. In fact, there is a fundamental belief that infrastructure should be immutable such that modifications to configurations should not be made after deployment; changes should only be made programmatically, assessed for risk, and the infrastructure should be redeployed with the changes.

Learn More: Accurics Touts Best Practices to Strengthen Cloud Infrastructure Security

Why Cloud Security Is So Hard 

And yet, the reality is quite the contrary — our studiesOpens a new window indicate that the vast majority of organizations, perhaps 90%, give privileged users the necessary access to make manual configuration changes directly to cloud infrastructures during runtime. Some changes may be necessary from an operational perspective, others may inadvertently introduce risk. While organizations are beginning to use runtime monitoring tools to alert for risk, only 4% of cloud misconfigurations reported in production are being addressed.

This is neither benign neglect nor criminal intent. Addressing the potential risks means tracing an issue back to the code that defined the original infrastructure configurations, and that’s a steep hill to climb. And so the problems continue to mount: Some 30 billion-plus records have been exposed through cloud misconfigurations in just the past two years.

The full potential of cloud adoption will never be realized until this dichotomy is addressed. There’s only one way to do that: match the immutable infrastructure with immutable security.

Given that the key to agility and danger alike lies in the code used to provision and manage the infrastructure (Infrastructure as Code – IaC), it must be imperative to secure the code. The only way to ensure that security does not hamper agility is to programmatically assess the code for risks —  think of it as Security as Code. However, programmatically detecting risks can quickly inundate developers with alerts.

Learn More: Why IT Security Teams Are Gravitating Toward No-Code

Code Drives Immutability 

There must also be a way to programmatically resolve the risks in the IaC through Remediation as Code — the perfect accompaniment to Security as Code. As soon as misconfigurations are identified, developers must be notified and given the code to remediate the issue. This can be done with an automatic “pull request” or “merge request” to replace the risky configuration with an appropriate alternative. Developers are able to review each recommendation and merge legitimate changes into the code to resolve the issue. We still have the agility, but now there’s early visibility into and mitigation of risks as well. The IaC is established as the secure baseline, the cloud infrastructure is deployed from the IaC, and the risk exposure is dramatically reduced.

The second part of the challenge lies in ensuring that the secure posture of the cloud infrastructure is maintained over time despite users making manual configuration changes in runtime. For that to happen, the IaC must become the single source of truth. Essentially, the cloud infrastructure must be continuously monitored in runtime for manual configuration changes that deviate from the secure IaC baseline and assessed for risk. 

For legitimate changes, developers are notified of the change and provided with the code to update the IaC and establish a new secure baseline. With risky changes, developers are notified and the cloud infrastructure must be redeployed using the existing secure baseline defined through IaC. As a result, problems introduced through malice or accident are overwritten. This closed loop approach ensures that the risk posture of cloud infrastructure is always defined through IaC and does not mutate due to manual configuration changes in runtime, enabling immutable security.

Done right, immutable security provides a new way to achieve self-healing cloud infrastructure in which misconfigurations are identified and resolved in an expeditious manner. It ensures that detection and remediation is embedded in the development lifecycle, not added on as an afterthought. This is the best recourse yet to secure immutable infrastructure.

Comment below to let us know if you liked this article or tell us on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you