IT Briefcase Exclusive Interview on Web Application Protection:
In today’s interconnected landscape, we interact with countless web applications every day whether we know it or not. Naturally, cybercriminals love targeting them. According to the 2016 Verizon Data Breach Investigation Report, web application attacks are the top source of data breaches today. An expert in data privacy and security, Waratek EVP James E. Lee dives into a common method of protection in web application security, why it’s problematic and where the industry is headed.
Q. What are some of the problems currently facing the state of web application protection?
Without a doubt, the current preferred approaches to protect against known code injection attacks in web applications involve some variation on applying a patch, fixing the vulnerability or disabling the flawed functionality, if possible. Web application firewalls can mitigate some threats, but are often plagued by high false positives and are limited in what they can “see” and how they contextualize this as traffic flows into an application.
The bottom line is this: We remain too dependent on heuristics when all evidence points to a massive failure of traditional security approaches to defend modern web applications.
Q: What’s the problem with heuristics?
By and large, cyberattacks are so successful because security professionals continue to rely too much on heuristics. That’s not surprising since historically that was the only approach generally available. By definition, though, heuristics are inaccurate. Accoring to Wikipedia, the term literally means “a practical method not guaranteed to be optimal or perfect, but sufficient for the immediate goals.” In other words, an educated guess – but still a guess.
And a big problem—often a fatal flaw—with all heuristics-based security approaches is the abundance of false positives. Chasing false positives can easily cost the average business more that $1M each year. Plus, most heuristics-based approaches are limited to only part of the application stack and they require instrumentation or filters to work. Again, by definition, if you are only instrumenting part of the app stack, you are not going to get comprehensive or highly accurate information and protection. Emerging heuristic-based runtime solutions can also introduce significant performance overhead. At the end of the day, heuristics give you a solution that is expensive, inaccurate, incomplete and it may slow down your application as a bonus.
If we want to fundamentally improve application protection, we’ve got to take the guesswork out of security solutions and add certainty.
Q: What are the potential issues with using heuristics and what’s the alternative?
Let’s talk about the most common heuristic-based AppSec tool. Web Application Firewalls (WAF) use naive rule triggers, pattern matching, regular expressions, and/or black/white lists. Any article that explains how WAF solutions work, describes how profiling of each application is required before enabling any protection. After profiling, custom rules may be required and those must be written by security experts who understand the unique technical specifics of each application. Routine tuning is generally required especially after new code is added to that app. And, even after all this effort, the protection will still not be adequate due to the nature of heuristics and limitations of instrumentation.
The most effective alternative is a defense-in-depth cybersecurity strategy that includes a runtime security solution based on virtualization. One non-heuristic approach puts security inside an application at the runtime using a secure virtual container wrapped around the vulnerable application. This requires no code changes, routine tuning or instrumentation, and takes only minutes to install, providing instant protection from the OWASP Top Ten as well as zero day attacks. Virtualization also allow us to determine if an operation is an attack or a permissible request with pinpoint, 100% accuracy.
The Waratek Application Security Platform allows you to see each transaction in real-time to determine if it is a legitimate transaction resulting in no false positives. All without the labor-intensive actions or performance degrading heuristic approach found in other traditional and some emerging approaches.
Q: Can you give us an example of how virtualization works?
Using a virtual container protects the full application stack – business logic, third party components, platforms, APIs, etc – not just select sections of code that you can access and instrument. A virtualization-based approach can detect and block attacks with 100% accuracy without generating the false positives you see with WAFs and other technologies that rely on heuristics and signature-based detection.
Virtualization also delivers benefits not possible in security approaches using instrumentation or filters. For example, you can apply code-equivalent virtual patches without taking an application out of production or making code changes, providing instant protection from newly reported exploits. You can also virtually update legacy applications to the latest platform version without touching a single line of code. That adds years of useful life to existing applications without the cost or resources required to refactor an app.
Q: What methods of protection are effective in the virtualized runtime environment?
Virtual containers make rules-based protections, like the 2013 OWASP Top Ten, easy to apply and deploy in both detect and protect mode without degrading the performance of your app. But, virtualization also provides a platform to address more complex attacks at the category level (CWE), not just at the individual vulnerability level (CVE).
A great example is how you can address code injections – all code injections – using an approach based on a proven technology used in all major OS. During the past decade address space layout randomization (ASLR) has become a standard OS feature and a significant guard against buffer overflows and similar attacks by randomizing the location where system executables are loaded into memory.
Name Space Layout Randomization (NSLR) is based on the same principle as ASLR, but applied for the first time as an application security feature for the Java runtime. NSLR hardens the Java Virtual Machine by randomizing the JRE namespace (Java packages). Using NSLR inside the JVM, the ownership of bytecode loading is standardized and unvalidated bytecode fails to be executed.
In effect, this makes bytecode tampering and a range of code injection exploits so difficult to execute that they become unfeasible, protecting against known and unknown vulnerabilities, including zero day exploits.