Five Reasons Why You Need an Application Security Program

Thursday, June 28, 2012

Fergal Glynn


Article by Jasmine Noel

Many organizations looking at application security for the first time struggle with understanding why they should take a programmatic approach to tackling application security.

I’ll touch on five reasons in this post to have a program to deal with application security.

1) Address the full scope of the problem

A quick look at Quocirca’s survey results shows that financial services organizations track around 800 mission-critical applications, those in other industries track around 400 applications. Those applications are conduits to corporate data and intellectual property.

The simple fact is that if someone wants your intellectual property, they are going to use software you bought, built or outsourced to get at it. In our SOSS Feature on Public Companies, we looked at results from several other research projects that track the root causes of data breaches.

While none of these research methodologies are perfect, the data from these projects shows that remediating application vulnerabilities goes a long way towards putting a data loss prevention program in place. Securing a handful of applications isn’t going to work anymore.

An application security program gives organizations a way to deal with the large scale of the application risk by making the application conduits to your data as difficult as possible for unauthorized people to use.

2) Simplify the compliance effort

Increasingly, industry standards bodies are incorporating requirements to show evidence of how you protect against data breaches and patch software vulnerabilities. It seems like every month I get a request to show how our platform helps a company comply with a standard that I’ve never seen before.

Usually I just point folks to one of our webinars on policy management, because what an application security program does is help organizations create self-complying software development lifecycle (SDLC).

By that I mean that security testing and remediation and retesting are integrated into the SDLC. Then the results are automatically analyzed and reported to show compliance (or progress towards compliance) with the OWASP Top Ten or SANS/CWE Top25, which most standards bodies will accept as evidence.

3) Knowledge is power

Managing risks is about making tradeoff decisions. Anyone that participates in fantasy sports leagues instinctively knows this because they have to make tradeoff decisions every week. Would you start or sit a player that’s hurt?

The answer is maybe – it depends on what you know about his injury and what role he would play in your game plan. Managing application security risks is about making a different set of tradeoff decisions. Would you put this application into production with vulnerabilities?

The answer is maybe – it depends on what you know about the application vulnerabilities and what role the application would play in achieving a business goal. Security policies are supposed to encapsulate that knowledge.

The problem is that organizations often don’t know much about their application inventory, or their application’s vulnerabilities, or the risks those vulnerabilities pose, or which vulnerabilities to fix and when, or what they are doing right and wrong when it comes to managing vulnerabilities.

A program provides a focal point for collecting and analyzing information related to application security so that you can make better decisions.

4) Enable third-party vendor management

Large organizations purchase and outsource development of a ton of software – their development teams also depend on software platforms and libraries from third-party vendors to speed up internal development. Because organizations have little control over third-party source code, the company must blindly accept the risks inherent in third-party software.

While many purchasing and outsourcing contracts include language about software security, it’s been a toothless requirement depending on verification questionnaires which are probably filled out by the vendor’s IT executive, who probably has a plateful of other concerns.

An application security program can enable procurement departments to develop some verification teeth using application testing methodologies to determine the actual software risk which procurement can use as a leverage point during negotiations.

5) Roadmap for organizational change

As one of my executive mentors keeps telling me, “a strategic change plan is something I must repeat to everyone over and over again until they get it, so I’d better make it simple enough to explain in a few minutes but I’d better have a framework behind it so I can back it up with dashboards and metrics.”

An application security program gives enterprises the opportunity to organize their efforts around a strategic plan which can be widely communicated. With an application security program, you can lay out a framework for:

  • Tying security activities to business goals and requirements, which you will need to initially garner executive support and keep them interested as time passes.
  • Building a step-by-step implementation roadmap, where each step is designed to deliver tangible results.
  • Measuring your results, where you choose metrics that matter to your executives in terms of organizational culture/behaviors (e.g. number of development teams scanning application builds), key business processes (e.g. number of apps rolled back by QA), and the application portfolio’s risk profile (e.g. application vulnerability density over time).

So those are five reasons for a program, would love to hear of other reasons your company has adopted a program. In my next blog post, I’ll talk about five tips to build a successful application security program.

Cross-posted from Veracode

Possibly Related Articles:
Information Security
Compliance Enterprise Security Risk Management Application Security Vulnerabilities Vendor Management metrics Remediation
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.