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.

Access this on-demand webinar here.

With a growing need for fast, agile development, companies have been 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 considerably outnumbered by developers contributing code to a normal organization’s structure,” says Moshe Zioni, VP of security research at Apiiro. “Because of the rapidity of development, they can’t catch up with every kind of problem unless they use a large-scale solution that lets them proactively remediate risks at scale, instead of just playing whack-a-mole when issues crop up.”

Cloud-native applications and mobile applications can be attacked in a variety of unique ways, and have cascading consequences, Zioni says.

The cloud-native risks of cloud-native applications

When a software package that has been allowed to develop dependencies is targeted, it can have an exponential effect on the supply chain. Attacks on the software development life cycle (SDLC) and continuous integration/continuous delivery/deployment (CICD) tool sets, which are crucial to rapid development, give the attacker a linchpin to undermine all the code you’re deploying and compiling.

“Those kinds of tools have been targeted pretty massively by attackers over the past two or three years now, first because they’re less of a concern for many organizations,” Zioni says, “and second, when a malicious user gains control over those processes, it can can go on for months, maybe even years unnoticed, which is of course a very devastating blow to anything we consider secure today.”

To get ahead of attacks at scale, security leaders need to find a way to contextualize the risks to their software.

Why contextualizing risks is key

The traditional way to consider risk is to evaluate the intrinsic danger a code, package, process, etc. For example, the intrinsic risk of human-written code is that it will have bugs. But this is a one-dimensional way to look at it, Zioni says. Without context, you won’t understand the broader risk that a weakness or vulnerability poses.

Context includes a wide array of things. It includes the environment the code lives in, and the effect 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 was trained in security, and whether the code introduces a change to authorization mechanisms — and whether the developer knows about those authorizations. It also will matter whether the developer has ever contributed code in the same manner, and whether the code is written according to the organization’s protocol or is copied from somewhere.

“All that intelligence information constructs what we call that contextual risk,” Zioni says. “Once you have all of those data points about a commit, you can assess the kind of risk that commit imposes, apart from the code itself. Without this kind of multidimensionality, you won’t be able to differentiate from one commit to another.”

This kind of context can be gained by creating a risk profile.

The importance of risk profiles

Risk should be looked at in three dimensions, Zioni says. The first is the developer layer, which includes a behavior 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 on. And third is the semantic approach, where automated machine learning and NLP processes parse stack messages and feature requests on ticketing systems to understand what kind of history and context the code commit holds.

Through those three layers, you gain essential information about what is behind the commit, what kind of contextual messaging the developers may have had around it, what kind of developer or developers wrote the code, and what you can tell about the code from that.

“Altogether, those three layers will position you right off the bat with a much better contextual risk position, and through that, you’ll be able to prioritize much better,” he explains.

The last part is simply knowing what matters, and prioritizing from there. If the change is something unimportant in terms of security, then you can prioritize that much lower than something that’s essentially changing a security-specific mechanism in the code.

Watch out for these security pitfalls

There are a few steps you can take to heighten cloud security, Zioni says.

The known unknowns. First is understanding what you know, but also what you don’t know. That means gaining a view into your code, your developer base, your organization, and even into tribal knowledge (what is being planned, who is contributing what, what communication channels are being used, and so on).

Remediation at scale. The second is to plan strategically for remediation at scale — or going all the way back to the root cause of an issue. If you find a problematic SQL injection time and again on a very specific code or maybe a part of the code base, drill down to why it keeps happening. Maybe the developer isn’t properly trained, or the reviewer doesn’t know how to spot this kind of vulnerability, or it’s slipping through your risk prioritization.

Monitor and measure. Finally, you need to figure out what can be measured, and what measurements matter, and from there, determine your KPIs. You’ll understand what represents progress, and what will keep you from getting stuck on that single-minded, whack-a-mole approach of just fixing the latest vulnerabilities.

“The goal shouldn’t be putting out fires, but instead making progress on your whole application security program,” Zioni says.

To learn more about the security risks to cloud-based applications, how to prioritize threats, dig down into root causes, and build a team of security-minded developers, access this on-demand webinar.

Access on-demand right here.

You’ll learn how to mitigate risk by:

• Identifying and enabling security champions
• Building and scaling a risk-based AppSec program
• Finding and remediating secrets in code and IaC misconfigurations
• Prioritizing risks effectively across the entire SDLC
• Finding the root cause and identifying the relevant developer

Speakers:

• Alex Mor, Director of Application Security, Anheuser-Busch InBev
• Moshe Zioni , VP Security Research, Apiiro
• Kyle Alspach, Moderator, VentureBeat