Building a Modern Application Security Strategy. Part One: Threats, Opportunities, and Challenges
Table of Contents
First of a two-part series:
The online world is now packed with applications, so it’s unsurprising that they’re a top target for threat actors. However, traditional application security (AppSec) strategies often prove ineffective. To defend themselves against the rapidly evolving threat landscape, organizations need to build a modern AppSec strategy that addresses these fast-changing conditions.
Jeff Martin, Mend’s vice president of outbound product management, and Janet Worthington, senior analyst at Forrester, met to discuss how modern application security programs are best built for an app-driven world. The first step lies in understanding the current status quo.
Understanding threat levels and sources
Forrester’s 2022 State of Application Security Report reported that 66 percent of respondents said their organizations had been breached at least once, making application security a major issue.
One of the key drivers is an explosion in open source use over the last five years. Open source comprises about 75 percent of most code bases, rising to 90 percent in some cases.
“We’re seeing the fact that web applications are depending a lot now on applications and general APIs, etc. We’re depending a lot more on open source and those dependencies, which is why we’re seeing software vulnerability exploits at number one,” said Worthington.
The leading sources of attacks are from external actors, and the research identified the top three sources as application exploits, supply chain/third-party breaches, and web application exploits.
According to Worthington, organizational awareness of the problem is increasingly important. “We really want people to understand that this is what attackers are using to get into their systems and to compromise them,” she said. “We want to highlight the importance of ensuring that the applications that you sell, and the software that you bring in and package, are all potential places that can be exploited.”
As applications are assembled from a collection of reusable components, Martin noted that it is inevitable smart attackers will target commonly used components. The good news is that automated tools are available to mitigate and remediate many of these attacks.
Prioritizing application security
Companies are increasingly aware of the threat posed by attacks on applications, and Worthington said application security has emerged as a top priority for many companies. “They now have an understanding of how grave the threats are from application vulnerabilities,” she said. “They get it. They appreciate that there are things they can do to harden their environment, applications, etc., to make sure that those vectors are not open for attack.”
Martin pointed out that as open source usage has increased, security has become part of the DNA of the open source community. “We’re getting better about not just using and creating open source, but trying to create it responsibly, create secure code, and publish when we have problems,” he said.
Traditional and emerging supply chain threats
Nevertheless, as open source usage grows, so does the risk of exposure to vulnerabilities and software supply chain attacks. The challenge is to keep up with the fixes published to the open source code in use. Data from the Mend vulnerability database shows open source vulnerabilities growing at a rate that maps roughly to the increasing prevalence of open source software. For instance, in 2021, the number of new open source vulnerabilities that Mend added to its vulnerability database was 25 percent greater than the previous year, pretty much in line with the estimated 25 percent growth in the amount of open source software available. However, in 2022, we saw a 33 percent increase in open source vulnerabilities through September.
“The attack surface is really the gap between what you have implemented and what the open source community has fixed, because that’s where the bad actors fit. They go for the recent vulnerabilities that are very prevalent, and they take advantage of the fact that you haven’t applied the fix yet.”
Furthermore, attackers are constantly developing new innovations and sophisticated attack methods. For instance, attackers modify and manipulate naming conventions in the hopes that organizations unknowingly download and include malicious packages in their applications. If these applications are passed to their customers, the risk of compromise increases further. Worthington said that this kind of dependency confusion is rife, alongside typosquatting and other growing risks. Essentially, the situation has become a race between attackers seeking ways to disrupt, and those responsible for security seeking ways to beat the attackers. “We keep getting more mature about mitigating things like known vulnerabilities, and big enterprises who are security conscious and a little bit farther along the maturity scale are doing well with that,” Martin said. “So bad actors needed a new way in. They realized that everybody is just trusting each other, and they can get inside that trust chain by injecting a package that they control. Now that’s typosquatting and dependency confusion, and all those related supply chain side effects.”
The leading threat example – Log4j
Worthington noted that attackers also focus on application development tools, because they are often overlooked by security teams. Case in point: Log4j.
In summer 2022, the US Department of Homeland Security released a report on how their organizations responded to Log4j and found out that one department had to spend over 33,000 hours remediating it. That’s a lot of time, cost, and opportunity lost at the hands of malicious actors. And probably the biggest thing that came out of the report was the assessment that Log4j is going to be an endemic vulnerability that we’re going to be dealing with for a long time.
What was shocking about Log4j from Martin’s perspective was that despite customers and others immediately being alerted to it and jumping on it, a significant number of people weren’t sure where they had Log4j, if it was in their applications at all. They were building all their applications without fully understanding what they were composed of, if and where they were using Log4j, and how exposed they were. “That is getting to the point of being an almost inexcusable problem,” he said.
“One of the bigger insights here,” he continued, “is that despite how good we are in the industry of paying attention now, we still quite aren’t at the maturity that we need to be for understanding the basics.”
APIs – Opportunities and risks
Attention then turned to APIs, which Worthington said carry security risks.
People are broadening their use of APIs because they are a great way to connect applications, streamline business operations, improve customer engagement, and even generate revenue. Unfortunately, just like web applications, APIs are vulnerable to attack methods such as injection attacks and broken object-level authentication. And that presents organizations with yet another security priority. “What we see when we talk to our clients is that people are struggling right now to identify and catalog all the API endpoints in their inventory,” Worthington said.
Using third-party APIs as an example, Martin echoed this sentiment. “You are assembling your application, especially modern cloud-native type applications out of reusable components. Some of them are open source. But the other pieces of functionality you’re using are APIs and it’s really the same problem,” he said. “You need to understand what the components of your application are, and you need to make sure you’re keeping up to date on the risks that those components are introducing. It’s not a completely free ride. You get the functionality for free, but that does mean you’re dependent on it. It does mean you have a trust relationship, and that requires some watchfulness and management.”
Sharing and managing API user identities is another security factor that sometimes gets overlooked. Often, the initial request is authenticated and authorized, but subsequent ones aren’t. Worthington and Martin agreed that it’s necessary to apply the same level of rigor on APIs as you would to any normal user requests. You need to make authorization a continuous process. This is especially important in industries that handle critical data and must comply with data privacy regulations.
“You have to make sure that you’re authenticating at every point, and you have to understand where the data is going. If you can’t meet those requirements, you are probably also not meeting some regulatory or compliance requirement for your industry,” Martin said,
So, what can you do to better secure your applications and software? Find out in the second part of this series.
