Why Application Security Penetration Testing Fails to Deliver

You understand the value of security penetration testing for your software applications and it’s been successful identifying important vulnerabilities.  You do the obvious thing, order more pentesting but in successive tests the arrival rate of new application vulnerabilities soon exceeds your technical teams ability to remediate them.  Management and technical teams security vulnerability epiphany soon turns to malaise as security becomes increasingly marginalized in favor of progressing against more tangible objectives – customer facing software features.  What happened?  Could this have played out differently?

The limitation of application penetration testing is that it reveals the symptoms of a problem without revealing underlying causes.  I’ll explain, poor application security is a technical manifestation of a business quality problem.  I know I’m speaking in riddles but stay with me for a moment please.  That’s right, application security is a business quality problem and pentesting does absolutely nothing to slow the introduction of new flaws into an already flawed application system.  A strong focus on pentensting alone is like a doctor complimenting a patient for a healthy diet while the patient is on their way to the smoking area for well-deserved cigarette break.  Pentesting is an essential component of a larger security process – it should not be your entire security quality process.

So how can application security be a business quality problem?  Let’s continue further with the medical analogy.  Surgical processes and controls are extremely important for successful of patient outcomes.  The entire operating room must be cleaned and sanitized including, instruments, doctors hands, all the uniforms worn by staff, scrubbing and cleaning surgical facility contact areas with disinfectants.  Virtually every aspect of the surgical process is meticulously scrutinized for sanitization quality.  The quality of the surgery and experience of the surgeon are important but with little or no focus on sanitation successful patient outcomes are unpredictable.  Developing secure software is exactly the same challenge.  Building secure software is a quality process and it takes the combined effort of many people; in fact, everyone that plays a role in it’s creation.

So how can we make progress on strengthen our software applications?  Instead of narrowly focusing security assets on the final products, a software binary, or deployed cloud service.  All aspects of software creation from it’s inception, design, development, testing, deployment, and sun setting must be considered for a secure solution.  If security is the checkbox at the end of the release, then you may identify security problems but it’s unlikely you will win support to fix them before deployment.  If you believe security is a problem of poor engineering than your missing the point.  Software quality is a business leadership responsibility.  Engineers should not have the authority to decide upon the level of security quality the software ships or deploys with.  Unlike traditional testing, security works best as a front-loaded combination of process and controls where it can influence projects earlier and measure security progress as development proceeds with involvement and oversight tapering off as projects come to a close.  Why is this important?  Simply this, is far easier on the business and everyone involved to change a bad idea than it is to change a million lines of crappy code.  Fixing a bug or vulnerability is easy fixing architecture is a disaster.  To avoid these outcomes security must be invited to the party early.

I admit, considering application security as a process, front-loading projects with security oversight, adding stronger security controls throughout the process, seems counter intuitive when you want think less about security.  A benefit of early security influence is that it reduces late project surprises or at least the scope and depth of security surprises near delivery time.  The value of pentesting is as a final spot check to an already high quality comprehensive program process.  No amount of pentesting will make poorly architected software applications secure.  Likewise, no application firewall can dig a moat deep enough around your datacenter to defend a poor application security architecture or missing security quality process.  The best way to make an application secure is to improve all your software security processes controls to from cradle to the grave with an emphasis of focusing more security attention at the start of projects where it has the most impact.  In such a model, pentesting then becomes security spot testing.  If pentesting uncovers repeated serious defects then it’s likely an indicator of a weakness in security standards, processes, or controls in the software process that require further improvement.  Strong application security posture is a business choice.  It always has been.

owasp.org, Secure SDLC Cheat Sheet
bsimm.com, Building Security in Maturity Model

 

Image Raised Fist from openclipart.org

Author: milton

For bio see, https://www.securitycurmudgeon.com/about/