tag:blogger.com,1999:blog-13756280.post4682333694907765919..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: Does secure software really matter?Jeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-13756280.post-3629561010603944822008-06-05T07:17:00.000-07:002008-06-05T07:17:00.000-07:00Great postGreat postAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-27666561288912419552008-05-22T03:23:00.000-07:002008-05-22T03:23:00.000-07:00I was also a little disappointed with the title, a...I was also a little disappointed with the title, and the content was less subtly WAF-driven than it could have been.Arshan Dabirsiaghihttps://www.blogger.com/profile/17228728745073712711noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-41701722673398009732008-05-19T09:41:00.000-07:002008-05-19T09:41:00.000-07:00@dre:It's not a 0% or 100% choice for many (and so...@dre:<BR/><BR/>It's not a 0% or 100% choice for many (and software security folks cannot yet dictate to companies what they have to do).<BR/><BR/>In Asia Pacific, most webappsec is at the nascent stage of pentesting; mostly it's being done because somebody somewhere from above is forcing the IT department to pentest the web apps they are hosting (I see this often in government agencies).<BR/><BR/>Say you're the IT department also in charge of security and a pentester finds vulnerabilities. You can't change the code in the foreseeable future because of one or more of the following: (1) the 3rd party app company doesn't exist or doesn't have to support the app; (2) getting budget to modify the source code is a lengthy process; (3) modifying, testing, and certifying the code for deployment is a lengthy process; and/or (4) the web applications are handled by a completely different department (or agency) and there's lots of political friction between your department/agency and theirs.<BR/><BR/>But, as IT and in charge of the network, you can deploy a WAF, hire a consultant that can write patches for some or most of the vulnerabilities, re-test, and you can CYA and keep your job until the app(s) gets fixed.<BR/><BR/>An ideal solution? No.<BR/><BR/>A palatable solution? Barely.<BR/><BR/>Will the web site get hacked eventually? Maybe/maybe not.<BR/><BR/>Will the IT manager keep his job because he got the pentest done and he mitigated the vulnerabilities in the report to the best of his ability? Yes.Stephen Craig Evanshttps://www.blogger.com/profile/09110632913410564073noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-37847126716671169712008-05-19T09:40:00.000-07:002008-05-19T09:40:00.000-07:00@andre, I'm not sure I agree that you could fix th...@andre, I'm not sure I agree that you could fix the inherent code problem in the same time it would take you to configure a WAF. I've been pretty vocal with my criticism of WAFs in the past, but I'm changing my position: I think WAFs can be valuable, especially as a first-response tool, <B>but</B> they must never be used as a replacement for secure code.<BR/><BR/>My biggest fear with WAFs is that they'll get put up as first-response tools, or as defense-in-depth measures, and then the actual underlying problems will never get fixed. "Why should we spend all this money to change the code? We're already secure!"<BR/><BR/>I've written a little more on this subject on <A HREF="http://blogs.msdn.com/bryansul/archive/2008/05/19/web-application-firewalls-in-practice-or-yes-jeremiah-secure-software-does-matter.aspx" REL="nofollow">my blog</A> this morning.Bryan Sullivanhttps://www.blogger.com/profile/15813014674042792805noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-77421492532111957152008-05-17T14:26:00.000-07:002008-05-17T14:26:00.000-07:00I've put some more thought into this, and I think ...I've put some more thought into this, and I think it's socially irresponsible for Jeremiah to recommend WAF's as even a temporary solution to web application vulnerabilities (and even when combined with an automated solution such as Sentinel's integration with F5).<BR/><BR/>When web application exploits become weaponized to the level of crimeware that some of the recent SQLi, file injection, and client-side exploits have lately in recent events -- we are now in a situation where there are those that<BR/>1) have WAF's or a WAF plan<BR/>2) have nothing<BR/><BR/>For those where WAF or other "virtual-patch" is impossible, financially difficult, or other infeasible -- this becomes a serious problem. If they are using COTS web application software, third-party components, validators/encoders out of a framework, or outsourcing custom code from an external dev shop -- this software is now integrated with their data, often customer data which has a trust relationship to the web application provider.<BR/><BR/>In other words, without software assurance there is no way to universally improve our situation. Some will survive, but many will fall. We need to cater to the lowest common denominator; we need to repair the "broken window" problem of the Internet (see: GEEKONOMICS).<BR/><BR/>It's also obvious to many that Jeremiah's approach only helps WhiteHatSec, F5, et al. The purpose of this marketing promotional material (i.e. "Does software security really matter?") thinly-veiled in blog posts by what used to be a reknown web application security expert is really an attempt to get momentum towards WhiteHatSec integrated into F5 as a line-item feature so that WhiteHatSec can be sold and its founders have their pockets lined with cash. The most likely outcome of this situation is that we'll never hear from these experts again, and all the work they've done becomes lost to those who most need it.<BR/><BR/>If you look at the kinds of threats we face in 2008, traditional approaches to combat risk is a zero-sum game. WAF is a traditional approach -- it's a solution looking for a problem.<BR/><BR/>The hard part about Secure SDLC is that it's mostly about adding process and people -- something that traditional IT Security is not used to doing. However, as proven by Visible Ops Security and laid out as the tenants of the New School of Information Secuirty: products fail without people and process behind them. Threats will go after new targets, assets that are not easily guarded and protected.<BR/><BR/>Blocking-mode WAF's only work best when you've discovered that your applications are under attack with specific attacks that a WAF would block. This is typically only detectable with a WAF or APIDS. By the time you could detect the issues and respond to them appropriately, it's more likely that code could have been reviewed and fixed -- and a new Secure SDLC process added to find and fix future (even new) kinds of vulnerabilities.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-71331396084762511532008-05-15T14:16:00.000-07:002008-05-15T14:16:00.000-07:00@Arshan, in the end you may be right, but its hard...@Arshan, in the end you may be right, but its hard to say right now if that's the general view. Very few WAFs deployed (still small) are set-up in block mode. Hopefully I'll help change that but it'll be interesting to see what happens after that. I'll be tracking.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-62217053650081867582008-05-15T13:19:00.000-07:002008-05-15T13:19:00.000-07:00@Andrew, WAFs certainly could be used to "give dev...@Andrew, WAFs certainly could be used to "give developers time to fix the bug". Unfortunately, many companies look at it as an either/or situation, e.g., have a WAF or do review the code (like in PCI).<BR/><BR/>Nobody's going to disagree that a WAF can really help an organization in many ways, it's just that they don't think in the same context we do.Arshan Dabirsiaghihttps://www.blogger.com/profile/17228728745073712711noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-67655310148917836052008-05-15T07:14:00.000-07:002008-05-15T07:14:00.000-07:00@Andrew - hallelujah brother! ;)@Andrew - hallelujah brother! ;)Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-70241148041989361762008-05-15T07:12:00.000-07:002008-05-15T07:12:00.000-07:00@Ron, SANS and WASC are actively working on it act...@Ron, SANS and WASC are actively working on it actually. I wouldn't be surprised if something is offered this year. Presently, not much exists, which I find to be a problem. Hiring managers really have no baseline to go by as they do in other areas.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-55122852422125735452008-05-15T07:10:00.000-07:002008-05-15T07:10:00.000-07:00@kuza55, I thinks its difficult to generalize exac...@kuza55, I thinks its difficult to generalize exactly what solution is best in every instance. That decision will differ between organizations and even individual sites and vulnerabilities for that matter. Personally I try to providing IT Security with as many options as possible and an understanding of the pros/cons (like performance). Eventually the business is going to have to decide what to do (or not do) based upon the information at hand. Whether an organization actually goes and fixes their code or not may not be any of my business.<BR/><BR/>@Miguel Lourenco, I think we're probably 99% on the same page. I also should probably reword the "can't take into consideration" a bit as it technically can, just not all the time with the proportions being unknown. For example, I don't recall reading any web development book or framework documentation from way back when that said to be careful of CSRF. The same can be said of the crossdomain.xml and all the rest of these client-side issues websites are trying to compensate for. <BR/><BR/>That's really what I'm trying to get figure out how to say. You could be doing everything "right", and then later something no one knew of take you by suprise. On an individual scale that might not be so so bad, but on a internet-wide scale it make a monster to tackle. Either way we should we do everything we can to make sure our new code going in is secure as possible. Over time this will pay dividends.<BR/><BR/>Thanks for the references. Going to do some study.<BR/><BR/>@Arshan, LOL. True indeed. :) The problem with the OWASP Top Ten though is that it exists purely because the problems it outlines got so bad that people finally noticed. Its not like a proactive thing. CSRF only recently appeared on in the 2007 version. Now we have to go back and refactor.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-22262005185429667992008-05-15T07:06:00.000-07:002008-05-15T07:06:00.000-07:00Web application firewalls, while being a band-aid ...Web application firewalls, while being a band-aid as you've stated, provide the flexibility to at least buy the developers some time into possibly reviewing, and rewriting their code in order to better suit it to more recent patterns of attack. I also believe that "code security by itself will not deliver us unto to the pearly gates of Web security that many people wish for" to be a spot-on statement. There will never be 100% security in any application for various reasons, and I've said it many times before, but it's truly all about layering your security in order to prevent as many issues as possible while remaining realistic enough to realize that it would be virtually impossible to defend oneself (or one's application) from all forms of attacks both past and future.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-49183673347119315982008-05-15T06:58:00.000-07:002008-05-15T06:58:00.000-07:00Jeremiah - We need a Web Application Security Prof...Jeremiah - We need a Web Application Security Professional Certification exam. Do you foresee such a cert becoming available ? I'm a web-developer looking to get into the webappsec space.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-50756611188536010872008-05-15T03:34:00.000-07:002008-05-15T03:34:00.000-07:00Developers can stop the OWASP Top 10 - if they do ...Developers can stop the OWASP Top 10 - if they do that, they're surely outrunning their friend (maybe not the bear).Arshan Dabirsiaghihttps://www.blogger.com/profile/17228728745073712711noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-61418120568596857762008-05-15T02:44:00.000-07:002008-05-15T02:44:00.000-07:00Jeremiah,SDLC process can and do take into account...Jeremiah,<BR/><BR/>SDLC process can and do take into account unknown attack techniques. If you design your application securely, and taking into account Saltzer and Schroeder's design principles, you can greatly limit or avoid the damage that unknown attack types might pose to your application. Secure coding best practices, even if implemented perfectly, can only account for attack techniques we're aware of. However we should be aiming for correct and secure code, not just secure-at-the-moment code. Sure, we didn't know heap overflows were exploitable, but we knew that having an application crash because its heap got corrupted was caused by incorrect, unreliable, code.<BR/><BR/>That said, I do agree with you that we won't have perfect code any time soon but we should continue to strive for better software and for technologies that are fundamentally more secure. A lot of the security problems we're stuck with are caused by the insecure design of the underlying technologies that applications depend on.<BR/><BR/>On a related note, check out Dan Bernstein's "Invulnerable software" presentation and related paper.Miguel Lourencohttps://www.blogger.com/profile/10076389080905298351noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-84046058877143533962008-05-15T02:34:00.000-07:002008-05-15T02:34:00.000-07:00I think at some point you have to go back to the c...I think at some point you have to go back to the code no matter what; e.g. CSRF, you *could* use a WAF to patch it (e.g. OWASP's CSRF guard), but at some point the performance hit generated by it will become unworkable, or more expensive to run the WAFs than to get some devs to fix the code, so if you can fix the code (i.e. you have developers who aren't already buried under piles of vulnerabilities) then IMO it is almost always better to fix the code than to write a band-aid because then you have a dependency on the band-aid, rather than safe code.<BR/><BR/>Having said that, I think your WAF solution is great since you can get things done quickly and for apps whose code you cannot change, esp for sysadmins who want to secure their websites but who can't force developers to do anything, so I'm not saying it's dead, I just think that fixing the code is still the best option, even if your devs could be developing more software that is useful to the business instead of fixing issues, unless they get slapped about in a code/site review they'll keep writing bad code, which leaves you with a bigger problem.kuza55https://www.blogger.com/profile/03932544559060480887noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-41017186848380772342008-05-15T00:09:00.000-07:002008-05-15T00:09:00.000-07:00@ Jeremiah:Sorry to chime in here so late.Can't IT...@ Jeremiah:<BR/><BR/>Sorry to chime in here so late.<BR/><BR/>Can't IT Security hire/retain an external organization to help fix the vulnerable code?<BR/><BR/>While I was at eBay (and while you were at Yahoo), I specifically recall the moment of realization that we couldn't fix our vulnerable code. We were looking for options. The first option we chose was to hire a third-party security review and consulting company to help us figure out what to do. They were extremely helpful.<BR/><BR/>This was around 2001 (when XSS was just hitting on the scene and SQLi had been around for 3 years) but today there are many more third-party options available. Today, there are options such as "Hackers for Charity"<BR/><BR/><A HREF="http://ihackcharities.org" REL="nofollow">http://ihackcharities.org</A><BR/><BR/>which will provide these kinds of services to those in need -- potentially for free.<BR/><BR/><I>software security proves to be one of those things that’s difficult to measure</I><BR/><BR/>Microsoft and others appear to be doing fine with measurements and showing improvement with the Microsoft SDL and the Trustworthy Computing Initiative (Bill Gates' Memo). They do not stand alone.<BR/><BR/>What is it about software security that makes it so difficult to measure? Find a bug; fix a bug. This doesn't have to be complex. Developers and quality engineers have been doing this for 30+ years.<BR/><BR/>If the application is vulnerable and the fix must come in the code, then why bother messing around with web application firewalls or other misplaced options? Why not solve the problem at the source (and end this comment on a happy note with a pun)?drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-81951792958109246552008-05-14T23:04:00.000-07:002008-05-14T23:04:00.000-07:00Darn, there's some context that got lost in the en...Darn, there's some context that got lost in the ending, which I clearly need to rework it if that question arises. <BR/><BR/>What the list is trying to articulate are the options available to IT Security between the point in time when a vulnerability is discovered and the organization fixes the code. In most instances IT Security themselves can't fix the code so that option is absent for them.<BR/><BR/>This make more sense?Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-25091883321889636492008-05-14T22:48:00.000-07:002008-05-14T22:48:00.000-07:00Jeremiah, that was a long blog post and maybe I mi...Jeremiah, that was a long blog post and maybe I missed something in all those words, but your list at the end there seems to leave out the thing most people think of when they hear about a vulnerability in their code.<BR/><BR/>0. Fix the vulnerable code.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-63887226607261583042008-05-14T21:29:00.000-07:002008-05-14T21:29:00.000-07:00lol. i've trolled enough todaylol. i've trolled enough todaydrehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.com