Monday, June 16, 2014

Choosing the Right Entry Point for a Software Security Program

The topic of software security, or AppSec, has once again cropped up recently in my travels and conversations so I thought it would be prudent to address that here on the blog. As someone responsible for software security in an enterprise, Fred was being given a small pool of money and a chance to plan, design, and implement a software security program. The big question on Fred's mind then, was where to start.

As we talked through the options, and I discussed some of the mistakes I've made and have witnessed others make, I tried to advise Fred to be cautious. One of the most important things one can do wrong when starting a software security program from scratch is starting in the wrong part of your Software Development Lifecycle or SDLC. This can be exacerbated by the fact that many organizations have many more than one software development lifecycle, and picking the wrong starting block is quickly amplified.

I explained the three main parts of any application's SDLC - and quickly realized I needed to elaborate. Each of the applications in your enterprise fall into one of the following 3 categories:
  1. Existing or "legacy" applications - applications which are currently in a steady state, or in other words there is no current plan/effort to modify the application code
  2. Currently under development - applications which are currently undergoing a development effort of some kind
  3. Future development effort - applications which have a planned development effort for some point in the future

Why it's a bad idea

Theoretically, you could tackle each of the 3 options above with a new software security effort - but why are any one of them a bad idea?
  • Existing/legacy applications - The main reason it's a terrible idea to start with legacy or existing applications is that they likely don't have any velocity; what I mean by that is that there is currently no capital or resources to do anything with these applications. The worst-case scenario if you are unlucky enough to start with legacy applications is that you find something catastrophic and are then faced with the stark reality that nothing can be done about it because there are either no resources, no capital, or both.
  • Current development - Applications currently under development pose the challenge that they already have momentum which is difficult to get in front of. What I mean here is that many times applications currently going through the pipeline have requirements done, capital and resources already allocated and deadlines set. Security folks showing up and demanding to be inserted into the process are rarely welcomed with open arms even in the most security-friendly atmospheres.
  • Future development - The problem with software projects which will have a future date for development effort is that they can become a moving target. There may or may not be any urgency, and today's security requirements may change by the time the project actually kicks off. 

Getting a good start

The fact is, the safest point of entry for your software security program is into those future development efforts. While your senses may tell you that the optimal place to jump in is with applications currently engaged in a development effort, or applications which are already in steady-state, realistically you don't want to get either in front of a moving train with momentum, or try to push a boulder with no momentum. The future development effort option both provides you with an opportunity for planned momentum and the promise of nothing being already set in stone.

If you're anything like me, your senses are screaming at you to look at the existing or legacy applications - after all that is probably the point where there are the most security issues. Applications that were developed and left to run often don't get much attention and therefore fall derelict, with the "don't touch it, you could break it" attitude. There is also the chance that these applications are of the 'brittle' class - which means your security testing will highly likely cause some catastrophic failure - and you really don't want to start with a catastrophic issue, believe me.

As Fred is making plans to engage the development organization, the business analysts, and the operations group - he will need time to analyze and understand which means he wants some runway. The safest place for him to engage, and the point at which he maximizes his chance of a successful initial engagement is with the future development effort. Once you've got a few planned wins under your belt, like Fred will soon, you will have coincidentally addressed applications in the pipeline, and will only be left with legacy or existing applications. That's something we can tackle in a future post, because that's a special animal in itself.


@boettcherpwned said...

I agree with you Rafal. We talk about pushing security to the left, but if you start all the way on the right, you have way too much to overcome. But how far do you go? The hiring process?

@boettcherpwned said...

I agree that in most situations that is wise advise. Let's go two steps farther (we'll skip over dev security training for now). Is inserting yourself into the dev hiring process pushing security too far to the left?

Rafal Los said...

I don't think that's 'too far' at all! Security should absolutely be a part of the developer hiring process... do they even have a clue? Are they careless? Do they have the desire to write code that is 'safer'?

Totally with you on this aspect!