Deploying Code Faster as a Security Feature?

Tuesday, July 24, 2012

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

If you don't follow Zane Lackey on SlideShare, you probably should.  

His presentation recently uploaded titled "Effective approaches to web app security" recently touched a nerve that has had me thinking about the different perspectives people can have on a particular aspect of anything - DevOps in this case.  

Go look at slide 14 from Zane's presentation... I think that slide says it all.

"Being able to deploy quickly is our #1 security feature" states Zane, in his deck.  The presentation in itself gives many of the software security assurance folks I know out there a run for their money in terms of simple elegance.

For me slide 14 caught my attention and I kept coming back to this because of my background colliding with my new focus lately. Think about how different people in your organization would answer this question: "How do you view the capability of your enterprise to deploy code to production many times per day?"

  • Typical InfoSec answer: Certain disaster waiting to happen.  Information Security teams have for years been trying to insert themselves into the SDLC (software development lifecycle) which means slowing down the release process long enough to get a thorough security analysis of the code being deployed.  This task cannot be done without understanding context, architecture, goals and more ... so we slow down even further.  If you're trying to deploy more than once every couple of weeks you're not giving anyone in security time to understand, review and make recommendations.
  • Typical developer answer: Fantastic!  Deploying more often leads to the ability to 'fix on the fly' when things don't quite work as expected ... or even better you can deploy changes in micro-components so that you can isolate a specific feature to be deployed and not have to wonder whether it was the SQL query you modified, the database scheme change, or the user interface that's causing the application to slow down - each change is made one at a time.

OK, so it may not always sound like that, and I have over-simplified the answer just a bit to keep this post from being a book, but you get the idea.  As developers and information security professionals we tend to see things from different angles - a push/pull.  Security wants to go slower while developers want to speed up - and you can guess this generates a lot of heat and friction in the IT department.

What if, as Zane says, deploying faster is actually a security feature?  I can certainly empathize with the frustration many security professionals feel when they find a critical issue in an application only to be told that the patch will be rushed... in about 3 months. I'd certainly love to hear that the update will be shipped this afternoon... wouldn't you?

As rosy of a picture as this is, it's still not trivial to insert good, solid, security and risk management into a process that gets looped many times a day.  But as my friend and colleague Gene Kim says "Shorter loops, more feedback!"... and the industry seems to agree with him.

We know there are 2 parts to workable software security: designing security in, and validating it when complete.  So what happens when we squeeze hard and press that gas pedal to go faster... does security fall off the to-do list?  

Or can we simply find some magic formula to front-load security practices into the design security in bit, and set up the validation through automation so that we're not penetration testing ourselves secure?

The idea that we can get to a state where security is done on the front-end of an SDLC, by people who have vested interest in security from the start is great - but I just don't think it's universally applicable.  

It may be great at Etsy, Netflix and other places where we know it works because the leaders there are smart developers and AppSec people - but what about the other 99.999% of the software development industry who just want to release faster without all that security expertise?

Well, I don't have an answer to that... but I suspect it lies somewhere between education and automation.  Ultimately we're going to need to raise awareness to a point where security is ubiquitous in the SDLC and just part of something developers do without thinking, then support that with an insane level of automation based on today's existing technologies.  

We desperately need to get away from trying to "test ourselves secure"... we do... and I think people like Zane and James Wickett (go check out his gauntlet project) have the right idea.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
8467
Webappsec->General
Software
Patching Application Security SDLC Vulnerabilities Best Practices Development Secure Coding DevOps
Post Rating I Like this!
Default-avatar
Maureen Robinson This article’s perspective is very interesting. We also said there isn’t a “one size fits all” solution for SDLC. We became fans of a SDLC framework that allows us to build a cycle of continuous improvement that will create an ecosystem of repeatable, secure software development: Standards, Education, and Assessment. This framework can ensure faster releases without security concerns.
1343909731
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.