Software Security Is Hard But Not impossible

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?!!]