Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

4/9/2019
02:30 PM
Manish Gupta
Manish Gupta
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

A New Approach to Application Security Testing

If the appsec industry were to develop a better AST solution from scratch, what would it look like?

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.

 

Manish Gupta is the CEO and co-founder of ShiftLeft Inc. He was previously the chief product and strategy officer at FireEye, helping grow the company from approximately $70 million to more than $700 million in revenue and expanding the product portfolio from two to more than ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
PaulV972
100%
0%
PaulV972,
User Rank: Strategist
4/9/2019 | 4:10:52 PM
Combination of Approaches
As the lead App Sec Architect for a healthcare SaaS offering, we moved from SAST to a mixed model.  In our scenario, we injected IAST into our test suite, and then automated DAST (alongside selenium automation).  The net result was actionable intelligence with reporting in a manner that made security just another of the testing practices.  We found SAST of limited value, with a signal to noise ratio that required supplementing traditional solutions with filtering and mapping that compensated for it's shortcomings.  Eventually, SAST was retained to satisfy regulatory requirements, while the integrated IAST and DAST suite was the basis for decision making.
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
How Security Vendors Can Address the Cybersecurity Talent Shortage
Rob Rashotte, VP of Global Training and Technical Field Enablement at Fortinet,  5/24/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7068
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7069
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7070
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7071
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
CVE-2019-7072
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .