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
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 .
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft to Officially End Support for Windows 7, Server 2008
Kelly Sheridan, Staff Editor, Dark Reading,  1/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7227
PUBLISHED: 2020-01-18
Westermo MRD-315 1.7.3 and 1.7.4 devices have an information disclosure vulnerability that allows an authenticated remote attacker to retrieve the source code of different functions of the web application via requests that lack certain mandatory parameters. This affects ifaces-diag.asp, system.asp, ...
CVE-2019-15625
PUBLISHED: 2020-01-18
A memory usage vulnerability exists in Trend Micro Password Manager 3.8 that could allow an attacker with access and permissions to the victim's memory processes to extract sensitive information.
CVE-2019-19696
PUBLISHED: 2020-01-18
A RootCA vulnerability found in Trend Micro Password Manager for Windows and macOS exists where the localhost.key of RootCA.crt might be improperly accessed by an unauthorized party and could be used to create malicious self-signed SSL certificates, allowing an attacker to misdirect a user to phishi...
CVE-2019-19697
PUBLISHED: 2020-01-18
An arbitrary code execution vulnerability exists in the Trend Micro Security 2019 (v15) consumer family of products which could allow an attacker to gain elevated privileges and tamper with protected services by disabling or otherwise preventing them to start. An attacker must already have administr...
CVE-2019-20357
PUBLISHED: 2020-01-18
A Persistent Arbitrary Code Execution vulnerability exists in the Trend Micro Security 2020 (v160 and 2019 (v15) consumer familiy of products which could potentially allow an attacker the ability to create a malicious program to escalate privileges and attain persistence on a vulnerable system.