3 Metrics For Determining Whether To Outsource Your Web Application Testing

websec

 

There's a seemingly timeless question within the halls of infosec departments worldwide: do we take on security testing ourselves, or do we find a vendor to do it for us?


The question is valid for a number of types of security testing, but there's a general trend worth noticing: as technologies come to be considered part of infrastructure rather than a series of one-off exceptions, the ability to bring testing in-house increases. As a case-in-point, network security used to be quite exotic and it was commonly outsourced, but these days it's often part of the woodwork, just like general networking infrastructure.

 

This is not so with application security, as it is not only a more recent problem but the problem itself is more slippery. Network stacks tend to look alike, and it's much easier to secure something that has less variation. Web applications aren't so easy to neatly package, as there are numerous ways to build them, secure them, deploy them, etc.

 

Web applications are wild, and they probably will be for some time.

 

So how do you know whether you can handle testing your web apps internally? Here are three considerations that can help guide your decision:

 

  1. Team: Make sure you have the right team internally if you're going to make an attempt to handle it in-house. You need extremely versatile talent that has both developer and info/appsec skillsets. If they lack the developer perspective they won't be able to communicate properly with those that matter -- the people who will be fixing the problems. If you don't have security people they'll be unable to convey why the issues are a problem, and nobody will listen. The people on the team must have both qualities.
  2. Capital: Determine whether your organization has the political and technical respect capital to move a program forward in your organization. If your group, for whatever reason, usually loses when it conflicts with those on the creation and business side, don't throw yourself against the mountain. If you can find a way to fix that problem, make that effort, but it is often more conducive to progress to have a third-party bring the news with the implicity support of upper management.
  3. Priority: Decide where your total priorities lie in terms of all the things that you want to accomplish as an internal team, and determine whether running a permanent webappsec vulnerability management program that will consume a good portion of your team is a proper use of your resources given those priorities.

In short, the decision is fairly simple once you consider these three things: Team, Capital, and Priority (TCP). If your answer is no to any of these questions then you should consider outsourcing:

 

  1. Do you have a security team whose members have a hybrid skillset of development and appsec knowledge?
  2. Does your team have the political and technical respect within the organization to affect change?
  3. Are you sure that, given all the other priorities on your team's plate, managing an ongoing websec vulnerability management program is the best use of your team's time?

Keep in mind that these are not the only considerations; cost and other obvious elements need to be part of that equation, but if you can't answer yes to all three of these imporant questions you may not want to waste any time on doing a cost calculation.

 

::

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
http://www.danielmiessler.com/about


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation