The Seven Deadly Sins of Security Vulnerability Reporting

On a previous post, I opened the door for a new blog post with the goal of providing a few specific recommendations (from a security researcher perspective) for organizations, commercial companies, and open-source projects in order to improve the resources and procedures they put in place to be notified and act on security vulnerabilities on their official web site(s), services, or any of their products.

The Seven Deadly Sins of Security Vulnerability Reporting pretends to become an easy to follow list, not very technical but security relevant (so that we can point people to it), for any organization interested on improving the process of dealing with security vulnerabilities reported by external security researchers (or third parties). It is the result of common issues we found when reporting vulnerabilities and findings during penetration tests, security research, and incident handling:

1. Communication channels
2. Confidentiality
3. Availability
4. ACK
5. Verification
6. Interactivity
7. "Researchability"

I strongly recommend you to go through the list during this Summer, identify what sins you can redeem in your environment, and implement the changes on September! Let's get ready for the new season!

1. Communication channels
Do you have clear and simple communication channels to be notified about security vulnerabilities in your environment and products?

Provide a clear and simple notification channel (or channels) for researchers to submit security vulnerabilities about your environment and products. Two of the most common methods are e-mail (use an easy to remember e-mail address, like security@yourdomain.com or secure@yourdomain.com - very common nowadays) and an easy to remember web page, such as https://www.yourdomain.com/security/. This page might include a web-based contact form, although I personally prefer e-mail, so it can just contain the details to contact with your security team.

2. Confidentiality
Do you have secure communication channels to receive sensitive and/or confidential notifications?

Implement secure communication channels to receive the security-related notifications by using strong encryption. This way, anyone eavesdropping on the communication won't be able to get all the details about the vulnerability.

• For the web-based option, make use of a trusted HTTPS connection for the web page used for the notifications (Did you see the "https://" above?). Do not use HTTP!
• For the e-mail option, create and publish the GPG/PGP key associated to the e-mail address used for the notifications. Have the key ready in advance, and make it easily available and verifiable: use your web site plus the public GPG/PGP servers for its publication and distribution.

Always use the secure channel. As obvious as it might sound, for some reason, it is very common for people to end up not encrypting one of the messages at some point during the process of solving the vulnerability and finding the fix, disclosing confidential details as a result.

3. Availability
Are the notifications channels available 24x7, specially, when they are required ;)?

Ensure the web page and e-mail address used for the notifications work as expected and are always available. This is easier said than done. Are you sure someone in the organization is receiving the notifications? Check all the notification methods frequently, or at least, from time to time.

4. ACK (Acknowledgment)
How can the researcher know you have received the notification?

As soon as possible, reply with a quick e-mail message to the researcher confirming you have received the notification, and explain that the notification is going to be reviewed and verified in the next few days. This way the researcher can confirm you got the notification, she knows she can expect a further detailed message and when (try to define what "a few days" means), and you are both in sync.

The initial acknowledgment message (and associated exchange) is a great time for sharing GPG/PGP keys and verifying the secure communication channel works.

If you put in place an automatic response system to confirm the reception of messages on the web or  e-mail notification channels, ensure you also provide a second human-based reply, so you demonstrate there is someone behind it, reading and processing the notifications.

Remember, e-mail is not a 100% reliable notification system (SPAM filters apart ;)), so I recommend you to acknowledge relevant messages during the whole process.

5. Verification
How do you know if the notification is related with a new vulnerability (0-day) or is a well known issue?

Take your time to read and understand in detail the contents of the notification and do not make assumptions till you test the issue in your environment. Clarify with the researcher any unclear points or undefined areas till you are able to reproduce it. Verify and, confirm or deny, if it is something you already knew about or a new vulnerability (0-day).

6. Interactivity
Once you confirm it is a new vulnerability, design a plan to fix it, and keep all parties involved informed about how the plan progresses.

This is all about information exchange, isn't it? Improve the information exchange procedures you put in place during the process of testing and fixing the issue. I highly recommend you to periodically notify the security researcher about how the fix progresses and any other relevant actions you take.  During the process, you can plan and agree on the deadlines for future actions and the final (responsible) disclosure date.

Apart from using periodic status updates, avoid not responding to e-mails. I you do not have an answer yet, or need time to review the data and provide an answer, once again, send a quick message to the other party and set a reasonable timeframe to keep the information exchange flowing.

7. "Researchability"
All the previous sins provided guidance to the organization that has the responsibility to fix the vulnerability, but... what about the security researcher that found it?

I'm sure there are things we (as security researchers) do wrong, so this last sin is reserved for us :) A few common mistakes not to forget are:
- Follow the responsible disclosure principle (it seems nobody really knows what this means, or has its own definition ;) ).
- GPG/PGP does not encrypt the e-mail subject, so provide enough information in the subject to differentiate it from other notifications (for example by using an identifier), but do not include too much information so that other people could know what is going on.
- Everybody's time is valuable, so before taking the time to report a vulnerability, be sure you have thoroughly tested it and are able to reproduce it (if possible, on the latest product version and, definitely, with the latest patches and updates applied). Try to confirm in advance if it is a well known, previously published, vulnerability or not. You don't want to end up wasting everybody's time (including yours) to confirm it is something that was already fixed a while ago.

Credit
Once a fix for the vulnerability is available and it is finally announced, provide credit where appropriate.