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:
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/?)
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.
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.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.