Software Security Assurance in a "One Man Show"

Friday, April 15, 2011

Rafal Los


Recently I was challenged with applying some of the more critical components of SSA to what was termed as a "one man show" (or "one person show" to be totally correct).

Thinking about down-scaling an enterprise security challenge into a smaller fit proved far from easy.

This manifested as more of a challenge than you'd think because it's just too easy to say 'outsource it all'... but how does that actually help an organization write more secure software?  

The answer is that it doesn't... so over the next few posts I'll go over the challenges and some opportunities in cases like this - and as always if you are living this situation drop me a note and tell me your experiences and share with your colleagues!

The Organization

The key to talking about a situation is making sure that everyone understand the problem.  

Too often I've found myself talking about what I feel is a great solution to a problem posed, in a group, where all of us understood the problem slightly differently... so here is a brief definition of the type of organization I'm addressing.

  • Security Resources: 1 (or few) security engineer(s) responsible for multiple roles within the security context both operational as well as advisory.  This may include patching, firewall management, policy creation and application security 'testing'. Key here is that there are no dedicated resources for managing, or staffing the various roles and responsibilities or tasks of an SSA program.
  • Budget Resources: little (or virtually none) budget dedicated to 'SSA' ...but may have a budget for tools related to 'application security testing'
  • Number of Applications: "moderate" (>10...100 ...or so)
  • Executive Visibility: Typically executive visibility of risk is low ...or none.
  • Organizational Buy-in: Minimal ...typically viewed as security's job, or just a function of arbitrary compliance with minimal standards - not actual security

The Challenge

The main challenge here is getting beyond the hamster-wheel situation I've discussed before.  What generally happens in situations like this (from experience, ahem) is the following (usually in this order):

  • security concerns are ignored by management, applications released without security purview
  • organization fails audit (application security is a, failure)
  • organization panics, tells 'security' to go fix the problem (no budget)
  • security defines proposal for an SSA program
  • leadership rejects proposal, 'do the minimum' instead
  • security purchases scanning tool (SAST or more likely DAST)
  • security is a 'final checkbox' in a project pre-go-live
  • 'scanning' is done, apps fail but are pushed through
  • no measurable gains in application security or risk mitigation

This probably looks familiar, doesn't it.  If you've felt this challenge before stick around, the next posts will directly address some of the issues that you face, and how to get you off the hamster-wheel and get you into a situation where you're actually helping the organization meet the challenges, and meet your goals as well.

Coming up...

  • Rationalizing business goals vs. security goals in a 'small shop'
  • Meeting the resource challenges of SSA in a 'small shop'
  • Implementing holistic SSA (mentality not 'tools')
  • Implementing technology
  • Measuring and proving success
Cross-posted from Following the White Rabbit
Possibly Related Articles:
Management Budgets SSA Software Security Assurance applications
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.