SANS ISC: The Seven Deadly Sins of Security Vulnerability Reporting - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

The Seven Deadly Sins of Security Vulnerability Reporting pretends to become an easy to follow list, not very technical but security relevant (so that anyone can point people to it), for any organization, commercial company, and open-source project in order to improve the resources and procedures they put in place to be notified (by external security researchers or third parties) and act on security vulnerabilities on their official web site(s), services, or any of their products

This is a scenario we (Internet Storm Center handlers) frequently find ourselves at, when notifying findings during our daily activities, or acting as a vulnerability reporting proxy for other researchers.

Below you can find the summarized list, while the additional reasoning and comments for every item are available on the original post I made on Taddong's Security Blog.

1. Communication channels: Do you have clear and simple communication channels to be notified about security vulnerabilities in your environment and products?
2. Confidentiality: Do you have secure communication channels to receive sensitive and/or confidential notifications?
3. Availability: Are the notifications channels available 24x7, specially, when they are required ;)?
4. ACK (Acknowledgment): How can the researcher know you have received the notification?
5. Verification: How do you know if the notification is related with a new vulnerability (0-day) or is a well known issue?
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.
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?
   
   Bonus: Once a fix for the vulnerability is available and it is finally announced, provide credit where appropriate.

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!

Please, share with us any finding or remarkable situation you might have found when reporting vulnerabilities (or when someone reported vulnerabilities to you), through the contact page or the comments section below.

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com