An effective way to treat Web 2.0 vulnerabilities
I’m personally a huge fan of the Matasano blog, and have a lot of respect for their group. I took a peek over at their blog today and noticed an article by Dave Goldsmith that deals with “Vulnerability Reporting in a Web 2.0 World Continued“.
In this article, Dave recounts personal experiences dealing with a PITA vendor that treated his vulnerability report as if it was a feature request. That sounds crazy right? Have a look at Dave’s original communication chain with the vendor:
Step #1: I send in a vulnerability report. I explain the vulnerability in a concise email and include repro steps.
They reply:
Thanks for the tip, David. It’s been noted.
I reply:
Can you give me some guidance on your response guidelines to security vulnerabilities? Is there a timeframe that you try and have vulnerabilities fixed by?
They reply:
Hi David,We’re always looking for new ideas and fixes to roll out in future updates but as as rule we don’t comment on possibilities or timeframes.
I reply:
How will I know when this vulnerability is fixed?
They reply:
Actually, they don’t reply at all.
Nice. I’ve been there before myself with a few vendors. This creates an interesting conundrum for the researcher.
Your ethics should probably say (assuming you’re ethical):
- I’d hate to blast out a vulnerability that will be exploited
- I’d hate to allow a vulnerability that I know about to be exploited
It’s a difficult situation to be in. Dave actually noted a blog post by the company that his original advisory targeted, 37signals, where they discuss how to say no to a feature request. From the 37signals blog post:
-
- The Hard No. If the feature is not aligned with the direction of the product, just be direct and say so.
- The Soft No. If it is something you might pursue in the future, but you don’t want to commit, say: thank you for the idea, we will consider it for a future version.
Interesting. So Dave got a soft no and a hard no (in the form of ignoring him) from the 37signals guys.
This is a problem. This is NOT an acceptable way of handling a vulnerability. I got to thinking the other day of how vulnerabilities should really be handled by a company. The problem of course is I’m saying how the companies should handle them, and I have no authority at any of these places, save people actually valuing my ideas. Personally, I’ve done some development in the past, and there was the concept of defects. Your bonus would depend on how many defects were in your application at delivery time. These were feature-based defects, but shouldn’t vulnerabilities be considered defects as well?
Many companies out their count security as one of their business objectives, well, time to step up. Count vulnerabilities as defects. Programmers understand that for sure. Of course, you can’t leave it all on them, because secure code development is not exactly taught in school (even today unfortunately), so go out and get them some training. Give them some lead in time to understand security vulnerabilities. Create a Secure SDLC process for your company that guides direction.
You know what? Be progressive. Don’t just ding your developers for defects (security vulnerabilities), reward them handsomely for extended time periods without flaws, security assessments that point out no flaws, etc.
Just my thoughts, but something has to change.
[Source: zdnet]
Post a Comment