Jisc’s vulnerability disclosure policy, the first 1,000 days

Jisc launched its vulnerability disclosure policy in February 2019. The policy was drawn up using ISO 29147:2018, and using guidance from other organisations, most notably NCSC-NL. Here, we look back at some of the trends and successes, as well as the lessons we’ve learned and what we have planned in future.

The policy encourages external security researchers to help us improve the security of Jisc systems and processes, by advertising a process by which they can report problems they spot and we undertake to deal with those reports.

During the first 1,000 days we’ve received over 264 reports from 179 different researchers. Of those reports 87 (33%) were determined to fall outside of the scope of our policy. Although we still investigate these and thank the reporter, we do not feature these on the wall of fame to encourage researchers to follow the policy. None of the reports, in or out of scope, gave us cause to believe that they were not being reported in good faith, or that Jisc was being put at risk by actions of the reporter.

We use MITRE CWE (Common Weakness Enumeration) as a taxonomy for recording the types of issues contained within the reports. Possible exposure of sensitive information (by which MITRE mean anything that shouldn’t be public), Cross site scripting and issues with SPF and DMARC records account for over 50% of all the reports we received. These and opportunities for clickjacking, DDoS and subdomain takeovers accounted for 80% of reports. In summary – a small number of issues accounted for most reports.

Using the structure provided by CWE we can identify that improper control of resources, neutralisation of data, and access control are the most common “research concepts” at the root cause of almost all the reports we receive.

Things we’ve learned

All the in-scope (and many of the out-of-scope) reports have led to improvements to Jisc’s systems and processes. Achieving this through penetration testing would have been commercially prohibitive, and would not have created the same expert community working to support Jisc’s – and our members’ – interests

If you haven’t fixed lower priority issues like missing DNS records, missing HTTP headers, or your TLS configuration you should expect large numbers of reports that take more effort to handle than they do to fix.

We get patterns where we receive many similar reports from different researchers within a few days or weeks. This may be driven by the availability of new tools and may also be a sign that the same issues will be exploited soon.

You’ll want to analyse the results to drive improvements in software development practices and demonstrate the effectiveness of your programme. This is difficult if there is no structure to the data you’ve captured. We did this using MITRE CWE.

Even if you don’t offer financial rewards for the reporting of vulnerabilities, you should be prepared to deal with researchers who are expecting one. It’s never become a problem for us but if poorly handled it could lead to a tense situation.

Future plans

We’re looking at expanding the scope of the policy to include all our systems, products, and processes. This should increase the benefits to Jisc and provide researchers with greater clarity as to what is or is not in scope. Besides, we already receive a lot of out-of-scope reports which we respond to, the only thing we do differently with them is not acknowledge them in our hall of fame.

We’re also looking at whether we can offer greater rewards than just acknowledgement on our hall of fame, and if this would result in attracting different sets of researchers and more impactful reports. It feels likely that the most competent researchers are going to focus their efforts where they can be best rewarded. As a membership organisation and charity, we will need to think carefully about this step.

We’re also looking at moving the workflow into our new ITSM software. This should allow us to provide a better and more consistent response to researchers and help us capture improved data on how we respond to reports.

As we evolve our vulnerability disclosure programme we’ll write about it on this blog. Subscribe to the RSS feed to receive updates and more cyber security posts from Jisc.

Leave a Reply

Your email address will not be published. Required fields are marked *