Prescriptive Software Security Assurance for SMBs

Wednesday, May 25, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

A while ago I wrote a post titled "SSA in a "One Man Show" and I had a few of you respond directly back to me stating you were experiencing some of these issues, and couldn't wait for the 2nd half of the post to get my thoughts on this difficult subject.  

This post is the 'now what'... aimed at those of you who work in a small to medium-sized shop, and are essentially a one-{man|woman} show...

Now, let me start off by saying I don't envy you. It's hard enough to get a Software Security Assurance (SSA) program off the ground with an army of support - but it's a hat-trick and a half to do it if you're the only one.

So what do you do...?  The crucial first step is to identify a sane 'end-game' for yourself.

What are your organizational tolerances?  Does your company live online, or are you a widget manufacturer with brick-and-mortar mentality?  Maybe you're somewhere in between those.  

No matter what your business model here are some prescriptive steps to getting it done... err... at least off to a start.

  • Identify yourself -- As I stated above, you have to know what type of organization you work for, and what role applications and technology play. This directly correlates to the level of impact you're going to have on the organization, and the appetite for 'security' the organization will have. For example, a hundred-year-old industrial organization will feel differently about its applications than a bank, web-tailer (retailer with a heavy web presence), or company that derives a majority of its profit from a connected presence.
  • Connected dependence -- This is key - how much of the company's revenue comes from an online presence, and the use of applications? If your answer is little, then you know your efforts to secure applications will likely fall on deaf ears. If your answer is heavy, then you at least have a hope that leadership (with the right amount of context) will invest in securing that revenue stream.  Try and get a dollar-value of how much of your company's revenue stream comes from 'being connected to the Internet', and you can probably ask for 2% of that (or less) for your security efforts.
  • Application registry -- How many applications are there in your environment? Count all the web and non-web applications in your organization that you would like to put 'in-scope' for an application security program.  These are the business enabling tools the organization depends on... now get a rough idea of how many there are.  Do you have 10, 100, 1,000, or more?  This knowledge will impact your plan later on.  Build an application registry of all the applications in your organization and get detailed information on them... more on this later.
  • Buy vs. Build -- As you start to think about securing your corporate applications, it's crucial to know whether they've been bought... or built. Even if you're purchasing a commercial package like SAP and customizing it in-house or (more likely) through the use of consultants, that customized code (ABAP, in the case of SAP) will need to be thoroughly checked out for security defects. Try and get a sense of whether you're more buy, or build... this will help you rationalize whether you should concentrate your effort internally, or externally to the company.
  • Development model -- It's always good to know whether your code is being written by someone in a cube on the 3rd floor, or someone on the opposite side of the world. This is critical because it helps you understand the level of influence you can hope to achieve at some point.  There are no guarantees, but if you're outsourcing your development to China the level of influence is far different than if Mike is your primary developer on 3...
  • Pipeline -- How much application churn does your company sustain?  Are your developers releasing some new code every week? How many apps are currently in development, and how many are out in waiting in the wings?  Go back to your application registry, and try and get a sense for how many times those apps already in production are updated or code-revised each year.
  • Available resources -- We all say we're running at 110% in our organizations - but ask yourself honestly... can you handle the amount of work it would take to ratchet up security on your organization's applications? If you've got anything more than a dozen or so applications in the organization, with more then 5 in the pipeline... you'll need help. Figure on a single non-dedicated resource being able to handle 1 application security test/week... tops.  Now what?

So... go to it! Start with the lucky 7 items I've outlined here... and I'll work on expanding each of these 7 items in future posts. Let me know if this is helpful, and if you're able to get any real-world use from these!  

I am happy to tweak and provide additional information to help you make YOUR end-game.

 Cross-posted from Following the White Rabbit
Possibly Related Articles:
10637
Webappsec->General
Software
Software Application Security Development SSA Software Security Assurance SMB
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.