Communication of product security Issues.

Chad Dougherty of the CERT Vulnerability Analysis team posted an article on some guidelines the vendor can follow so that their product vulnerability can be communicate to them. Security Experts always try to stick to responsible Full Disclosure rules before making any vulnerability public. So if they are unable to contact the vendor for a long period of time, the vulnerability is made public which can in turn affect it’s many users. To brief the recommendations:

1. Vendor must provide an easily identifiable role email address specifically for product security issues such as “product-security@”, “security-team@”, “security-response@”. Use of standard email addresses such as “info@”, “support@”, and “webmaster@” for the security point of contact as these email ids may be receiving other generic mails too and critical vulnerability information can easily be overlooked or mishandled.

2. Providing a web-based reporting form can help to maintain the vulnerability information in well structured manner that can later be reffered too.

Sample vulnerability reporting form can be found here.

3. Since the vulnerabilities contain sensitive information, it is recommended to encrypt the vulnerability details while generating reports or sending mails to concerned person.

4. Vendor must provide a web-page at “/security” like in “www.product.com/security” which will contain security related issues regarding the product. This can be the information base of all security documents and known security issues pertaining to the product.

5. Send out “signed” email to customers/partners regarding the vulnerability and the patch details which can help them mitigate the issue.

The article concludes with

Vendors’ attention to product security is receiving increased scrutiny in security and IT communities.  Presenting organized methods for communicating product security information is an important element to demonstrating to customers (both current and potential), security researchers, the media, and the general public that you have at least some awareness of and commitment to security. 

Share
  • http://jbrownsec.blogspot.com Jeremy Brown

    There is much controversy regarding the process and there are many way to approach or not approach it, but here are some feelings about it. I may lean slightly off-topic, but bear with me.

    1) Vendors shouldn’t value money over integrity.
    2) It is not a duty or responsibility of a research to notify the vendor of flaws; it was not their fault they were introduced and if the research is not being employed by the company, what motivation, besides be so-called “responsible” with “disclosure” can the he or she have?
    3) There is a difference between business minds and technical minds, so to having the best of both worlds is rare.
    4) Internal audits are usually even more successful if they are not audited by the people who wrote the code to begin with!
    5) Just because an exploit or vulnerability details are released without notice to the vendor, doesn’t mean shame on the researcher. It means shame on the vendor. Vendors should have people watching the lists. Vendors should take a quick, responsible action to make sure their product is “safe” again. Researchers that work with vendors, I feel, are often doing an unnecessary courtesy. Some people view them as wrong even. We all approach disclosure in different ways, and some in many ways. All and none of us are wrong; and no one can 100% justify it one way or the other.

    Its the security industry– its what you can expect.

  • http://maestro-sec.com w0lf

    Hi Jeremy

    I agree with you that it is not the duly of the researcher to inform the vulnerability to the vendor. But this is what termed as responsible disclosure and I feel it to be necessary so that end users should not be victim of some coding bugs of vendors.
    Besides Chad Dougherty’s article states that if you want to inform the vendor about the vulnerability( so that you can give them some timeline before disclosing), then what the vendor can incorporate into their site or what basic guidelines can be followed so that the researcher can easily contact them.
    Otherwise what you stated is true to the most.

  • http://www.mysticnebula.com Chris Vera

    @Jeremy Brown:

    Its unfortunate that we expect vendors to care more about their integrity than money, but we can’t say the same for security researchers.

    If integrity is so important for vendors to have, it should be important for researchers too. Researchers with integrity might consider using a responsible vulnerability reporting framework because it will make them more trustworthy. Trustworthy researchers will be more respected. Good hackers are a dime a dozen. Good hackers that have integrity are more rare, and therefore more valuable to the community at large.

    Report responsibly or don’t. But don’t hold vendors to a standard you are not willing to meet yourself.

  • http://maestro-sec.com w0lf

    Nicely said Chris Vera. Why would the vendor have security-issue contact page when we are not ready to contact them? Even as Jeremy said “Internal audits are usually even more successful if they are not audited by the people who wrote the code to begin with!” But in real life, people who write code don’t audit the code themselves (else we wouldn’t exist) and internal audits may be successful but there are still more limitations on internal auditor than an external researcher.

  • http://jbrownsec.blogspot.com Jeremy Brown

    Thanks for your comments, Chris Vera. Below are mine.

    There is no standard that I will hold either way; it is a form of etiquette. But saying that ‘responsibly’ disclosing security bugs is helpful for everyone, I would suggest another look.

    Does it help companies? Sometimes, if they even have a proper place to report them. But what makes them motivated to fix the bug(s) in a timely fashion?

    Does it help customers? Only if the companies fix the bug in, once again, a timely fashion.

    Does it help hackers? Chances are, every bug one discovers, has already been discovered prior to your discovery and is being 1) exploited in the wild or 2) held for a rainy day (or event).

    But then you take a quick glance at rapid, full disclosure, without contacting vendors: Ask yourself the same questions? Different answers? I would say so. Positive answers? Of course. Negative answers? Of course.

    When someone finds a perfect balance in the humanity of software vendors and security researchers, let me know.

  • http://securityco-op.com Business Security Systems

    Yes, indeed! Vendors must give their contact numbers or addresses so we can track back any pending issues.This adds to the security as well.

  • http://maestro-sec.com w0lf

    Yes. There must be a code of conduct followed by both vendors as well as gray hats so that this works smoothly without any legal issues.