Following the Wh1t3 Rabbit - Practical Enterprise Security

Enterprise Security organizations often find themselves caught between the ever-changing needs of the agile business, and the ever-present, ever-evolving threats to that business. At the same time – all too often we security professionals get caught up in “shiny object syndrome” which leads us to spend poorly, allocate resources unwisely, and generally de-couple from the organization we’re chartered to defend. Knowing how to defend begins with knowing what you’ll be defending, why it is worth defending, and who you’ll be defending from… and therein lies the trick. This blog takes the issue of enterprise security head-on, challenging outdated thinking and bringing a pragmatic, business-aligned, beyond the tools perspective … so follow the Wh1t3 Rabbit and remember that tools alone don’t solve problems, strategic thinkers are the key.

Rafal (Principal, Strategic Security Services)

Displaying articles for: May 2010

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!

Source: Boston Talk

Hi everyone - there are a bunch of you who have been asking if the Source: Boston talk titled "Into the Rabbit Hole..." Matt Wood (from Director HP Web Security Research) and I gave was recorded.  Well, thanks to 'dre for pointing out that the video is up and viewable on SecurityTube!


Here's the embedded video...


 

The Lesser of Two Weevils

Remember that scene in "Master & Commander" where the captain had to let one of his men be swallowed by the sea in order to save the rest of the ship?  That scene devolved into a joke about the lesser of two evils ... so as I looked through that title today I thought about the idea of the lesser of two evils.


From the WebAppSec perspective, there are two primary evils - developers and hackers.  If you've ever thought about this problem from this perspective - read through this and let me (and the readers here) know what you think ...



  • Developers - Developers are a necessary evil.  I don't mean to call developers evil of course... but a careless or untrained developer can wreak havok with just a few strikes of the keyboard.  Web Applications are getting so much attention in the media lately because people are breaking into them and pillaging at an unprecedented rate.  The reason?  Developers.  Developers write the code and if they're not properly trained and given the tools, processes and knowledge to successfully write rugged, bullet-proof code ... it doesn't matter how many shiny devices you put on the wife in front of them...ahem.  Developers are focused on writing code to specifications (functional and performance, usually) with a general disregard for privacy and security ...and this can be dangerous!

  • Hackers - Hackers are the embodiment of evil.  They look for weakness in our systems (especially web applications) and exploit them for their monetary pleasure.  They make money and get rich off of your company's misfortune.  They aim to scheme, scam and break - all without regard for your company's privacy or liability to the user-base.  Hackers deconstruct your web applications, find tiny holes to exploit and steal what they can - often without even being detected.


So then, I challenge you to think about it and answer ...which is worse?  The uneducated developer or the malicious hacker?  ...now explain why?


I'd love to hear your responses ... feel free to post them in the comments/feedback section!

Search
About the Author(s)
Follow Us
Twitter Stream


Community Announcements
HP Blog

Technical Support Services Blog

Labels
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