Presented by Apiiro
In recent years, companies have accelerated their adoption of cloud-native applications. But with that leap comes risks unique to cloud native computing. To learn more about the dangers and challenges, and how to overcome them, don’t miss this VB On-Demand event.
Go here to this on-demand webinar.
With a growing need for fast, flexible development, companies are increasingly embracing cloud services and applications. But with that ease of development, propelled by the proliferation of open source code, comes new and unique security risks.
“Security professionals are significantly outnumbered developers who contribute code to the fabric of a normal organization,” said Moshe Zioni, VP of security research at Apiiro. “Because of the speed of development, they can’t catch up to every kind of problem unless they use a large-scale solution that can proactively mitigate risk on a large scale, rather than just making fun of when problems arise. †
Cloud-native applications and mobile applications can be attacked in several unique ways and have cascading effects, Zioni says.
The cloud-native risks of cloud-native applications
When a software package that has been allowed to develop dependencies is attacked, it can have an exponential effect on the supply chain. Attacks against software development lifecycle (SDLC) and continuous integration/continuous delivery/deployment (CICD) toolsets, which are critical to rapid development, give the attacker a linchpin to undermine any code you deploy and compile.
“These kinds of tools have been attacked quite massively by attackers in the past two or three years, firstly because they are of less concern to many organizations,” Zioni says, “and secondly, when a malicious user gains control over those processes, they can it goes undetected for months, maybe even years, which is of course a very devastating blow to everything we consider safe today.”
To stay ahead of large-scale attacks, security leaders must find a way to contextualize the risks to their software.
Why contextualizing risk is essential
The traditional way of assessing risk is to evaluate the inherent danger of a code, package, process, etc. For example, the intrinsic risk of human-written code is that there are bugs in it. But this is a one-dimensional way of looking at it, Zioni says. Without context, you don’t understand the broader risk that a weakness or vulnerability poses.
Context encompasses a wide variety of things. It includes the environment in which the code lives, and the effect that the introduction of new code will have on the periphery, infrastructure and environment. It also means knowing which developer wrote the code, whether the developer is trained in security and whether the code introduces a change in authorization mechanisms — and whether the developer is aware of those authorizations. It also matters whether the developer has ever contributed code in the same way, and whether the code was written according to the organization’s protocol or copied from somewhere.
“All that intelligence information constructs what we call that contextual risk,” Zioni says. “Once you have all that data about a commit, you can assess the kind of risk a commit poses, aside from the code itself. Without this kind of multidimensionality, you can’t differentiate from one commit to another.”
This kind of context can be obtained by creating a risk profile.
The importance of risk profiles
Risk should be viewed in three dimensions, Zioni says. The first is the developer layer, which contains a behavioral analysis of the developer. The second is the code itself, where the code is parsed to understand what it means and what kind of mechanisms it touches. And third, there’s the semantic approach, where automated machine learning and NLP process stack messages and feature requests on ticketing systems to understand what kind of history and context the code commit contains.
Those three layers give you vital information about what’s behind the commit, what kind of contextual messages the developers have had around it, what kind of developer or developers wrote the code, and what you can tell about the code from that.
“Overall, those three layers will immediately position you with a much better contextual risk exposure, and therefore you can prioritize much better,” he explains.
The last part is just knowing what’s important and prioritizing from there. If the change is something insignificant in terms of security, then you can set that priority much lower than something that essentially changes some security-specific mechanism in the code.
Beware of these security pitfalls
There are a few steps you can take to improve cloud security, Zioni says.
The known unknowns. The first is understanding what you know, but also what you don’t know. That means understanding your code, your developer base, your organization, and even tribal knowledge (what’s being planned, who’s contributing what, what communication channels are being used, and so on).
Remediation to scale. The second is to plan strategically for large-scale recovery — or go all the way back to the root of a problem. If you find a problematic SQL injection time and again on a very specific code or maybe part of the code base, dig deeper into why it keeps happening. Maybe the developer isn’t properly trained, or the reviewer doesn’t know how to spot these kinds of vulnerabilities, or it’s slipping through your risk priority.
Monitor and measure. Finally, you need to figure out what can be measured and what measurements matter, and determine your KPIs from there. You’ll understand what progress represents and what keeps you from getting stuck in that determined, relentless approach to fix only the latest vulnerabilities.
“The goal shouldn’t be to put out fires, but to make progress with your entire application security program,” Zioni says.
Join this on-demand webinar to learn more about the security risks of cloud-based applications, prioritize threats, identify root causes, and build a team of security-focused developers.
Access on demand here.
You will learn how to mitigate risks by:
Identify and enable security champions Build and scale a risk-based AppSec program Find and remediate secrets in code and IaC misconfigurations Effectively prioritize risk across the SDLC Find the root cause and identify the relevant developer
Alex Mor, Director of Application Security, Anheuser-Busch InBevMoshe Zioni, VP Security Research, ApiiroKyle Alspach, moderator, VentureBeat
This post How to neutralize security threats to your cloud native applications (VB On-Demand)
was original published at “https://venturebeat.com/2022/03/17/how-to-neutralize-security-threats-to-your-cloud-native-applications-vb-on-demand/”