Performing Assessments Early in CI/CD to Reduce Security Issues and Developer Rework
“Misconfiguration Prevalence: high; Attacker Sophistication: low...misconfiguration of cloud resources remains the most prevalent cloud vulnerability....”
Why You Need a CSPM
Mistakes happen! No matter how many controls and processes you put in place – services can and do get exploited by the bad guys because of errors from many developers deploying rapidly to the cloud. It's an all too common reality. In August of 2020 alone, over 4,000 S3 buckets were found publicly exposed – full of secrets and more. This cut across fortune 500s, NGOs and startups. Class action suits are still underway.
As security practitioners, it’s our job to find out about exposures like these before attackers can find them. CSPM solutions give you visibility of what security issues are running in your cloud environments. They scan for configuration errors post deploy. In some cases, they not only scan for issues, but can take some remedial action – like integrating with cloud service provider APIs to fix the “leaky S3 buckets.”
Notice the warning on the box though:
Relying on post deployment approaches alone means defenders may be the last to know about the exposed bucket, database or other vessel of valuable data. Not only are you the last to know – but you are likely to know the least about it.
There is a better way: we can make CSPMs more effective if we can trace what data is associated with the service, who exposed it, who can fix it, and what the impact will be to the business if you can fix it. Furthermore, if we can use that information to prevent the misconfigured asset from ever being created, then there will be nothing to detect in the future.
Without contextual data coming from development, you are like the blind monks in the Japanese Zen painting above. Each monk thinks they are touching something different; one monk thinks the tail is a snake, while another monk thinks the leg is a column, and etc. They are all wrong because they are missing critical information caused by collective blindness.
Development Running Faster Than Ever
Cloud native application development today means it is easy for developers to provision applications to the cloud for customers to use, with the ability to release updates anytime. Contrast this with the past, where an application developer would file a ticket, wait for someone from IT or operations teams to provision a server, work to release software, and then issue updates over periods of months or even yearly.
Instead, using cloud platforms, like AWS, Google, and Azure, modern software developers can self provision infrastructure, with minimal help from other teams. Then, they can release and update software using continuous integration and continuous deployment (CI/CD) for rapid software releases and updates.
Declarative Infrastructure as Code (IaC) – things like Terraform, CloudFormation, Kubernetes manifests, and Helm Charts – helps streamline cloud infrastructure provisioning by eliminating manual process and putting declared state under source control. The code is the authoritative state for the resources for immutable infrastructure – servers, databases, networks, application deployment, and configurations. We have solved change provisioning and change management deftly. But we haven’t eliminated the risk of configuration mistakes. In fact, we have made the problem worse.
The Challenges of Defending With CSPM
If a defender has a CSPM - they can catch misconfigurations in runtime. But it’s late in the software development cycle. The infrastructure is available to attackers. Development teams have moved on to the next sprint. The feedback loop is too long. As the number of daily releases increases, the risk of security incidents and misconfigurations increases, and remediation comes with a high cost to the business.
In 2018, we saw more than 80 high profile breaches caused by misconfigurations, approaching $11 Billion in impact. In 2019, it nearly doubled to over $21 billion. Even technically savvy companies like Capital One, Twilio, Accenture, Dow Jones, Verizon, and many more, have fallen prey to cloud configuration breaches.
Security teams were already outnumbered by 10:1 in operations (DevOps, SRE etc.). The ratio of developers to security is a 100:1! Add pipeline-based CI/CD to the mix, and security is both outnumbered and outgunned.
If you’re catching the issue in runtime with your CSPM, you can then mitigate risk, but you have to prioritize it with your backlog, trace it back to the owner, and take the time to work with the developer to remediate it.
Working in CI/CD to Conquer the Triage Treadmill
Cloud service ownership and other contextual data is created in development – in buildtime. It’s generated by developers authoring their IaC, using Terraform, CloudFormation, Kubernetes manifests, ansible playbooks and more.
As IaC moves through CI/CD pipelines, in and out of repos, across branches, and deployed into public clouds, volumes of data are generated. Your CSPM tool has absolutely zero visibility into those processes and the data they make. But that’s where all the juicy action is!
Without that information, you are just opting for a triage-heavy project every time something bad occurs (unless you can automagically fix it without blowing up the business in the process). It’s extra time in meetings to discover who owns what. It’s developers wading through CSPM impregnated backlogs – much of which they will consider false positives due to a lack of context.
All this triage work takes time away from important security work and business supporting product development. While you are figuring out if you have a problem and who owns it, data and services are being exposed, leading to breach.
Better Results from Shifting Security Left
At Soluble, we believe modern cloud infrastructure security must shift security work left to development. This means holding to the principle of “meeting developers where they are,” helping developers assess security in their toolchains and in their pipelines. Why? Because the developers are the ones authoring IaC, and it is more efficient for them to find and fix issues early. By making it easy for developers to do security testing with little to no disruption, everyone wins – particularly the business.
We also hold to the principle of “bringing all the data together.” As I mentioned above, the buildtime context generates a slew of data. Data coming from code repositories, pipelines, security scanners, identity and access management (IAM), and more must be made easy to access and understand. Making that data accessible and comprehensible is key for streamlining security changes and reporting on them over time.
The first principle of “meeting developers where they are'' is embodied by Soluble’s full featured command line interface (CLI). It lives in your CI/CD pipelines on the far left – pictured in the diagram above. It executes IaC static analysis, image scanning, secrets scanning, and more. It intelligently selects the right solution (including ones you already use) depending on the context. And it’s designed to easily add capabilities over time. Most importantly, it gives fast feedback to developers in their toolchains so they can make changes in seconds.
The second principle of “bringing all the data together” is seen in our SaaS platform and its dashboards that bring all the data together in one place. For security, it provides visibility and accountability into a previously sealed domain. Now, security can see what is going on in infrastructure development, monitor for risk, author security policy (as code), and say goodbye to ever being left behind.
We can use this information to increase the effectiveness of CSPM findings; when an issue is discovered, you now have the information to quickly address it: the infrastructure owner, and information on what data and services are exposed. And we can use that information to prevent misconfigured assets from being created so there is nothing to detect in the future.
At Soluble, we believe this gives you a more complete solution to improve your cloud security posture. First, you can reduce defects from being deployed by testing IaC early in development. This reduces the number of misconfigurations and security issues deployed in runtime. Then, in runtime, if your CSPM does find issues, the Soluble platform has the data to help with faster incident response.
Want to know more and to give Soluble a try? Contact us for early access.