A New Approach to Application Security Testing

As software, aka applications, microservices, and workloads, increasingly moves into the cloud, its protection has become paramount. Recent research highlights this need, pointing to application vulnerabilities as the leading source of security breaches in 2018. The "Verizon Data Breach Investigations Report," for example, confirms that a vast majority of breaches happen either due to spear-phishing or application vulnerability exploits. These are the two seminal challenges for cybersecurity in the coming decade.

Yet the ugly truth, according to a recent SANS Institute survey titled "Secure DevOps - Fact or Fiction?," is that only 10% of organizations report repairing critical vulnerabilities satisfactorily and in a timely manner. Clearly something has to change.

In order to understand what that change is, we first need to have a clear view of the current state of application security. Application security operates in the development (dev) and production (prod) phase of the software development life cycle (SDLC). In dev, the goal is to find and fix vulnerabilities before releasing insecure code. In prod, the goal is to protect the application from all of its vulnerabilities. Theoretically, software providers need only one or the other, but since neither is foolproof, most companies cover their bases with some form of both.

Gartner identifies three available code analysis techniques:

1. SAST: Static application security testing analyzes the application from the inside-out by inspecting its source code. SAST's advantages are that it leverages fundamental knowledge of vulnerabilities to inspect the source code and is therefore the most thorough of all AST techniques. It can be used for any code as long as the programming language is supported, and it's performed closest to dev, making it the least expensive way to find and fix vulnerabilities.

On the flip side, traditional SAST scan times are slow, requiring hours or even days to complete, which doesn't work well in increasingly automated continuous integration and continuous delivery (CI/CD) environments. False-positives are also an inherent part of the SAST process. Moreover, traditional SAST does not analyze an entire application, forcing organizations to buy a separate tool for software composition analysis (SCA). Even SCA merely identifies publicly known vulnerabilities; unknown vulnerabilities in open source, third-party APIs, or frameworks is out of scope for both SAST and SCA.

2. DAST: Dynamic application security testing probes the application from outside in, treating it as a black box and testing exposed interfaces for vulnerabilities. DAST generally results in low false-positives and can be performed even when the application's source code is not available (for instance, with third-party applications). It is particularly good at accurately identifying externally visible vulnerabilities. DAST can be performed for any application, regardless of programming language, as long as the test scripts are available, and it can find vulnerabilities in open source software, third-party APIs, and frameworks.   

That said, DAST requires test scripts to test everything, which is impossible from a practical standpoint and requires heavy reliance on experts to write tests, making it difficult to scale. More importantly, by definition it only analyzes exposed interfaces, which presumes an attacker only has external access – yet insider threats and complex "peel-the-onion" attacks are some of the most dangerous. DAST also provides insufficient information to the developer about why and where a vulnerability exists, requiring considerable time to identify the root cause. The efficacy of DAST is thus directly proportional to the quality and volume of QA, making it ill-suited for modern, fast-paced DevOps pipelines.

3. IAST: Interactive application security testing aims to improve on DAST by instrumenting the application to allow deeper analysis (beyond just exposed interfaces) and can be considered a superset of DAST. Its advantages and disadvantages are similar to those of DAST, with the added drawback that the application instrumentation means it needs to support the application programming language. In particular, it can only be performed on languages that have a virtual runtime environment, such as Java, C#, Python, and NodeJS. It cannot support languages such as C, C++, and Golang.

A New Approach
Clearly each approach has advantages and disadvantages. But if the appsec industry as a whole were to develop a better AST solution from scratch, what might it look like? First, its analysis would mirror the more comprehensive inside-out paradigm of SAST but be much, much faster. Like DAST, it would analyze the entire application, including dependencies, third-party APIs, and frameworks. After all, a hacker only needs one vulnerability in an entire application to wreak havoc.

The analysis also wouldn't be generic. Developers would be able to leverage their application knowledge to write new custom queries or edit existing ones. For instance, if a team has written a custom API to escape inputs, the tool needs to take this API into account. A better approach would understand the flow of an application so even when no clear vulnerability is identified (a false-negative), monitoring of runtime behavior compared to the inherent flow of the application can identify when an application has been successfully exploited.

As noted earlier, SAST in itself is incomplete, so it should be combined with the ability to take data from the production environment to address otherwise inherent reachability challenges. This would require a microagent that deeply instruments the application (like IAST) and is designed around the stringent performance and stability requirements of a production environment. Because this microagent is designed for production, it should easily run in QA where, if tested with QA/security test scripts, can function as an "enhanced" IAST. Yet, unlike IAST, the microagent should learn from SAST where it needs to instrument the application. So, for example, if the application is not vulnerable to SQL injection, why instrument the application and alert on SQL injection patterns?   

Given that only 10% of organizations today report satisfactory and timely repair of critical vulnerabilities, regardless of how good an AST tool chain is, there will be unfixed vulnerabilities deployed into the production environment. In other words, AST does not eliminate the need for a tool to protect applications in production.

Yet today's typical security approach is to deploy a tool or appliance that continuously alerts on threats, regardless of whether the application itself is vulnerable to that particular threat. Even if the alert is relevant, it demands considerable time spent investigating if, and where, the vulnerability exists. Worse, when a vulnerability is not relevant or has been fixed, the security tool will continue generating alerts regarding the same, now benign traffic.

In contrast, this better approach instruments the application based on SAST findings, ensuring the protection is high-performing and accurate. It will also tell the developer about the vulnerability and the specific location in code that needs to be fixed.

That's the point of continuous improvement: code analysis informs runtime and runtime traffic informs code analysis. And it should be the key goal of every application security program.

Related Content:

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.