Virtualization Technology News and Information
Article
RSS
Avoid this Mistake with Infrastructure as Code Security

By Josh Stella, Co-Founder and CEO of Fugue

Shifting security earlier in the software development lifecycle (SDLC) pays real dividends for cloud engineering teams, not just in terms of improved security, but in terms of speed, efficiency, and savings. The economics of shifting security left can be substantial because remediating security issues in the development phase is a lot easier and faster than addressing them in runtime.

But until recently, the shift left movement was predominantly focused on application security with tools to empower developers to automatically check the security of their code and get helpful feedback to fix issues quickly and move forward. Cloud security remained a runtime exercise because it lacked a true development lifecycle to shift security into. 

Cloud Infrastructure now has a Development Lifecycle 

Infrastructure as Code (IaC) tools such as Terraform and AWS CloudFormation changed this equation. We can now express cloud infrastructure as code (or, more specifically, configuration files) and provision or modify cloud environments programmatically. 

Cloud infrastructure now has its own development lifecycle-and naturally IaC security has become a top priority for cloud teams. This is an opportunity to catch resource misconfiguration pre-deployment and address the number one cause of cloud-based data breaches. Considering the typical cloud engineering team is investing 50 or more hours per week to cloud security, the opportunity to shift that burden into the development phase can have a big payoff.

But there are some unique aspects to cloud infrastructure, and failing to recognize this can lead one to make some dangerous assumptions when adopting IaC security. Unlike other layers of the cloud tech stack where risks due to runtime mutation is small (application code) or non-existent (Docker containers), the risk of runtime mutation (or drift) with cloud infrastructure remains extremely high, even when IaC is used extensively and IaC security is effective. 

IaC Security Requires Full Context

Identifying cloud vulnerabilities requires the full context of the environment, and an IaC template typically only defines one component of a larger environment. It's not uncommon for dozens of IaC templates to be employed for a single environment. It's great when we can provide cloud developers with tools that help them check and fix their IaC templates before commit, but this approach will only catch some issues.  

A cloud resource configuration may be safe in one context and dangerous in another. For example, an IAM policy with S3.list.* isn't intrinsically dangerous, but when it gets associated to an EC2 compute instance it becomes a major vulnerability. The ability to check Terraform plan files, which are essentially "compiled" output from Terraform HCL files, can help catch some vulnerabilities that checks on HCL may miss. But only by checking the runtime cloud environment can you be sure vulnerabilities didn't slip through.  

Not all Misconfigurations can be Caught in IaC

While it's recommended to use IaC for as much of your cloud environment as possible, not every cloud resource configuration can be deployed and modified using IaC. For instance, information that comes from Data Sources in Terraform. Any misconfiguration vulnerability contained in these resources must be caught post-deployment in the runtime. 

Post-Deployment Cloud Drift Happens

Cloud configuration drift occurs - a lot. Even when cloud teams are mature in IaC adoption and the use of CI/CD pipelines for cloud infrastructure, those environments will still see significant modification outside of IaC and the CI/CD pipeline. The classic example of this is the addition of a security group rule to allow for Internet SSH access (e.g., 0.0.0.0/0 or a large public CIDR block on Port 22). Often used when performing maintenance or retrieving logs, it's not uncommon to forget to delete this rule once the work is completed (and is itself an insecure practice that should be guarded against.

IaC Security Won't Catch Orphaned Infrastructure 

Orphaned infrastructure is a major issue in the cloud, and it's not just about overspending for resources you aren't using. It's pretty common for resources to become forgotten, including EC2 instances, S3 buckets, EBS snapshots, AMIs, IAM users, VPC networks, and security groups. And while orphaned infrastructure is a long-recognized cost issue, it's also a serious security issue. If you're not aware they exist, you're not monitoring them for vulnerabilities. Orphaned resources have played a role in a number of recent cloud breaches, and IaC security offers no help in addressing the problem.  

Cloud Security Must Span the Entire Development Lifecycle

When developing your cloud security strategy, it's better to think of extending left rather than shifting left. Your cloud security strategy should take into account the full development lifecycle, from IaC through CI/CD to the runtime. Make no mistake, the payoff of shifting left with IaC security in terms of efficiency, speed, and savings are all there in spades, but don't ignore cloud runtime risk. 

##

To hear more about cloud native topics, join the Cloud Native Computing Foundation and cloud native community at KubeCon+CloudNativeCon North America 2021 - October 11-15, 2021  

ABOUT THE AUTHOR

Josh Stella 

Josh Stella is co-founder and CEO of Fugue and a technical authority on cloud security for highly regulated enterprises with customers like AT&T, Red Ventures, and SAP NS2. Bringing 25 years of expertise as a technology startup CTO, principal solutions architect at Amazon Web Services, and advisor to intelligence agencies, Josh founded Fugue and pioneered the use of policy-based cloud security automation to help enterprises run faster and safer in the cloud. He is a cloud technology patent holder, book author, and host of the Cloud Security Masterclass Series. 
Published Tuesday, October 12, 2021 11:26 AM by David Marshall
Filed under: ,
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<October 2021>
SuMoTuWeThFrSa
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456