Vulnerability Disclosure Submission Standard?

I present you with RFC2142, please take a minute to skim through it for a little context. This RFC aggregates all of the recommended mailbox names that network and computer operators should setup depending on what public services they offer (You did setup and continue to monitor important mailboxes like postmaster, abuse, and so on, right?). The idea behind this is, if someone has a mail issue, they can just email POSTMASTER@domain.tld. If there is an issue with the website, send it to WEBMASTER@domain.tld. Having these predefined mailboxes takes all the thought out of the process, and saves people from having to pick up the phone, or start hunting around the website for a contact form, and just send the message and get on with their day. People have become lazy regarding these best practices, so this blog is also to raise awareness about that particular practice as well.

So how does this relate to security, you ask? One of the dumb problems in the security industry is that there isn’t a standard way to disclose vulnerabilities to vendors or to network operators. Unless you have some sort of existing relationship with the company, or they go above and beyond in terms of security responsiveness (which is almost nobody), you start pitching your vulnerability disclosure into various e-mail boxes, snailmail letters, voicemail boxes, etc. More times than not, the information doesn’t make it to the right person, so you end up disclosing. When the bad press happens to catch someone’s attention, they get upset because you didn’t tell them about the problem first. It’s a lose-lose situation for everyone involved.

My suggestion is to resurrect good internet stewardship, and start standardizing on the SECURITY@domain.tld for vulnerability and security disclosure. The above RFC was written in 1997 and includes this mailbox under section 4 “NETWORK OPERATIONS MAILBOX NAMES,” so at least there is existing precedent for this naming convention. I suggest we expand the scope a little and use that mailbox for any security related topic. This can include, but is not limited to:

  • Vulnerabilities on a website
  • Vulnerabilities in software distributed by that company
  • Vulnerabilities in services offered by the company
  • Vulnerabilities on a public facing network or system that is maintained by that company
  • Publicly leaked information on a websites like pastebin
  • Sensitive documents blowing in the parking lot

What you do with the mailbox is up to you, but here are some ideas:

  • Have an employee check this box once in a while, and manually distribute the messages to those that need the information.
  • Create a secondary mailbox in Exchange that people can attach to and have your infosec department manage the mailbox.
  • Create a distribution group or mailing list with key members of your organization subscribed.
  • Have a ticketing system monitor the mailbox and create cases or tickets automagically when something comes in.

While we’re talking about standardizing vulnerability disclosure, lets put together some high-level process objectives we could all strive to attain:

  1. All messages received on SECURITY@domain.tld should send an auto-reply back to the user immediately thanking them for their submission, and include a URL to a page with more information about that company’s vulnerability process. (We could even standardize the URL, how about something like www.domain.tld/security/?)
  2. Within no more than 7 calendar days, the vendor MUST send a response back to the vulnerability submitter. The response should contain a case or ticket number they can reference in the future and a means of communication to check up on the status of the vulnerability. This gives the vendor an opportunity to accept the vulnerability as legitimate and issue a case or ticket number, and drop all other spam messages without assigning case numbers to bogus requests or spam messages. If no ticket number is issued within 72 hours for any reason at all, the submitter is free to disclose publically. If the submission is granted a ticket number, a three-month gag order and moratorium starts. The submitter should be reasonable and grant more time if the vendor gives a valid reason. For example, if the vulnerability were so widespread that a vendor would have to rewrite the entire application from the ground up, 3 months wouldn’t be enough time.
  3. Once 3 months (or whatever the agreed upon time frame) is up, the vulnerability submitter is free to speak, blog, tweet about the vulnerability as they see fit. Once the gag timer expires, the submitter’s responsibility is terminated.

I realize this is a lofty idea that will get ignored, but I can dream. Thoughts, comments, and ideas on this are all greatly appreciated. Have you implemented something similar in your organization? Let me know in the comments how it worked for you.

UPDATE: since the release of this blog, a couple new standards have been released. ISO 24197, and ISO 30111 have been released for public consumption. I’ve not read either of these standards, but they should be reviewed by organizations when writing their vulnerability disclosure and handling policies.

Discover why security operations teams choose NetSPI.