The Need for Real-World Runtime Protection Benchmarking
First-principles thinking is one of the best ways to reverse-engineer complicated problems and unleash creative possibility. Sometimes called “reasoning from first principles,” the idea is to break down complicated problems into basic elements and then reassemble them from the ground up. It’s one of the best ways to unlock creative potential, and move from linear to non-linear results.
This approach was used by the philosopher Aristotle and is used now by Elon Musk. It enabled them to cut through the fog of shoddy reasoning and inadequate analogies to see opportunities that others miss.
Application security is in dire need of first principles thinking. There has been an attempt to bolt-on legacy technologies, like static analysis, dynamic analysis and Web Application Firewall (WAF), into streamlined #DevOps pipelines. These tools operate in silos and dump huge quantities of alerts onto security and development teams that have no real way to identify real from false positives to remediate so many issues. This bottleneck impedes velocity in #DevOps pipelines and, as a consequence, security is being left behind in many organizations.
ShiftLeft is the industry’s first converged solution that seamlessly integrates into the #DevOps pipeline and protects the application by identifying its attack surface without reacting to threats.
Today we’re announcing the industry’s first public real-world benchmark of a continuous application security solution. In the benchmark test, we submitted two instances of a vulnerable application to expert penetration testing. One of the instances was protected with ShifLeft and the other was unprotected.
DevOps automation, agile methods, cloud computing, virtual machines and containers have dramatically sped up the pace of releases, while application security and runtime protection have barely evolved. Therefore, to mimic real world constraints, products must be tested for their abilities to identify and protect against vulnerabilities, without slowing down new feature releases.
Test Application
The test application is a simple REST-based multi-tenant application emulating the functions of a retail-banking interface, including routes. Two instances of the application were deployed into a cloud environment. The application was intentionally built to be vulnerable. Hence, a security benchmark could be established between the protected and unprotected instances.
Test Methodology
The testing methodology created three (3) isolated teams:
- Development: Built the vulnerable application and deployed two instances of it
- Security: Instrumented one of the two instances with ShiftLeft
- Pen Testing: (Performed by Coblalt.io) attempted to exploit both applications
The development team built an application that included 6 of the relevant OWASP Top 10 vulnerabilities, including:
- A1-Injection — SQLi
- A2-Broken Authentication — HTTP secure cookie
- A4-XML External Entities — XXE
- A5-Broken Access Control — Path traversal
- A8-Insecure Deserialization — Java deserialization
- A9-Known Vulnerabilities — Known OSS vulnerability
Next, two instances of the application were created. One instance was hosted without any security protection. Another instance was protected by ShiftLeft, which extracted the application’s security DNA in order to create a custom security profile that protected the application in runtime. The security team that was protecting the instance with ShiftLeft had no knowledge of how the application was built or how Cobalt.io might attempt to breach it.
Finally, Cobalt.io performed a 14-day penetration test against both applications. Cobalt.io had 3 white hat hacking experts attack both applications. Cobalt.io was able to find and exploit all 6 vulnerabilities in the unprotected test application. However, the application protected by ShiftLeft could not be exploited during the test.
Full Results Report & Details
For Cobalt.io’s full penetration testing results report, more detail about the test methodology and to learn how ShiftLeft’s protected the vulnerable application, please visit our Runtime Protection Benchmarking webpage.
The Need for Real-World Runtime Protection Benchmarking was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Andrew Fife. Read the original post at: https://blog.shiftleft.io/the-need-for-real-world-runtime-protection-benchmarking-544fedbe4e98?source=rss----86a4f941c7da---4
