CLOUD
Architecture Summit

Enterprise-Grade Integration Across Cloud and On-Premise

REGISTER

June 10, 2021

Online Conference

DevOps: It’s the perfect term for a vital discipline, taking so little space to say so much.

DevOps has come to signify the definitive foundation for cross-disciplinary collaboration. To practice DevOps is to unite multiple and varied technology disciplines, from development to operations, into a singular and coherent entity.  Its impact has become massive, and its  ramifications profound.

For all of DevOps import, the term doesn’t actually go back too far—the first conference dedicated to the function wasn’t held till 2009.

Inside this same abbreviated 12-year timeframe, another impactful technology (and complementary to DevOps) also emerged. It is also known by a perfectly crisp term: IaC – or Infrastructure as Code.  

The term IaC has joined the vernacular of IT as organizations increasingly leverage automation tools—think Terraform, Kubernetes YAML, Dockerfile, and OpenFaaS YAML—they looked to provision and manage such technologies through code: hence, Infrastructure as Code, or IaC.

Over the years, the benefits of IaC have proven undeniable:

The code is more flexible and easier to manage, many tasks can be easily automated, and a code-based infrastructure enables embedded security throughout the process and boosts a multi-tiered defense strategy. As this simple concept continues to gain traction for formalizing the entire production environment in its software incarnation, it has the potential to fundamentally revolutionize the development process.

With Infrastructure as Code (IaC) Be Sure You Know, Manage Risks

But right alongside IaC’s plentiful gains, there are also distinct risks. Managing these risks effectively can spell the difference between success and failure.

So, let’s understand the scale and nature of the issue, and look at some examples of IaC risk/rewards. Then we can better understand how to end up on the right side of the equation:

• First, IaC is only as simple, or as complex, as the developer intends it to be, and this makes subsequent management more problematic. This is thanks in part to the same flexibility that it counts as a major benefit.
• For its part, automation has its downsides too. Even simple mistakes can be amplified without human awareness, and such mistakes can reach disaster-level with unfortunate speed.
• Finally, IaC broadens the attack surface—the same problems we see with cloud management—and causes greater potential risks.

Recent headlines informed the IT community about multiple breaches, successful or otherwise. These offer stark testimony that attackers are constantly developing new tactics to take on the cloud.

One research report suggests that misconfigured cloud storage services are commonplace in 93% of cloud deployments, and most also have at least one network exposure where a security group is left wide open. These problems have helped lead to more than hundreds of breaches in just the past few years.

There are other vulnerabilities. In the notable case of the Twilio hack last summer, the intruders gained access to the javascript code for the TaskRouter SDK that allows Twilio customers to integrate incoming phone call routing. Since the cloud storage service was publicly writable, the invaders were able to modify the code. Fortunately, the change was not malicious. . .this time.

We’re also finding new policy violations become commonplace: For example, hardcoded keys get stored within computing environments, which is partly how we got the Imperva breach a couple of years ago.

How Best To Balance IaC’s Benefits and Risks

Within this context, what’s the best way to find common ground? How can we derive the clear benefits of IaC within DevOps without falling prey to the problems?

We’re all familiar with policy guardrails such as encrypted databases, rotated access keys and multi-factor authentication. There are also solutions available to detect IaC risks across the cloud native stack. However, implementing these and other measures in runtime isn’t particularly effective—the risk posture often drifts when users take advantage of the flexibility to make configuration changes directly to the cloud.

This is where the blessing of Infrastructure as Code can be extended: IaC enables organizations to codify policy checks earlier in the development lifecycle.

To accomplish this, the IaC must become the single source of truth. In addition, the cloud infrastructure must be continuously monitored in runtime for configuration changes and assessed for risk.

When even a “privileged user” makes a “legitimate” configuration change, the IaC must be remediated to reflect the good change and a new baseline established. Otherwise, the next time that the cloud infrastructure is deployed using IaC, the change will be overwritten.

In situations where the configuration change introduces a risk, the cloud infrastructure must be redeployed based on the secure baseline defined through IaC. This way, any risky changes made accidentally or maliciously are overwritten.

This moves us forward from “Infrastructure as Code” to what is coming to be known as “Policy as Code,” a holistic approach that secures infrastructure as code during development, and ensures that the secure posture is maintained even after cloud infrastructure is provisioned.

But let’s go even further:

Detecting issues without helping to resolve them only shifts the “noise” (alert fatigue) from runtime to development. In fact, there are many stories of developers becoming inundated with alerts about policy violations. Each must be assessed and dealt with, and that effort drains time. Eventually, only 6% of issues get remediated. 

This is why Policy as Code needs to go one more level – to be associated with technology that can do more than provide alerts to an IT team. Enter: Remediation as Code.

In essence, Remediation as Code takes the posture that the code to remediate relevant issues should be checked into the repository. In this way, developers only have to review and merge the code to the main branch to resolve emerging problems. Once all issues have been resolved in the code, a secure baseline must be established, which significantly reduces the attack surface before the cloud infrastructure is provisioned.

It’s a straight line from development to benefit: Automated detection and response of misconfigurations in cloud infrastructure that enables security at the speed of DevOps.

In sum, we know that marrying DevOps to IaC offers major benefits, but the truest and most impactful benefits come only when security is codified into development pipelines and enforced throughout the lifecycle.

Policy checks and breach path detection should be codified across Infrastructure as Code to identify risks before cloud infrastructure is provisioned; and remediation must be codified into the development pipelines to address the risks before cloud infrastructure is provisioned. That way we get the benefits without the dangers.

Accurics, the cloud cyber resilience specialist. Prior to Accurics, he was CSO at AutoGrid, where he achieved NERC CIP attestation for GovCloud. Om also served as head of cyber security for General Electric’s Industrial Cloud and Edge platform, Predix and while at CipherCloud architected the world’s first Cloud Access Security Broker (CASB) product.