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

8/12/2015
03:30 PM
Jason Schmitt
Jason Schmitt
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
planetlevel
50%
50%
planetlevel,
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.
macker490
0%
100%
macker490,
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 .
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7029
PUBLISHED: 2020-08-11
A Cross-Site Request Forgery (CSRF) vulnerability was discovered in the System Management Interface Web component of Avaya Aura Communication Manager and Avaya Aura Messaging. This vulnerability could allow an unauthenticated remote attacker to perform Web administration actions with the privileged ...
CVE-2020-17489
PUBLISHED: 2020-08-11
An issue was discovered in certain configurations of GNOME gnome-shell through 3.36.4. When logging out of an account, the password box from the login dialog reappears with the password still visible. If the user had decided to have the password shown in cleartext at login time, it is then visible f...
CVE-2020-17495
PUBLISHED: 2020-08-11
django-celery-results through 1.2.1 stores task results in the database. Among the data it stores are the variables passed into the tasks. The variables may contain sensitive cleartext information that does not belong unencrypted in the database.
CVE-2020-0260
PUBLISHED: 2020-08-11
There is a possible out of bounds read due to an incorrect bounds check.Product: AndroidVersions: Android SoCAndroid ID: A-152225183
CVE-2020-16170
PUBLISHED: 2020-08-11
The Temi application 1.3.3 through 1.3.7931 for Android has hard-coded credentials.