UK PSTI? You’ll need a Vulnerability Disclosure Program! 

If you are distributing or selling smart devices in to the UK market, your products will need to be compliant with the UK Product Security and Telecommunications Act.

One of the three mandatory areas is that you have a vulnerability disclosure program (VDP) 

In the supporting materials for the Act, the description is as follows: 

Information on how to report security issues

The manufacturer must provide information on how to report to them security issues about their product. The manufacturer must also provide information on the timescales within which an acknowledgment of the receipt of the report and status updates until the resolution of the reported security issues can be expected by person making the report.   

This information should be made available without prior request in English, free of charge. It should also be accessible, clear and transparent.  

So where on earth do you start?

I’ve spent over 20 years disclosing vulnerabilities to organisations and now run courses, teaching how to run a successful VDP. Here’s a brief summary that should get you started. 

Step 1: RFC 9116

RFC 9116 is a file format to aid in security vulnerability disclosure.

Publish a security.txt file on your web site with details of how and where you would like vulnerabilities to be reported to. 

Link to your vulnerability disclosure policy 

Step 2: write your vulnerability disclosure policy

Describe how you will behave in response to a security report and stick by it. 

Be fair and open, always take the moral and ethical high ground. 

Ask how you would like the reporter to behave. 

There are many examples of policies, but you need to customise yours to suit your organisation. Take advice and engage the teams who will be part of the respond to vulnerability reports. 

Here are a few you might review to get started: 

UK Gov: https://www.gov.uk/help/report-vulnerability 

US FCC: https://www.fcc.gov/vulnerability-disclosure-policy 

US CISA: https://www.cisa.gov/coordinated-vulnerability-disclosure-process 

Nestle: https://www.nestle.com/ask-nestle/our-company/answers/vulnerability-disclosure-program 

Step 3: allocate resources to your VDP

You receive a report. What next? 

Someone needs to be responsible and accountable for taking the lead. Who is that? 

Who is responsible for internal and external communication? 

Who is responsible for triage? 

Who is responsible for fixing the issue? 

Step 4: empower the team who run your VDP

This is a really common failing: getting priority from development teams to address security flaws is hard! 

It’s also hard for organisations to appreciate the reputational damage that can come from mishandled vulnerabilities. 

Who has the power to escalate issues? Who will listen to them? 

At its simplest, does the team have the ear of people who can make decisions to take important revenue generating systems down whilst critical vulnerabilities are fixed? 

Step 5: run training across your organisation about your VDP

It’s hard for dev teams and product owners to hear that their product isn’t perfect. 

Run training and awareness sessions, so your teams understand that curve-ball requests might come in at short notice. 

Step 6: stress test your VDP

Submit a vulnerability report yourself at a weird time of day. Does your process work? 

Were you communicated with as expected? Did the triage process work and were responses sent to the researcher in the timeframe promised in your VDP? 

You could even run a table top exercise where injects are presented to be dealt with in real time by your team. It’s a great fun exercise! 

Gotchas

You don’t get to dictate what the reporter does with the vulnerability they’ve found. You can only ask and potentially incentivise responsible behaviours 

Hence, NDAs are a no-no. Many researchers will be irked if you ask for a non disclosure agreement 

Don’t forget to say ‘thanks’ and potentially offer swag. 

Don’t forget to communicate with the reporter, regularly. 

Don’t spook the reporter with legal threats, unless they’ve stepped well over an ethical line, perhaps through copying excess data or threatening extortion. 

Outsourcing your VDP

Many of the bug bounty (BB) platforms offer to manage your VDP for you. Use caution! 

BB platforms are commercially motivated businesses: they will want the reporter to agree to terms that usually prevent disclosure, in exchange for payment of a bounty. They typically have a ‘one size fits all’ approach that doesn’t always work for many researchers and reporters. 

This works, sometimes. Sometimes it doesn’t. The motivations for the BB platform are different to yours and different to the reporter’s motivations. This can cause issues for all. 

You MUST have the ability to receive direct vulnerability reports in to your organisation too. Some researchers will not want to go via a BB-managed VDP as the terms aren’t acceptable. 

Conclusion

Receiving and handling vulnerability reports doesn’t have to be a stressful experience, you just need to create a policy, allocate resources to it and then stress test it. 

This is a very quick introductory guide, if you need more guidance or advice, do drop me a line on X / Twitter @TheKenMunroShow.