Understanding Vulnerability Disclosure with Mårten Mickos & the HackerOne Team

• 

  Ashley Dotterweich
  

Security vulnerabilities are a reality that every team must face at some point. We asked Mårten Mickos, CEO of HackerOne and members of his security team to share their thoughts on the importance of vulnerability disclosure, the move towards responsible policies, and what teams should do as they prepare to create their own vulnerability disclosure policy.

What has been the biggest change or trend you’ve seen in the vulnerability disclosure in the past year?

Vulnerability Disclosure used to be an obscure practice that only the most responsible or progressive companies and organizations would engage in. Today, it is becoming a best practice. It is part of NIST’s cybersecurity framework which probably is the most used framework of its kind. Nearly all startups have a security@ email address where they receive vulnerability reports from the outside. The DoD is working on a new capability model called CMMC, where every vendor to the Pentagon will be required to be able to receive, analyze and take action on vulnerability submissions.

(CMMC says: “The organization has processes established to receive, analyze and respond to vulnerabilities disclosed to the organization from internal and external sources.”)

What makes a vulnerability disclosure policy a “responsible” one? What are the pros and cons of opting for this model vs. something else?

It’s important to include the boundaries of what you will and won’t do in your policy. Be very explicit about what assets are in-scope, how you wish to communicate with hackers and how you will legally treat those that are trying to work with you — by adopting a safe harbor policy. As we all know, vulnerabilities are in your software and people will find them either intentionally or unintentionally. Anything short of a clear responsible policy will reduce or eliminate the possibility that these vulnerabilities will be disclosed or resolved.

The word “responsible” was added years ago when people worried about irresponsible disclosure and saw other risks. Today, with the vulnerability submission and handling process pretty well defined for all stakeholders, we could consider dropping that word. The vast majority of all hackers will disclose vulnerabilities in the right way to companies, and increasingly companies know what to do once they receive such a report.

What are some common misconceptions about responsible vulnerability disclosure that might be preventing companies from implementing one?

Several traditional behaviors of information security were established before the world became always connected through the internet. In the security profession, there was secrecy, isolation, siloing and belief in perimeter defense. There was a belief that complete security can be achieved. Many practices were established to protect individuals from culpability more than protecting the actual computer systems. As a result, engaging with an external community of security experts was not understood.

To see the immense value of responsible vulnerability disclosure, you need to start by acknowledging that all software has vulnerabilities. Secondly, you need to believe that people on the outside of the organization are to the largest extent people with good intent whose help can be useful. Thirdly you need to realize that you are in better shape, not worse shape, when you know about a vulnerability compared to not knowing. Fourth, no matter how hard it may be to fix a bug, you need to come to the insight that every bug can be fixed or access to it can be blocked, i.e. there is always a cure.

If a team wants to launch a vulnerability disclosure policy (VDP), what’s the first step they should take?

The first action is to obtain alignment internally and commitment from the software engineering teams to fix the most critical vulnerabilities when they are reported.

HackerOne’s guide on VDP Basics outlined five critical components. Of these five, is there one that teams find the most challenging to get right? Why do you think that is?

Opinions may vary, but the initial promise is quite a substantive commitment to live up. The success of a vulnerability disclosure program depends on the everyday attention to whatever hackers are reporting to the organization. Staying on top of the queue and always responding promptly to hackers takes some discipline – and leads to success of the overall program.

Finally, are there any additional resources on vulnerability disclosure that you would recommend?

The following are some great resources for learning more about vulnerability disclosure and cybersecurity policies:

• OWASP Cheatsheet
• NIST cybersecurity framework
• DoJ framework for cybersecurity
• Atlantic Council comic booklet on vulnerability disclosure
• The Hacker Powered Security Report 2019

Additionally, you can find a wide range of existing vulnerability disclosure programs that are worth reviewing as you build your own:

• EFF.org
• IBM
• GM
• Department of Defense
• Central Security Project
• PHPBB
• Copper (launched in Sep 2019)

Learn More about Vulnerability Disclosure and More from DevGuild: Enterprise Security Talks

Security has taken a more central role in the business strategies of growing companies, and knowing how to approach security effectively is key. At DevGuild: Enterprise Security, we learned from CISOs of organizations like Splunk, Atlassian and HashiCorp about how to create strong security processes. Watch the sessions here and check out other security content in the Heavybit library.