Threat Actors Focus on the Application Layer, Do You?

How application security affects you

Philosopher Henry David Thoreau famously said, “There are a thousand hacking at the branches of evil to one who is striking at the root”. While this quote is not about the current state of cybersecurity, it certainly applies. Organizations worldwide spent approximately $123 billion (USD) on IT security in 2020. Yet 2021 has been dominated by headlines heralding successful cyber attacks against Colonial Pipeline, JBS Meat packing, Microsoft, and others.

What is going on?

The primary problem may be that the business world is busy hacking at the branches of cyber attacks, rather than striking at the root. Applications are the main attack vector exploited by threat actors. In fact, an estimated 84% of cyber attacks occur on the application layer. Yet organizations spend the majority of their IT security money elsewhere. According to Forbes, a full 89% of all IT security spending goes to:

  • Security services
  • Infrastructure protection
  • Network security equipment
  • Identity access management
  • Consumer security software

This allocation of security resources makes sense for organizations that are relying on third-party software and services for their daily operations. Yet none of these billions in spending addresses the root of the issue — vulnerable applications.

Why Are Applications Vulnerable?

Writing secure software can be an incredibly difficult task. These difficulties can quickly compound when software is engineered to function on multiple platforms, perform more tasks, and interact with networks, services, or other applications. For example, it is estimated that software developers write somewhere between 90 billion and 120 billion lines of code per year. This incredible output provides threat actors a generous attack surface, given they need only one vulnerable line of code for success.

Of course, bad actors are not scanning each line of code written every year for flaws. They don’t need to. The vast majority of software development companies use some form of open-source code in their products. If threat actors can find vulnerable but widely-adopted open-source code they can capitalize on it every time it is used.

The application layer provides a wellspring of opportunities for attackers, between the rapid growth of code and companies using open-source materials. Yet the majority of security spending is streaming into reactive solutions that assume software will be compromised. Wouldn’t it make more sense to secure the application layer, rather than accept it as an inevitable point of failure?

Why Do Developers Keep Writing Vulnerable Code?

It would be easy to blame the success of ongoing cyber attacks directly upon the shoulders of software developers. After all, if they were writing secure code then 84% of the problem would be solved from the outset. Yet, software developers are not writing vulnerable code out of malice or laziness. They do not want their names or professional reputations associated with a high-profile security breach. What factors, then, contribute to the ongoing practice of writing vulnerable code?

Many professionals in software development are familiar with the Iron Triangle. The phrase refers to a project management maxim that states any job can be done “fast, cheap, or good — pick two”.

1 The Iron Triangle — Pick two priorities at the expense of the third

Many software development companies focus on minimizing project expenses and reaching the market quickly. Software applications and services are often scheduled on tight deadlines, preventing developers from performing exhaustive security checks on their code. They opt for fast and cheap, at the expense of good — perhaps hoping any problems can be resolved with future updates.

Another issue is that code vulnerabilities may go undiscovered for a significant period of time. By the time a critical flaw is discovered in some code the original author may have already moved on to other opportunities. The net effect of this delay between the writing of vulnerable code and its exploitation means many developers may never discover their errors. In fact, they may go on writing code for years, in several different organizations, making the same mistakes.

Misplaced incentives play a role in creating vulnerable software as well. Consider the well-known metaphor about reward and punishment known as the carrot and the stick. Software developers receive the carrot at the completion of a project, often in the form of pay, praise, and satisfaction. Yet when completed software is eventually breached by attackers the stick often falls directly on the product operations team. Once again, the original authors of the code may no longer be with the company to witness the repercussions of their failed software. This disconnect between the authoring of faulty code and the negative consequences of the software’s failure disables a feedback loop critical for self-improvement. Put simply, many developers never get the opportunity to learn from their mistakes.

How Can Vulnerable Code Be Fixed?

Developers have a number of methodologies that can detect security vulnerabilities before software is released to the public. Three major ones are static application security testing (SAST), dynamic application security testing (DAST), and interactive application security testing (IAST). These processes can be used individually or together, each providing their own strengths and benefits.

SAST

SAST testing can be carried out whenever the application code changes. As such, this method is shifted to the “left” in the development cycle. Strong SAST testing represents a golden opportunity for developers to ensure their product is built upon a secure foundation. Testing is carried out directly on the code without executing the application, making SAST tools language-dependent.

Using SAST to identify and fix vulnerabilities prevents innumerable cyber attacks. Every fixed security flaw translates to one less avenue threat actors can exploit. It is difficult to fathom the amount of money and resources developers save the economy by ensuring code is secure before release. While project managers can quantify the costs of using various SAST methodologies, who can calculate the savings of the cyber attacks it ultimately prevented?

In addition, frequent SAST testing integrated into the developer’s workflow can give developers immediate feedback about the security of their code, which helps them write more secure code in the future.

DAST

DAST is a methodology performed on running applications. As such, it occurs when a deployment-ready version of the application is completed. DAST does not need to understand the technology or framework an application was built upon. It performs run-time security analysis to discover vulnerabilities, a feature making it useful for both developers and threat actors. Because testing occurs after most development has been completed, vulnerabilities discovered by DAST are more costly to because often, more code needs to be changed. The best strategy to control the time and monetary costs of fixing vulnerabilities is to find most vulnerabilities using SAST early in the development cycle, then catch the few missed by SAST using DAST.

IAST

IAST is an integrated process for testing running web applications. It detects vulnerabilities by deploying sensors (or instruments) to analyze manual or automated interactions occurring with the program. Like SAST, IAST is language and framework-specific and requires access to the source code. However, IAST also integrates with the code, which is something developers should consider when determining their comfort level with this style of testing.

New Technology for Earlier Vulnerability Detection

Recent advancements in graph analysis have enabled a new generation of SAST tools. Next-gen SAST (NG-SAST) developed by ShiftLeft is an example of such a tool. The speed and accuracy of this type of SAST has vastly improved upon the benefits of this class of test. Historically, a test could take hours to days to perform which prevented teams from using it frequently. In a recent study of its users, ShiftLeft found that 46% of applications using NG-SAST are scanned at least weekly and 17% at least daily. Available reports from traditional tools indicate applications using older technology are scanned around 3.5% weekly and 0.3% daily.

Getting vulnerability information to developers shortly after their code is written is key to fixing issues quickly and efficiently. It also has the benefit of teaching developers to write more secure code in the future. The effect of this efficiency is seen in Enterprise customers who integrated NG-SAST with their CI/CD pipeline and scanned applications at least weekly. These users fixed 91.4% of vulnerabilities within two sprints of their creation. This corrects the issue of misplaced incentives and ensures the original team is responsible, and therefore attentive to, the security of their code.

The importance of writing secure code cannot be overstated. Applications are the root of 84% of cyber attacks, making a strong AppSecprogram the best tool for fixing the problem. Today, the vast majority of IT security budgets are spent whacking at the leaves of cyber attacks. ShiftLeft offers organizations the opportunity to dedicate their security budgets to a more effective model. Learn more about NG SAST, and how to strike at the root of cyber attacks by contacting ShiftLeft today.


Threat Actors Focus on the Application Layer, Do You? was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by The ShiftLeft Team. Read the original post at: https://blog.shiftleft.io/threat-actors-focus-on-the-application-layer-do-you-3a74c714825b?source=rss—-86a4f941c7da—4