Comments on: Web App Sec Predictions for 2010 http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/ mostly useless crap from me Mon, 23 Jan 2012 12:46:05 +0000 hourly 1 http://wordpress.org/?v=3.3 By: vanderaj http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/comment-page-1/#comment-21488 vanderaj Fri, 05 Feb 2010 02:24:17 +0000 http://www.greebo.net/?p=596#comment-21488 I do both penetration tests and code reviews. Penetration tests find a tiny fraction of the items a code review performed with a live test application to eliminate false positives will find. Code reviews find things that cannot be easily discovered by penetration testing alone. Penetration testing with zero knowledge might give someone a woody, but it's really a huge waste of money. Code reviews are not that much more expensive than penetration testing, and if done right, they can save hundreds if not thousands of days of wasted developer time in resolving issues in their code. Code reviews are very cost effective. In my 12+ year experience, once given penetration test findings, folks fix just the things in the report, and do not search for any other similar issues within their code. So we do a do-over a bit later, and surprise, they still have XSS or SQL injection in different places in old, modified and new code. If you're in the pen testing business, great. If you're in the business of being a trusted advisor to your clients, then this is a FAIL. Penetration tests happen far too late in the development process to prevent these issues going live, and if it's your only control, it's not enough. Often I test older applications, and it's like dynamiting a lake full of fish. We need the full suite - security architecture, developer training, code buddies, code reviews, penetration tests, and WAFs. No one thing is the silver bullet. In my experience, firms that have an SDLC, do security architecture, get their architects and devs trained up, peer review themselves for coding flaws, write abuse cases in their unit test, and perform code reviews have the best outcomes in penetration tests. Those that just do penetration tests are unfortunately doomed to repeat their mistakes as there is no loop to train the developers not to make those mistakes again, no policies or peer reviews to prevent those issues creeping in again, and no tests written to ensure that the issue doesn't get re-introduced. I do both penetration tests and code reviews. Penetration tests find a tiny fraction of the items a code review performed with a live test application to eliminate false positives will find. Code reviews find things that cannot be easily discovered by penetration testing alone. Penetration testing with zero knowledge might give someone a woody, but it’s really a huge waste of money.

Code reviews are not that much more expensive than penetration testing, and if done right, they can save hundreds if not thousands of days of wasted developer time in resolving issues in their code. Code reviews are very cost effective.

In my 12+ year experience, once given penetration test findings, folks fix just the things in the report, and do not search for any other similar issues within their code. So we do a do-over a bit later, and surprise, they still have XSS or SQL injection in different places in old, modified and new code. If you’re in the pen testing business, great. If you’re in the business of being a trusted advisor to your clients, then this is a FAIL.

Penetration tests happen far too late in the development process to prevent these issues going live, and if it’s your only control, it’s not enough. Often I test older applications, and it’s like dynamiting a lake full of fish.

We need the full suite – security architecture, developer training, code buddies, code reviews, penetration tests, and WAFs. No one thing is the silver bullet. In my experience, firms that have an SDLC, do security architecture, get their architects and devs trained up, peer review themselves for coding flaws, write abuse cases in their unit test, and perform code reviews have the best outcomes in penetration tests. Those that just do penetration tests are unfortunately doomed to repeat their mistakes as there is no loop to train the developers not to make those mistakes again, no policies or peer reviews to prevent those issues creeping in again, and no tests written to ensure that the issue doesn’t get re-introduced.

]]> By: Nitchimon http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/comment-page-1/#comment-21485 Nitchimon Thu, 04 Feb 2010 15:04:42 +0000 http://www.greebo.net/?p=596#comment-21485 Way off course on Penetration Testing. The budgets of many organizations can not afford code reviews, change and incorporate security into an SDLC, Secure development and various other "new" techniques. We've seen that code review as well as training still leaves XSS and Injection problems, because its just a fact. Developers, reviewers get lazy and revert back to old bad habits. Face it. You need to balance all aspects of these things to effectively stop the "known" attacks of today. You also need to get people to understand that this is NOT a singularity but an ongoing, ever changing environment that produces new vulnerabilities never dreamed of at the time of code hashing. Just like someone stating that a WAF is the correct and only way to do this. Dead on wrong. Its a concerted effort across the board, but you will never see this implemented UNTIL you start changing the mindset of Managers, program Mgt included. They lump "security" as part of Risk Management and as we know this is wrong. Risk Assessments are usually done at the beginning of an application prior to any code being written. The only way to be sure you capture every aspect is to implement all of it. The bottom line is that you do an injustice to the Application Security environment stating that "PTs are useless". Get your mind out of the code and LOOK at what needs to be accomplished and you will realize, you are missing that its no one solution will fix the problem. Way off course on Penetration Testing. The budgets of many organizations can not afford code reviews, change and incorporate security into an SDLC, Secure development and various other “new” techniques. We’ve seen that code review as well as training still leaves XSS and Injection problems, because its just a fact. Developers, reviewers get lazy and revert back to old bad habits. Face it. You need to balance all aspects of these things to effectively stop the “known” attacks of today. You also need to get people to understand that this is NOT a singularity but an ongoing, ever changing environment that produces new vulnerabilities never dreamed of at the time of code hashing.
Just like someone stating that a WAF is the correct and only way to do this. Dead on wrong. Its a concerted effort across the board, but you will never see this implemented UNTIL you start changing the mindset of Managers, program Mgt included.
They lump “security” as part of Risk Management and as we know this is wrong. Risk Assessments are usually done at the beginning of an application prior to any code being written.
The only way to be sure you capture every aspect is to implement all of it. The bottom line is that you do an injustice to the Application Security environment stating that “PTs are useless”.
Get your mind out of the code and LOOK at what needs to be accomplished and you will realize, you are missing that its no one solution will fix the problem.

]]> By: An Information Security Place » An Information Security Place Podcast – Episode 29 http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/comment-page-1/#comment-21247 An Information Security Place » An Information Security Place Podcast – Episode 29 Wed, 23 Dec 2009 14:49:49 +0000 http://www.greebo.net/?p=596#comment-21247 [...] Link 1 / Link 2 / Link 3 [...] [...] Link 1 / Link 2 / Link 3 [...]

]]> By: An Information Security Place Podcast » Blog Archive » An Information Security Place Podcast – Episode 29 http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/comment-page-1/#comment-21246 An Information Security Place Podcast » Blog Archive » An Information Security Place Podcast – Episode 29 Wed, 23 Dec 2009 14:49:06 +0000 http://www.greebo.net/?p=596#comment-21246 [...] Link 1 / Link 2 / Link 3 [...] [...] Link 1 / Link 2 / Link 3 [...]

]]> By: Jim’s Bloggyness » Post Topic » An Information Security Place Podcast – Episode #29 http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/comment-page-1/#comment-21244 Jim’s Bloggyness » Post Topic » An Information Security Place Podcast – Episode #29 Wed, 23 Dec 2009 05:27:34 +0000 http://www.greebo.net/?p=596#comment-21244 [...] Link 1 / Link 2 / Link 3 [...] [...] Link 1 / Link 2 / Link 3 [...]

]]> By: Big Red http://www.greebo.net/2009/12/18/web-app-sec-predictions-for-2010/comment-page-1/#comment-21236 Big Red Sun, 20 Dec 2009 23:51:10 +0000 http://www.greebo.net/?p=596#comment-21236 Could not agree with you more on penetration tests. We also need to think about enumerating goodness, not badness, and stop a reliance on user education. People are like electricity; they will take the path of least resistance. Could not agree with you more on penetration tests. We also need to think about enumerating goodness, not badness, and stop a reliance on user education.

People are like electricity; they will take the path of least resistance.

]]>