tag:blogger.com,1999:blog-13756280.post1258786829927282222..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: Why vulnerable code should be fixed even after WAF mitigationJeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-13756280.post-91528335513977109902009-09-05T19:29:16.943-07:002009-09-05T19:29:16.943-07:00#n+1: At some point, you may be able to stop payin...#n+1: At some point, you may be able to stop paying the hardware+software+latency costs for your WAF.Jeremiah Blatzhttp://www.jeremiahblatz.com/noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-33949714538082119252009-07-14T17:44:47.132-07:002009-07-14T17:44:47.132-07:00You could also use a scenario showing the WAF is j...You could also use a scenario showing the WAF is just an added protection and wouldn't catch all. <br />Plus, there are times when code is just gruesomely erroneous that it affects performance. You could see these from the request headers. All sorts of things happen. Dev should still check these events. Pose as if ur helping them and not fulfilling ur targets.Ryan 2noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-90097492781242932162009-07-09T15:38:53.678-07:002009-07-09T15:38:53.678-07:00I like turtles^H^H^H^H^H^H^HNumber 7.I like turtles^H^H^H^H^H^H^HNumber 7.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-8942998736818088602009-07-09T10:19:22.538-07:002009-07-09T10:19:22.538-07:00The line that I use most is that it boils down to ...The line that I use most is that it boils down to good vulnerability management which is remediation of the root cause not mitigation of the symptoms.<br /><br />Since the root is the code, anytime that we find that we have an issue that the WAF is defending we should apply true root cause analysis and remediation.<br /><br />I talk about the fact that code that is secure today is not secure 5 years down the road as new attack vectors are identified and while you can throw something in front of the code to reduce the threat, the threat does not go away until the code is fixed.<br /><br />I used to say that you can use duct tape to fix anything... but I wouldn't fly in a plane with duct tape on the wings... its that way with vulnerable code... the WAF will fix it.. but I don't want to fly with the code.Unknownhttps://www.blogger.com/profile/10327814953232661602noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-4148445531680819322009-07-09T10:03:43.942-07:002009-07-09T10:03:43.942-07:00What Dre hasn't posted to this yet? Shocking!What Dre hasn't posted to this yet? Shocking!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-91746109837764870142009-07-09T09:00:04.294-07:002009-07-09T09:00:04.294-07:00@Ryan, what can I say... very well said. The decis...@Ryan, what can I say... very well said. The decision to fix or not fix IS risk-based IMHO. What I find many are challenged by is understanding and/or articulating the possible risks to the decision makers. Hence the reason for the list.<br /><br />@Stephan, hmmm... that is an interesting one, but right on the line I think. Why give an informative error to someone who is attacking you in a known vulnerable spot? You probably wouldn't, but maybe not in every case.<br /><br />@Sylvain, some do... some don't. When and why is always their call and we don't really have great visibility into when this happens. We test whatever they give us in whatever state it happens to be. What we have seen is some who specifically black-list regex our tests, which don't fix the issue, which is particularly frustrating.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-66034957507824154202009-07-09T05:38:35.001-07:002009-07-09T05:38:35.001-07:00Any feedback on WH customers running scans with th...Any feedback on WH customers running scans with their defensive line down?<br /><br />From the WAF vendor side of things, I've seen different customers asking us to:<br />- whitelist the scanner<br />- treat the scanner like other users<br />- blacklist the scannerSylvainhttp://www.imperva.com/noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-19113122040699037232009-07-08T23:55:08.851-07:002009-07-08T23:55:08.851-07:00Another reason is usability, is it not?
That WAF...Another reason is usability, is it not? <br /><br />That WAF is not likely to produce a user-friendly response to the problematic input.<br /><br />StephanStephan Wehnerhttp://stephan.sugarmotor.orgnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-75308520945432797512009-07-08T17:25:44.550-07:002009-07-08T17:25:44.550-07:00Hey, as most everyone knows, I am a WAF supporter ...Hey, as most everyone knows, I am a WAF supporter ;) Even so, I have to answer the same types of questions when we talk with prospects. <br /><br />Jeremiah - you mention at the end of your opening paragraph that you looking for "reasonable business justification" for still fixing code however all of your ideas are technical/risk based. I would suggest that users focus in on the contractual language that was in place for the development of the web application code. If there was no language for producing "secure code" then they should tackle that first. SANS has a good template to work from - http://www.sans.org/appseccontract/.<br /><br />Basically - I believe that until developers are hit in the wallet (and start missing out on bonuses) by procuding code that has either functional or security defects in them, things won't change. This goes back to the contract language.<br /><br />Virtual patch management is sort of a hybrid between vulnerability, IDS and firewall rule management. Any network firewall admin will tell you that over time, the rule sets implemented can be quite complex and always stacking on rules ends up impacting performance later. I have worked with many customers with this process and I always advocate leveraging the customer's change management systems to track both virtual patches and the code changes themselves. If/when the code gets fixed, then you can remove a virtual patch from the WAF and "trim the fat" so to speak.<br /><br />Another tactic that I have seen customers use, that I don't necessarily agree with on all fronts, is the whole "need to know" scenario. Their belief is that the developers don't need to know that virtual patching is even taking place. Their management is simply provided with vulnerability details and instructed to fix the code. Bringing up virtual patching as a compensating control only muddies the waters and removes much of the motivations for fixing the code.Ryan Barnetthttps://www.blogger.com/profile/12300602630139148313noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-82200561146481089992009-07-08T14:58:06.737-07:002009-07-08T14:58:06.737-07:00@Jimmy, did happen to find anything reasoning or l...@Jimmy, did happen to find anything reasoning or line of discussion that did serve to convince?Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-70119178861049848122009-07-08T14:55:50.423-07:002009-07-08T14:55:50.423-07:00Awesome.
You don't know how many times I have...Awesome.<br /><br />You don't know how many times I have had to answer the question "Why do I need to address code changes if we have a WAF?"...<br /><br />I have given them most of the same arguments you show in this, to no avail. <br /><br />It is good to see that I am not crazy and that others think this way.Unknownhttps://www.blogger.com/profile/10327814953232661602noreply@blogger.com