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

03:30 PM
Jason Schmitt
Jason Schmitt
Connect Directly
E-Mail vvv

Software Security Is Hard But Not impossible

New Interactive Application Security Testing products produce an interesting result under the right conditions, but they can't, by themselves, find all the security vulnerabilities you need to fix.

There’s little debate about the danger posed by software security vulnerabilities, but there is healthy dialogue around how organizations can respond. The application security market as we know it has existed for about 15 years, emerging alongside interactive web applications and hackers who quickly identified those systems as easy targets.

What’s new since then is a sentiment from application security monitoring vendors that the “old way” of doing things isn’t enough – that software security is so hard to do the right way that you can now take the easy way out by purchasing a product that promises speed and zero false positives and requires no security expertise. However, this notion completely misses the fact that software has changed massively in the last 15 years and truly effective application security has evolved with it. You still can’t solve this challenge by simply buying a tool.

Interactive Application Security Testing (IAST) describes a technology approach first created in the mid-2000’s to augment automated black box penetration testing tools with code instrumentation. The early iterations of this technology relied on aspect-oriented programming to wrap an app and monitor all the program calls in and out, improving the thoroughness and efficacy of penetration testing. In recent years, these solutions moved away from programming-intensive approaches to rely on debugging and profiling APIs in application runtime environments to accomplish the same goal of improving application security vulnerability detection accuracy.

IAST as panacea
What is new in this space is the positioning of standalone IAST products as a panacea of application security – the last software security technology that you will ever buy, simultaneously rendering obsolete all static analysis tools, dynamic web application scanners, and even human penetration testing. Standalone IAST products are billed as passive security monitors that detect all of the relevant security vulnerabilities in your applications – without any security expertise or testing required. You just drop into your application a software agent that installs into the application runtime environment and let it go.

As your quality assurance (QA) team is trying to find functional or performance bugs in a test environment, this software agent (that has instrumented all of the interesting parts of the application) will detect some security vulnerabilities. However, can it, by itself, find all of the security vulnerabilities you really need to fix? Not even close.

IAST as speed trap
I liken standalone IAST products to a police speed trap on the freeway. The speed trap is set up at certain points in an application’s call graph. Optimized for places that are most likely to contain offenders – such as the intersection between User Input Drive and Database Avenue – they can’t possibly watch everything happening in your app. If there was a cop on every corner, traffic would be atrocious; similarly, overzealous monitoring would kill your application’s performance. Nevertheless, these speed traps can be extremely accurate at detecting offenders when properly placed and calibrated to see the one thing they’re designed to see: a speeding car. Or, in our case, a security vulnerability of a known type and signature. But, they can’t do anything else, and they can’t detect where they’re not looking. Finding a security vulnerability or two is interesting, but it’s not enough to make the environment safer.

Standalone IAST products are monitors that can produce an interesting result in the right conditions. By itself, an IAST product can never provide a complete and accurate method of detecting all of the dangerous security vulnerabilities that exist in your software. Following are three shortfalls of the standalone approach and how “traditional” application security technologies are more important than ever.

Shortfall #1: IAST is useless outside of Java and .NET
IAST solutions are based on APIs made available in the Java and Microsoft .NET runtime environments, and hence are restricted exclusively to applications running on these platforms. The APIs are rich and available, and the number of security problems are fairly numerous. However, it’s hard to rely on a detection technology that covers just a small percentage of your apps.

Shortfall #2: Passive vulnerability detection is unreliable
If you follow the storyline of standalone IAST solutions, you can forego security expertise, education and automation, and rely on your QA team to find security vulnerabilities. Are you comfortable that your QA team is ironing out every logic path, use case, edge case, negative test, performance scenario and data flow of your application? You certainly aren’t producing bug-free software, so banking your software security on your QA team’s ability to exercise an application that a passive security monitor is watching for a small set of vulnerability categories is a leap of faith. We must prioritize proactive coverage, completeness and accuracy over passive convenience in software security.

Shortfall #3: Accuracy and performance matter, and expertise isn’t optional
Performance and usability matter significantly when implementing a security solution, and application security monitors are notoriously heavy in how much memory and processing they can use when doing an extensive analysis of a running application. Whether the IAST product is doing taint analysis or some other form of data flow analysis in real time, it will have an impact on your application because it has to completely follow all data flow paths, of every method exercised in your app, for every program call that is detected. Simple IAST solutions will crush your app, dramatically slowing performance. Faced with that, the first thing that IAST vendors do to speed up is analyze less and cut corners to get performance to acceptable levels – at the expense of security. Ironically, the most effective use of IAST technologies is improving the accuracy, speed and coverage of DAST scanners.

Security expertise will always be required in effective application security no matter what kind of automation tool you are using. Standalone IAST solutions may produce some actionable security results, but someone still has to act on the findings. QA teams simply don’t have the skill set, and application security expertise is still required somewhere in your organization to triage results, prioritize remediation, suppress false positives, and judge the efficacy of the program. Software cannot replace expertise. Software can only make it scale better through automation.

[Read an alternative industry perspective on application security from Jeff Williams in What Do You Mean My Security Tools Don’t Work on APIs?!!]

Jason Schmitt is vice president and general manager of the Fortify business within the HP Enterprise Security Products organization. In this role, he is responsible for driving the growth of Fortify's software security business and managing all operational functions within ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
8/18/2015 | 9:16:27 AM
Wrong on the facts, wrong on the impact
I'll be posting a more detailed response shortly, but this article seriously mischaracterizes modern IAST.  IAST takes the best of static, dynamic, and runtime technqiues and delivers them via an agent that runs with the full context of the application.

I understand a legacy tool vendor attempting to criticize a newer better technology to try to maintain market share. It's very easy to verify that IAST performs considerably better in both vulnerability coverage and accuracy (see the OWASP Benchmark Project).

But the implication that static analysis (SAST) is better for experts is ridiculous. I know dozens of companies that have large teams of people whose entire job is to triage false positives. We need that expertise focused on threat modeling, security architecture, and implementing defenses.... not "onboarding" and triage.
User Rank: Ninja
8/17/2015 | 7:32:01 AM
First,-- you have to actually want security
look at the new EMV cards

they include a magnetic strip.   the magenetic strip is the element responsible for the card hacking debauch that has disgraced PCI for the past several years

but they don't get rid of it.  because security is secondary: ease of used is first priority .   so, the debauch will continue .
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in GitHub Enterprise Server that allowed authenticated users of the instance to gain write access to unauthorized repositories via specifically crafted pull requests and REST API requests. An attacker would need to be able to fork the targeted ...
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user with the ability to fork a repository to disclose Actions secrets for the parent repository of the fork. This vulnerability existed due to a flaw that allowed the base reference of ...
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in the GitHub Enterprise Server GraphQL API that allowed authenticated users of the instance to modify the maintainer collaboration permission of a pull request without proper authorization. By exploiting this vulnerability, an attacker would b...
PUBLISHED: 2021-03-03
A remote code execution vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. User-controlled configuration of the underlying parsers used by GitHub Pages were not sufficiently restricted and made it possible to execute commands on the Gi...
PUBLISHED: 2021-03-03
Pug is an npm package which is a high-performance template engine. In pug before version 3.0.1, if a remote attacker was able to control the `pretty` option of the pug compiler, e.g. if you spread a user provided object such as the query parameters of a request into the pug template inputs, it was p...