Following the White Rabbit - A Practical Security Blog
Welcome! Let's follow the White Rabbit down the Web Application Security rabbit-hole... This blog is less about awesome h@><0ring and more about practical, real-world web app security measure and counter-measures. If you're looking for a blog to relate to your day-job - this may just be it. As long as you're here, bookmark (Ctrl + D) it, drop it in your reader and leave a comment!

Psychology of "Secure Code"

Happy Monday everyone,


  I've not written anything in a few weeks because I've been absolutely buried in the presentation of this new technology we've launched in the ASC.  I wanted to drop a quick post today to give you a little insight into what I've been reading and something I picked up on from the psychology angle.


  In the past 5+ years in the web app security program space I've tried every approach to getting developers to write more secure code.  I've tried the carrot approach - offering positive reinforcement and rewards to developers as an incentive to write better, more robust and secure code.  I've also tried the stick approach - auditing, punishing and shaming developers who repeatedly write poor code.  Neither approach has actually produced the results I would have liked to see, and that's the topic of today's post.


  Recently I've seen a few good posts out there that reminded me just how and why this is such a difficult battle.  The matter of the OpenCart saga is a perfect demonstration that we in Information Security (Web App Sec) are far removed from our brethren in app dev.  Even though some of us in security (most?) came from the development side of the house - it's a far distant memory and it shows.  Sometimes we completely forget what the motivations of developers are.  They are simple: write code to spec as fast as possible.  If you doubt what I'm saying look at most any project plan that involves application development.  There is usually an insanely short timeline to write the code, less time to actually test the code and security ... well that's typically an after-thought.


  Focusing on the development team, strictly speaking, they don't often get "secure coding training" ... and even worse it's rarely in their requirements.  Code is meant to be functional, fast and only as a tertiary idea is it ever asked to be secure.  Sure, this is different in what's referred to as a "high security environment" - but I bet that the vast majority of code-slingers worry little about security.


  The mentality just isn't there for "secure code" to be second nature to developers.  The reason?  The two vastly different mind-sets ... builders vs. breakers.  Those of us that cut our teeth on app dev then moved on to web app security started as builders but then something clicked in our brains that made us breakers.  Now we understand both sides of it, and then we learn how dangerous insecure code can be, why it works that way, and work tirelessly to prevent it.  On the other hand, builders simply build code to specifications.  Never getting that "breaker" light-bulb to go on makes it nearly impossible to understand why writing secure code is so critical - and more importantly why anyone would ever want to break!


  Now - let's couple that with the approach that security pros take with developers ... and we have a great reason the two don't talk.  Developers write code, insecurely, by nature.  The security guy comes along and tries to be helpful once, twice lacks the patience to really see this through.  Then the claws come out, feelings get hurt and both sides go on the defensive and then the offensive.  Now you've got a typical standoff on the playground, like back in grade school.  Remember that?  Remember when you tried to help someone with building something in the sandbox?  Remember what happened when you tried to tell them that you knew better?  Doesn't matter if you used to be best friends - feelings got hurt and neither of you talked to each other.


  The lesson then ...is this.  Web App Security professionals must learn patience when working with their code-slinging counterparts.  They must learn that it's much easier to point out flaws than it is to actually write code without those flaws.  Security pros must come to the realization that code bundles are increasingly complex and that makes securing them ever-harder without the cooperative relationship with the security group.


  Folks - this may shock you but no one writes "bad" code on purpose.  Sometimes a developer just doesn't know better ... and then, like Mr. Miyagi would say "Patience, Daniel-san" ...have patience, and remember that you too were not so security smart some time back.


Play nice on the playground or everyone loses recess privileges!

Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Rafal "Raf" Los, is a web application security evangelist for the HP Software & Solutions business at HP. Los is responsible for bridging t...
Featured


Follow Us
Guidelines
Follow the White Rabbit on Twitter! Home
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.