Enterprise Software Security - The Fake Choice Between Fast and Secure

A question crossed my desk recently that read something like this:

 

"What do you say to organizations considering software security, but struggling with adoption due to the inevitable, additional drag on release cycles?"

 

First, let me say I think this is a false choice — deciding between security and speed. If adding security to your enterprise software development methodology and lifecycle creates a significant amount of drag on the actual release deadlines — for an extended period of time — you’re doing it wrong.

 

You’ll notice I highlighted a part of that last sentence. There’s a reason for this. There is no denying it: If you’re dropping security into an existing software release strategy it’s going to be hell on wheels initially. Whether you’re dropping into a waterfall methodology, Agile, or continuous release, it’s going to initially set a fairly heavy drag on the release process. This pain shouldn’t last very long.

 

The reason why isn’t obvious, and worth explaining from my perspective.

 

In the last six years I’ve probably been responsible, either directly or indirectly, for about two dozen implementations of security into an existing enterprise SDLC (I’ve had success to varying degrees). Each engagement started with a reasonable period of data gathering, then pilot, then lessons learned and then phased/staggered enterprise-wide implementation. At the start of each phase there was the inevitable learning curve, adaptation, and then rapid assimilation of the security processes. That was for the times we got it right. When we got it wrong, that inevitable learning curve collapsed into a plateau and never really got anywhere. That was our indicator to try, try again.

 

This is where I get my argument that speed and security should absolutely not be mutually exclusive. Let’s be realistic though, security processes aren’t entirely going to disappear into the woodwork and become zero-effort (believe me, no one wants that more than those of us pushing software security). The best-case scenario you can hope for is an appropriately designed injection of security — such that the drag balances the benefit of reduced technical risk. In that game, everyone’s happy and no one cries foul.

 

You’ve probably heard the purpose of brakes on a car isn’t to slow the car down, but to enable it to drive faster, right? Same applies to injecting an aspect of security into your software development and release processes.

 

If you think about it carefully, injecting security components into your software development and release methodology early on — and throughout — actually helps you go faster.

 

Follow my logic:

 

Let’s assume that no organization actually wants to release software that forces it to take on unknown amounts of technical risk. If that’s the case, then you want to have better security, but strategically, and in the right places, so you’re not stuck finding out the day before you have to go live that you’ve got major security problems. At that point you’re stuck with more than just having to push a release date — often times enterprises are hit with financial penalties. Even if the code goes out vulnerable, you’re still likely going to have to make the fix at some point. And unless your math is different than mine, you’re still adding to the overall release cycle and wasting a lot of energy needlessly. Of course, I’m not telling you that just because you include security into your requirements cycle that you won’t end up with 100 SQL Injection vulnerabilities in your web application, but I am telling you the likelihood is significantly less, and your overall release velocity is better.

 

So, back to that original question.  What do I say to those organizations considering software security, but struggling with adoption due to the inevitable, additional drag on release cycles?

 

First, it’s 2013 and if you don’t have a software security strategy by now, odds are your adversaries have beaten you multiple times, and you haven’t realized it yet. Second, someone is making cheap excuses. Software security is as much about speeding up the release cycle as it is releasing safer and less risky software.

 

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


Follow Us
Community Announcements
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