The New Application Attack Surface

This post comes as a result of a conversation between Tyler Shields, VP Strategy of Sonatype and myself.  

The way we create, deploy and operate applications has changed in the last few years. Applications are no longer just built, they are composed and constructed from libraries—whether internal or externally sourced. It’s often much easier (and safer!) to pull in a library that integrates the functionality you need vs. roll it yourself. Microservice and service oriented architectures are no different, and may actually increase the number of components in production environments.

In this new normal—it’s not just the code in the component that must be secured, it’s the language, the operating system, the hardware and all the layers in between. This is a challenging and complex landscape both for attackers to take advantage of, and for defenders when trying to secure applications. But, as I discussed with Tyler, there are solutions and successful strategies you can employ to improve visibility and gain control.

As portrayed rather strikingly in this image (credit @samnewman), there are a lot of ways for attackers to target a modern application. The custom functionality of any given application itself is just a piece of the overall picture. There may be bugs in the underlying libraries, the language itself, the operating system, the hypervisor, and as recently demonstrated via the MDS bugs, even the hardware. All of which can leave you vulnerable to attack. Yes, it’s rather overwhelming, but the good news is that we’re learning how to protect at the same time attackers are learning how to take advantage of this new reality, so there is time to stay ahead of the curve.

Beware The Common Component

Among these many layers in the modern application stack, open source components are key areas of risk. As the use of them rises, of course they are an increasingly attractive target as well. Tyler shared in the webinar the findings from their DevSecOps community survey that breaches related to open source components increased by 71% between 2014 and 2017.

And lest you think that open source vulnerabilities are just a problem for cutting-edge companies like Netflix with a very modern architecture, think again. In reality, I ran the  numbers for Express—for those who may be unfamiliar, this is a web front-end library for Node.js. I think it’s a pretty good indicator of who is running Node.js. And it turns out 84 of the Fortune 500 are running it across 1,000 different Endpoints. Which goes to show that this is not just a Netflix problem, this is an everybody problem.

At the same time, you have less time to fix things given that the speed of exploits has compressed by 93 percent. Now it is only three days before a vulnerability is exploited. While these are scary numbers, if you think about it, it makes sense. For example, for the most recent Struts bug, as an attacker it makes sense to look for those vulnerabilities right away. I suspect that many attackers may be cataloging information so when a new CVE or vulnerability is released they can just go back to their catalog and ask which systems are likely vulnerable to that particular vuln.

Visibility Is Key

So in this threat landscape, what can we do to protect our applications? Visibility is your most important tool. It’s absolutely necessary to understand what you’re running. The component layer is generally the first and fastest to be targeted. The library or the component layer will get targeted before individual applications because these can have the most impact for the least amount of work by an attacker. So having full visibility of individual components is key. In addition, it’s very important to know the threat landscape. I find GreyNoise to be a very good source of threat info.

It’s also important to have visibility inside the organization to understand which teams could be focused on and which teams could use attention. So one has visibility not just into the threats, but also where they are likely to come from.

Shift Left AND Shift Right

Once we’ve gotten visibility into threats, we need to know that we can’t and shouldn’t just try to fix everything up front, as humans can’t keep up with the volume of vulnerabilities. Especially when you’ve only got three days before an exploit, so it’s unlikely you’ll execute a patch in time. Here automation is key. Automation of your defenses will then buy you time. Shifting right with protective technologies or what Tyler coined as “shifting left and shifting right.”

Not only do security teams need to shift left and get security embedded earlier in the development process, but it’s also important to shift right and put protections in place that can buy your development teams time to fix vulnerabilities. So when a new CVE is discovered in an open source product, you’ll want to automate, feed into a ticketing system and include all relevant info on how to patch it and get a vulnerability resolved in the fastest time possible.

As discussed, there are so many different places where you might have vulnerabilities. And as we saw in the 2019 DBIR, passwords and leaked accounts are still a major problem, and that’s just one of the many things application security teams will have to deal with. The integration between Sonatype and Kenna helps to bring in information from the component level. So often teams start with SAST, DAST, as the first thing. While those are important, and it’s important to have as many different application security tools to give us full visibility into the problem, frankly, SCA is the most bang for your buck in terms of which vulnerabilities are likely to be targeted by an attacker. So having awareness and visibility into those is key for security teams today.

In sum, the first question when a new vulnerability comes out is, “Does this affect us?” And you have to be able to answer that question. If you aren’t there yet with your application security efforts, we here at Kenna Security would love to help get you there.