Monday, May 14, 2007

Web Application Security for CIOs

Last week an article appeared in CIO, An Introduction to the Murky Science of Web Application Security, where none other than Simson Garfinkel interviewed yours truly. Simson is a notable name in the information security arena, with a reputation for being VERY direct with vendors, authored the first book I ever read on web security, and most importantly really knows his technology. Oh, did I mention that he admits he’s never been of fan penetration testing? Going in I knew I had my work cut out for me, but was excited by our first meeting and didn’t know quite what to expect.

What you might find interesting about the article are the descriptions of the types of vulnerabilities we routinely identify and the odd situations we encounter when doing so. For example when vulnerabilities spontaneously open and close from scan to scan or when they reopen months later for no apparent reason. Overall Simson did a really good job highlighting the more important aspects of the field in an easy to understand way that CIOs can digest. Then this quote really made my day:

"I’ve never been a big fan of penetration testing, but the two hours that I spent talking with Grossman convinced me that it’s a necessary part of today’s e-commerce websites. Yes, it would be nice to eliminate these well-known bugs with better coding practices. But we live in the real world. It’s better to look for the bugs and fix them than to simply cross your fingers and hope that they aren’t there."


9 comments:

Anonymous said...

Thanks! Although the article appeared in CSO Magazine, which is CIO's sister publication.

Anonymous said...

odd, just looks like a long advertisement disguised as a story.

Jeremiah Grossman said...

I guess if by advertisement you mean describing to a subject matter expert what it is you do for a living and why its important. Sure.

alik levin said...

penetration testing is cool, but rather trying to discover these bugs when the application is completed i think it is better to anticipate the bugs throughout the whole dev process and most important when conducting threat modeling in the beginning

here is my view on the above:

Security Engineering process

http://blogs.msdn.com/alikl/archive/2007/05/07/security-engineering-big-rocks.aspx

Threat Modeling
http://blogs.msdn.com/alikl/archive/2007/04/27/threat-modeling-big-chunks.aspx

Jeremiah Grossman said...

alik levin, thanks for the comment and generally I agree with the process when building any new web applications. However, please consider the following:

1) Not all vulnerabilities in production first existed in development (forced browser, config issues, hot fixes, etc.) and its highly unlikely for ANY developer to write bug free code. Best test production before the bad buys do because they will no matter what.

2) The VAST majority of web applications in existence have already been built and deployed without the process you described. Its unlikely that they'll be re-coded from scratch within the next 10 years using this process. More likely we'll get more code and additional complexity. One benefit of vulnerability assessment is we can measure the security of existing websites and fix what issues we can, however we can.

To be clear though, my advocacy of vulnerability assessment does not conflict or replace a solid SDLC.

alik levin said...

agree. Sorry i sounded like i think these approaches are in confict. They are all add to the whole process

alikl

Jeremiah Grossman said...

I guess thats one thing that makes getting a handle on webappsec so hard... its a big friggin complex process. :)

alik levin said...

lemme disagree here.
I do not think it must be freaking complex

tak a look at this please, tell me what you think, is it that complex?

http://blogs.msdn.com/alikl/archive/2007/05/07/security-engineering-big-rocks.aspx

Jeremiah Grossman said...

At a high level we can make just about anything appear simple. Its only when we get into the nitty gritty details of say SDLC, VA, Business Process, Compliance, Best Practices, Ajax, do things become somewhat complicated. :)