We were engaged by a large Dutch university to provide legal assistance in the disclosure of a security flaw in a popular hardware interface.
Be aware of the legal risks regarding security research
A researcher identified a loophole in a widely used interface for quickly transferring data to and from a computer. The researcher wanted to publish their findings. However, disclosing a vulnerability involves a lot of legal risks – and previous cases (e.g. Radboud University/NXP) show that vendors won’t hesitate to invoke multiple legal doctrines to stop the publication of any vulnerabilities found in their systems. We devised a strategy to streamline the disclosure process in order to avoid a publication ban on the researcher’s work.
Assume responsibility for your actions
In the Netherlands, the National Cyber Security Centre (NCSC) has published a guide to handling vulnerability disclosures. This guide makes it clear that the person reporting the vulnerability is responsible for his or her own actions and must observe the principles of proportionality as well as subsidiarity when investigating and reporting vulnerabilities. In other words, the reporter should not do more than what is necessary to demonstrate the vulnerability, and always report the vulnerability to the vendor before making it public.
Choose the right time to publish
The timing of the report’s publication is crucial. Immediate publication of the vulnerability could encourage attacks and damage to the vendor(s) concerned. But keeping the vulnerability secret would mean that people are still exposed to security threats. To reduce the legal risks, the reporter must give the vendor an appropriate timeframe to fix the vulnerability (if possible), while minimizing the window of opportunity for people to continue to exploit the vulnerability.
Show good intentions
When disclosing a vulnerability, it is vital that the vulnerability report submitted to the vendor is in order. It should clearly establish the ‘white hat’ credentials of the reporter by listing his or her academic background and showing his or her good intentions. It is also important to explain the pressing social need to reveal the vulnerability to the public.
If the reporter wishes to be eligible for compensation, he or she should consider following the vendor’s bug bounty guidelines (if they have any). However, the reporter should be careful of unilaterally drafted ‘take-it-or-leave-it’ terms that basically silence reporters in exchange for a fee (the bounty).
Check if the vendor has a responsible disclosure policy
In addition to bug bounty guidelines, a vendor may have a responsible disclosure policy. There is no legal rule that obliges a reporter to comply unconditionally with the conditions of a vendor’s vulnerability program, especially if they lack safe harbor language for the reporter (i.e. a commitment from the vendor not to pursue legal action against a white hat hacker).
To increase the chance that the publication is seen as legally justified, our advice is to follow the vendor’s vulnerability program conditions as much as possible – but not if it is detrimental to the reporter (e.g. if the disclosure deadline can be unilaterally extended by the vendor).
It is important to communicate regularly and pro-actively with the vendor throughout the disclosure process. Be clear about future steps the reporter intends to take, for example if he or she intends to speak at a conference about the vulnerability. In our experience, disclosure processes rarely run smoothly, especially if multiple vendors are involved in a complex supply chain. If the process of reporting the vulnerability does not go as expected, consider involving the NCSC to act as an intermediary.
Our careful preparation of the vulnerability disclosure enabled the researcher and the university to avoid legal pitfalls – and most importantly to reveal the details of the vulnerability to the public.
Please do not hesitate to contact us if you have any questions.