Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Vendor notification |
|---|---|
| Date: | Thu, 31 Mar 2005 07:07:34 -0800 |
Susan
Barrie Dempster wrote:
Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: <snip>
I'm talking about informing about 'bad stuff in the wild' to help the vendor know that we are all protected for this stuff.
<snip>
If every such incident was reported to the vendor they would be flooded with absolute garbage all day. How many times do we see "is this a new virus?" and other such questions where the poster hasn't done any basic research or verification at all.
I think it's important to ask "do you see this too?" on the appropriate forum, then when you have some verification and discussion you can pass the info on to the vendor if it seems prudent. However most vendors are reading the appropriate forums for thier products and become aware very quickly of any possible issues. When it comes to discussing and disclosing any new security problems, the most important people in the equation are the *users* not the vendors. I agree though that in many cases you would want direct vendor notification, but unless it's something they can fix directly - ie.. patchable - then let the users know first, so that they can setup IDS/IPS rules, configure firewalls or monitor for traffic patterns.
Your example was an exploit existing for an already determined vulnerability, in this case I don't think the vendor needs to care about it at all, the presence or lack of an exploit should have no bearing on their time to patch release. If it's a security vulnerability then the patch should be released as soon as reasonably possible. If the patch is already released and the exploit appears, then the vendor doesn't have to know or care, the user however might want to monitor this for their own research/defense.
Basically this boils down to.... Find it, discuss it with peers, if the vendor can fix it notify them.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Vendor notification, Barrie Dempster |
|---|---|
| Next by Date: | Re: Vendor notification, Barrie Dempster |
| Previous by Thread: | Re: Vendor notification, Barrie Dempster |
| Next by Thread: | Re: Vendor notification, Barrie Dempster |
| Indexes: | [Date] [Thread] [Top] [All Lists] |