Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

12/22/2009
08:06 AM
Gadi Evron
Gadi Evron
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Security PR: How To Disclose A Vulnerability

When your team discovers a new security vulnerability in a third-party product, there are ways to handle it correctly to achieve maximum visibility.

When your team discovers a new security vulnerability in a third-party product, there are ways to handle it correctly to achieve maximum visibility.This blog is part of a series of posts on security PR. The previous one was Security PR: How To Talk To Reporters.

The most important thing to remember about vulnerability disclosure -- regardless of if you believe this personally or not -- is that while disclosing a vulnerability can be a win for your organization, it will hurt others, plain and simple. The justification to release it is that it will hurt people more if you don't disclose it.

Indeed, if not for your efforts, this vulnerability would not have been fixed, and may have been exploited by evil attackers without anyone knowing or used in a mass-exploitation by a worm a year from now. But that does not change the fact that the vendor whose product you found a vulnerability will suffer in having to fix it and in the support costs and from a PR perspective having to respond to criticism.

Then millions of potential users may get compromised because of your disclosure, when criminals use the information to exploit the software now, rather than a year from now.

These are issues you should be ready to address in a statement if asked, and are also why you should insist that your researchers disclose the vulnerability responsibly, with the vendor (as long as the vendor also responds responsibly), rather than try to dissuade them from it so that the timetable can be shortened.

Make sure you have the goods Ask your researchers to examine their work, and to bring in an extra pair of eyes to make sure the vulnerability it real (i.e. exploitable), and that on the flip-side, it is not even more serious than they think (such as a remote exploit versus a denial of service).

Write three press releases One should be a simple email you can send to reporters you work with to interest them in the discovery. The second is an actual press release that you can reference everywhere, and the third a miniature technical paper on the issue.

Send the email with a reference the actual press release (a cover letter, if you like) to reporters you work with often.

The technical paper can be referenced in the press release, on your Web site, and on other forums where you publish it. It will be referenced by others who will inevitably write on the topic, as any new released vulnerability is interesting to people inside the industry much more than it is to reporters.

Contact reporters The first question to ask yourself is how urgent is this release. If the vulnerability was discovered by your team due to rigorous research and is not likely that someone else will publish it in the next few months, take your time to do things right.

See if you can locate a journalist who will be interested in the disclosure as a scoop. Preferably, a reporter from a large, popular publication. But there is nothing wrong with working with a smaller, successful tech publication. When one such publication writes on something newsworthy, the rest are likely to pick it up.

Once a large newspaper writes on the subject, others will pick it up and your work is almost done.

If the release is more urgent, work from the bottom up. Contact journalists at tech publications, provide them with the information, and let them do their jobs.

Industry and community releases More important than contacting the press is informing the community.

If you have the time, have your technical team submit a talk on the vulnerability to a large security conference such as Black Hat, Defcon and CCC. These conferences have teams of reporters just waiting for juicy new releases, and may even contact you before the conference as the rumor-mill generates noise.

If the vulnerability is not that significant or time is short, ask for the help of your technical team, and write a short, yet detailed, technical email to be sent to relevant mailing lists (such as Bugtraq and Full-Disclosure). While email formats for such disclosures can be found online, they vary considerably.

It is important that you include: 1. A layman's explanation of the vulnerability. 2. A layman's explanation of what the effects of the vulnerability are. 3. What products are affected. 4. Disclosure history (such as when you spoke with the vendor, and on what). 5. Technical details. 6. Exploit - you should not include the actual exploit code for the vulnerability, others will likely write about it soon, but for purely ethical reasons, it shouldn't be you. However, you should definitely include technical details of what it is. There is little more annoying to peers than a report which is devoid of details. 7. URL to full technical analysis on your website (see note about blogs). 8. URL to the press release.

If you can coordinate this release with the affected vendor, that would be great. But don't be afraid to release on your own. Inform the vendor ahead of time how long you are willing to wait before you release the vulnerability, but do try and be understanding and collaborative of their internal issues. The rule of thumb is to be understanding as long as they are being serious about it, rather than just stonewalling.

This industry release will get more relevant attention than any press release, and will be syndicated or referenced on multiple blogs, depending on how critical the vulnerability is.

Further, reporters who follow these mailing lists and groups will contact you so they can write about it.

Other groups to contact You should send your report to Websites such as Secunia and OSVDB, so that they can easily release the information as well, rather than gather it from the mailing lists. Consult your technical people for which resources you should contact.

Blogs and social media Referencing to your blog for further information is a great idea. You can then either release the technical paper on the blog itself, or link to it in PDF format from the blog.

This is about branding to the press. The relevant reporters will soon learn that they should follow your blog for interesting new releases, and they will contact you.

The same can be said of a Twitter account, but the blog is your first step.

Any one of these routes may work for you, and you should examine which one works best for the vulnerability you currently need to release. A combination of these methods is strongly recommended.

Follow Gadi Evron on Twitter: http://twitter.com/gadievron

Gadi Evron is an independent security strategist based in Israel. Special to Dark Reading. Gadi is CEO and founder of Cymmetria, a cyber deception startup and chairman of the Israeli CERT. Previously, he was vice president of cybersecurity strategy for Kaspersky Lab and led PwC's Cyber Security Center of Excellence, located in Israel. He is widely recognized for ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-0404
PUBLISHED: 2019-12-11
SAP Enable Now, before version 1911, leaks information about network configuration in the server error messages, leading to Information Disclosure.
CVE-2019-0405
PUBLISHED: 2019-12-11
SAP Enable Now, before version 1911, leaks information about the existence of a particular user which can be used to construct a list of users, leading to a user enumeration vulnerability and Information Disclosure.
CVE-2019-0395
PUBLISHED: 2019-12-11
SAP BusinessObjects Business Intelligence Platform (Fiori BI Launchpad), before version 4.2, allows execution of JavaScript in a text module in Fiori BI Launchpad, leading to Stored Cross Site Scripting vulnerability.
CVE-2019-0398
PUBLISHED: 2019-12-11
Due to insufficient CSRF protection, SAP BusinessObjects Business Intelligence Platform (Monitoring Application), before versions 4.1, 4.2 and 4.3, may lead to an authenticated user to send unintended request to the web server, leading to Cross Site Request Forgery.
CVE-2019-0399
PUBLISHED: 2019-12-11
SAP Portfolio and Project Management, before versions S4CORE 102, 103, EPPM 100 and CPRXRPM 500_702, 600_740, 610_740; unintentionally allows a user to discover accounting information of the Projects in Project dashboard, leading to Information Disclosure.