OWASP AppSec USA - Day 1 - Recap

Conference Diary: OWASP AppSec USA - Irvine, CA (Day 1)

 

Hi everyone, as day 2 of the OWASP AppSec USA in Irvine is about to kick off I thought I should quickly summarize what happened yesterday for the benefit of those that missed the conference.  For the record, if you're able to make it to an OWASP conference, you should go if you work in Web Application Security.  These conferences offer very real, grounded discussions in technology and methodologies - what's more though... the hallway discussions and dinner conversations are priceless.

 

The conference started with Jeff Williams' keynote on Rugged Software, and then went off with a bang when Chenxi Wang gave her keynote.  From discussion in the hallway afterwards - her concepts were half brilliance, half madness and certainly made some people think.  The concepts that I took away were as follows, in order:

  • developers aren't writing any more secure code today than 5+ years ago [agreed]
  • educating and "forcing" developers to learn secure coding isn't working (and won't work) [agreed]
  • security needs to become invisible ...[agreed x10]
  • --> web application security should be pushed into the frameworks and away from the edge developers
  • --> web application security should be written into the compilers (and toolkits) to prevent obvious errors
  • ...and then things went a little sideways... and poor Jim Manico almost lost it
  • in order for security to suceed we must remove developers from the equation [...huh, OK, maybe...]
  • security must provide hands-off, automatic virtual patching on the fly for web applications [ ...what-now?]

 

I know analysts dance the line between prognostication and guess-work ...but to really want developers completely out of the equation and some method for automatically patching code for security bugs after it's all developed, tested and ready to go... that's a stretch even for my idealistic side.  Sure, that may work on basic Cross-Site Scripting (XSS) or SQL Injection types of issues ...but what about anything more complex?  What about the fact that any such magical system would have to understand your source code and compensate for your lack of security controls ...without breaking your code's functionality!?  We talked this over in a hallway conversation for the rest of the afternoon and have come to realize that the complexity behind solving this issue in such a way borders on mis-understanding just how [infinitely?] complex code can be.  We already know that each developer puts their own flavor on code; each group writes their own "extensions" into existing methods and frameworks - so how can you possibly compensate and patch in compensating "security patches"?

 

I admit, as much as I preach that web application security is NOT an operational issue, if technology reaches this level of sophistication... I will be wrong.  Of course, by then I probably won't care because I will be long-gone and my grand-children will be driving their hover-cars around on the planet Mars.

 

So one has to wonder, as a realist, is this utter madness or brilliant insight into something we can't grasp yet?

 

Opinions?

Comments
(anon) | ‎09-10-2010 10:57 AM

Wow, that is certainly revolutionary thinking. Developers can never be removed from the equation! well, if you can write software without developers, only then you can take developers out of the equation.

(anon) | ‎09-10-2010 01:43 PM

Raf,

50 years ago if you would had asked people if you would be able to video chat with someone in china with almost no delay... they would had said " I will be long-gone and my grand-children will be driving their hover-cars around on the planet Mars."

 

Same goes with everyone carrying a phone, and then the internet, etc....

 

Its hard to envision it.... but in order to envision something, someone needs to create the vision.

 

 

(anon) | ‎09-10-2010 05:22 PM
Interesting idea and I'd agree that's frameworks have a part to play. But afraid I don't buy the idea that developers can or should be removed from the loop. Ultimately there are classes of security issues (eg, business logic flaws application authorization issues) that I can't see frameworks solving completely, and these flaws can be some of the most serious for an applications security. I'd say that what needs to happen is that security needs to become part of developers day to day job, like writing perfomant code, or writing robust code. To draw an analogy across to IT ops, most Microsoft admins now accept that a degree of security patching is part of the role, due to all the problems and headaches that worms and virii have caused. I think that same type of acceptance is needed in the web app dev world for a degree of secure coding to be a necessary part of the job. Of course the hard part is how to actually achieve all that :smileyhappy:
(anon) | ‎09-10-2010 07:45 PM

Sherif... you just came up with the solution... take developers out of the equation!

(anon) | ‎09-11-2010 01:58 PM
RAF, I'm 100% biased. I deliver secure coding training services for a living. I theorize that Dr. Wang's comments regarding the ineffectiveness of secure coding training are influenced by tool vendors inability to monetize on such activities at scale. I almost fell out of my chair when she said that! There is clearly a reduction in AppSec vulnerabilities when more than 1/2 of a dev team has undergone such training - especially ESAPI centric (ie: very code example centric) training. Dr. Wang's comments about compilers and frameworks were right on. Good to see you Raf, keep fighting the good fight.
(anon) | ‎09-13-2010 09:31 AM

There probably is a need to redefine what a developer is.  As frameworks become more and more sophisticated and more and more activities are handled by canned software, many of the activities done by people currently called developers will be done by someone called a "configurator" or some such thing.  Those will be the developers who will be removed from the equation and whose work should not be allowed to alter the security posture of the application they are working on.

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