Software Security is a Business Problem

Thursday, June 14, 2012

Rafal Los


Notes from a developer conference on DevOps, AppSec and Barney Fife

Recently I spent the day at a developer conference.

The conference, a 1-day event run by one of my company's customers, had a NASA keynote and fabulous tracks running 5-wide throughout most of the day with one other external speaker... the rest were internal.  

Approximately 1,200 or so developers of various types and varieties working on the company's (let's call them ACME Corp.) software for internal use, as well as for their customers took time out of their schedules to attend and learn.  I was also lucky enough to be asked to speak there on the topic of software security - so I picked DevOps as a vantage point for security.  

From my understanding of their organization, they've made several attempts at incorporating software security principles into their development culture and have largely come up short each time.  Honestly, I was banking on the fact that I would be the only DevOps talk that was from a 3rd party with a slight emphasis on security to get them into the track.

The experience solidified my belief that the Information Security hasn't figured out how to actually approach the problem of insecure code.

This isn't a technology discussion, because almost all the tools developers could ever dream of are right there ready to use. This isn't a risk discussion either, because most of them aren't risk-management experts. This discussion is about what my friend Terry, one of the folks responsible for having me there, calls "The Barney Fife problem".

You all know Barney Fife right?  He's the bumbling sheriff's deputy from Mayberry on the Andy Griffith Show.  Some of you in the more junior ranks will want to read about him on this Wikipedia page first.

Barney Fife was a law man.  Barney enforced the law as he understood it ... the problem was Barney's situational awareness was..."lacking" even in the best of times.  Barney often didn't really have any idea what was going on, he would just try and enforce the law as he understood it but couldn't really tell if he was doing it right or not - or whether those he was working with were actually the bad guys or the good guys.  Barney was ... your average AppSec guy at companies like ACME Corp..

Terry puts it this way - "[Application] Security people show up, dictate requirements and throw around a lot of strong words, often completely missing the point that the application is part of something bigger or largely missing the business perspective."  Well put.

Terry and I sat and talked about how ham-fisted security professionals would try and dictate development principles and design directives all while knowing absolutely nothing about the actual product or business goal.  They understood nothing about the customer use-cases, support challenges, legacy data and other constraints - all they cared about is security.  

So... when the security guy parachuted in briefly, made demands and ordered the development team around everyone nodded and uh-huh'd, but the minute that person left they all chuckled and went on with developing software completely forgetting that silly-sounding security guy.  Sound familiar?

My talk focused on collaboration, process streamlining, and automation - all DevOps principles - rather than security talk.  I didn't try and tell them why they should write secure code, or that the big, bad hackers will get their data - they didn't really care.

These developers, like many others I've had the pleasure of meeting, wanted to know how to do their job better.  DevOps is something they're testing and trying to see whether it will improve their efficiency, delivery times, and quality - but wait, where's security?

Security is still largely seen as the "not my problem" problem.  It's not that developers have singled out security as something they want to ignore - it's that they've got too many other things to worry about like whether the interface they're releasing today will work with the 2,000+ customers that are feeding them data, even some of the weird, legacy stuff a handful of customers are doing.  That's more important - "does it work?" takes precedence every time.

I won't keep belaboring the point, it should be clear by now why security is still so, so far behind in the priorities of developer groups across the globe... In the grand scheme of things, because it's presented as something separate and aside from their goal of quality software that works - it doesn't get another thought.

I did attend some of the other talks, most of which were company-specific and way, way over my head, and behold - no one else even mentioned the word security.  There was a Hadoop talk, a MongoDB talk, talks on implementing scalable interfaces, and tons of other cool stuff... but no other peep on security.  Fancy that.

Oh, and  I took a poll in the room.  This was a room filled with all developers except for a security incident response manager, and a self-described security-minded developer lead.  Exactly 0% of the group felt there was a need to have a "SecDevOps" or "DevOpsSec" or "Rugged DevOps" or anything else confusing the point of DevOps and specifically calling out security.  I realize this is a small sample, a group of developers at a single company isn't representative of the industry at large ...or is it?

Lesson learned: Don't be the Barney Fife of your organization when it comes to driving software security.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Information Security
Enterprise Security Application Security Development Secure Coding Software Security Assurance Information Security Infosec DevOps
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.