It is important to recognise that although setting out a policy and process for RD is a practical step to take, the circumstances of any disclosure can vary greatly
When it comes to vulnerability management, CISOs should define a responsible disclosure policy so that they can receive and manage identified vulnerabilities transparently, practically and collaboratively, says Paul Watts of the ISF.
Identifying and managing software vulnerabilities has always been a key component of good security hygiene and this has become increasingly important to CISOs as the world becomes more interconnected and enterprises push on with digitally transforming their businesses. Security researchers are part of the vulnerability management ecosystem, leveraging their craft to identify vulnerabilities that, if exploited, present clear and present risk to consumers. But when a researcher identifies those vulnerabilities, imparting the information effectively and constructively has been an historical challenge.
There is no particular standard for defining your approach to RD or even how actively you promote it. Incentive schemessuch as bug bounty programmescan be useful, but can also present different challenges, including increased workloads driven in some cases by lucrative financial incentives. Organisations such as the UK’s National Cyber Security Centrenow provide useful toolkitsto get you started.
However, it is important to recognise that although setting out a policy and process for RD is a practical step to take, the circumstances of any disclosure can vary greatly. Be prepared to operate outside of the process depending on the circumstances, as long as you reach the desired and published “good” outcome at the end.
When a disclosure is made, the initial triaging of that information helps to determine the next steps. The objective here is about reducing harm and managing risk, but sometimes there can be difficult judgement calls to make. Declaring a vulnerability before a patch is available can cause angst amongst customers, but the counterbalance is that you can have a transparent conversation about workarounds and mitigation.
If the vulnerability relates to a safety-critical asset, any disclosure without first having a patch could be high risk, especially if the exploitability potential of the vulnerability is high.
Similarly, there can be moral and ethical issues to debate. What if a vulnerability is big enough to transcend multiple vendors, products and end-users? In this case, should you go public quickly so that the problem can be worked through as a collaborative effort, even though that could cast a shadow on your own organisation? What if this vulnerability is in the public domain already? What if the disclosing party has already communicated outside of your RD process?
You risk reputational damage if it transpires that they had warned you up front and perceptively you did nothing about it. A pre-emptive communication may alleviate that risk, or it might create another. Every situation is different, but at least you’ll not be coming at the problem cold if you’ve planned ahead.
Having a clear stance on RD drives transparency and demonstrates commitment to the cause. Each party will know up-front how to engage and where they stand in terms of potential outcomes. Planning what you will do before the circumstance arises is a practical step, but must account for uncertainty, recognising that no two scenarios are the same but are likely to present a different set of moral, ethical and logistical challenges to overcome.
Paul Watts, ISF Distinguished Analyst