Application Security

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

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: Apprentice
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.
Russia Hacked Clinton's Computers Five Hours After Trump's Call
Robert Lemos, Technology Journalist/Data Researcher,  4/19/2019
Tips for the Aftermath of a Cyberattack
Kelly Sheridan, Staff Editor, Dark Reading,  4/17/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-11378
PUBLISHED: 2019-04-20
An issue was discovered in ProjectSend r1053. upload-process-form.php allows finished_files[]=../ directory traversal. It is possible for users to read arbitrary files and (potentially) access the supporting database, delete arbitrary files, access user passwords, or run arbitrary code.
CVE-2019-11372
PUBLISHED: 2019-04-20
An out-of-bounds read in MediaInfoLib::File__Tags_Helper::Synched_Test in Tag/File__Tags.cpp in MediaInfoLib in MediaArea MediaInfo 18.12 leads to a crash.
CVE-2019-11373
PUBLISHED: 2019-04-20
An out-of-bounds read in File__Analyze::Get_L8 in File__Analyze_Buffer.cpp in MediaInfoLib in MediaArea MediaInfo 18.12 leads to a crash.
CVE-2019-11374
PUBLISHED: 2019-04-20
74CMS v5.0.1 has a CSRF vulnerability to add a new admin user via the index.php?m=Admin&c=admin&a=add URI.
CVE-2019-11375
PUBLISHED: 2019-04-20
Msvod v10 has a CSRF vulnerability to change user information via the admin/member/edit.html URI.