There’s an obvious but important rule in cybersecurity: the quicker you find out about a weak spot, the stronger the chances of being able to fix it before it causes any damage. It follows that if someone else notices an issue before you do, you should make it as straightforward as possible for them to tell you about it.
It’s best practice to have a set procedure for this (aka a vulnerability disclosure policy). If you don’t have one yet, the UK’s main cybersecurity agency has just launched a toolkit to help you quickly build your own.
Here’s the lowdown on vulnerability disclosure policies; who needs one and why – along with a closer look at the new toolkit.
What is a vulnerability disclosure policy?
A vulnerability disclosure policy provides a clear channel for people to report problems. Think of it as a kind of neighborhood watch scheme for your internet assets.
It might be a tech expert who’s been looking over your code and who wants to tell you about a backdoor vulnerability. Or it could be a customer who’s just noticed that the tracking feature on your new fitness app reveals the home postcodes of nearby users (something you almost certainly didn’t intend to happen!).
Do we need a vulnerability disclosure policy?
If your organization connects with outsiders via internet channels, computer software or hardware that you control, it’s usually advisable to have a policy in place.
Examples of assets that should be covered by such a policy include your website, your company app and connected equipment (e.g. smart meters).
You may also want to establish a separate policy to cover the technology your staff use internally. This is especially relevant now that so many of us work remotely. As an example, let’s say a company has created its own web hub for communications and for accessing work systems. You need a set procedure for users to notify you of any issues with it – no matter where they happen to be based.
What are the benefits of a policy?
It shows that you take security seriously. Your reputation is all-important. With a clear vulnerability disclosure policy in place, you are showing the world that you are alive to the cybersecurity and privacy risks that are out there – and you are proactive in addressing them. In short, you’re a safe pair of hands for doing business with.
Testing only takes you so far. Your new app has just launched. The code has been checked and rechecked; the beta testing went well and you’re confident that all issues have been fixed. But even with all the right safeguards in place, bugs can still slip through the net. Some vulnerabilities may only be detectable further down the line. Your vulnerability disclosure procedure becomes part of your ongoing strategy for safeguarding your assets.
Putting white hat hackers to work. There are lots of experts out there who love to pick out organizations, delve into their infrastructure and test their virtual fences to find the security gaps. A vulnerability disclosure policy gives you a framework for building a positive relationship with this white hat hacker community. It provides a formalized channel for these individuals to reach out to you.
Staying ahead of the law. At the minute, vulnerability disclosure falls under the category of best practice. In other words, it’s something that responsible companies are encouraged to do – rather than being forced into it. But this is changing, and in the next few years, we’re likely to see a global trend in favour of mandatory disclosure policies. In the UK for instance, a law is being drawn up that will force all manufacturers of consumer smart gadgets to have vulnerability disclosure programs in place. Meanwhile, the US Cybersecurity and Infrastructure Security Agency (CISA) has just made it mandatory for all US government agencies to instigate disclosure policies. Acting now pre-empts being forced to act later on.
What should a policy contain?
In 2017, the US Department of Justice published a framework for organizations looking to implement vulnerability disclosure policies. These guidelines have become the global standard for companies, and you can read them here.
There are five basic components:
- Promise. This is where you define the purpose of the policy and what you hope to achieve from it, i.e. by setting out your commitment to security and customer privacy.
- Scope. Where you set out what assets are (and are not) included in the policy. For instance, you might want to state that the policy covers your app and website, but not your courier’s website!
- Safe harbor. This is particularly relevant to white hat hackers. You need to reassure them that no legal action will result from them researching your assets, abiding by your rules and reporting to you in good faith.
- Process. You need to set out a clear mechanism for people to report incidents (e.g. via an email or web form).
- Preferences. Here, you set out what happens next after a vulnerability has been reported. Areas to cover include the expected duration between submission and initial response and whether or not people have permission to publicly disclose vulnerabilities.
What is the new toolkit?
The UK’s National Cyber Security Centre (NCSC) has released a guideline for companies to set up their own policy.
This includes a policy template that you can adapt. It also includes a Security.txt code extract that allows you to integrate a secure web form into your website. This ensures that the person reporting a problem can contact you easily and securely. It also provides a clear link to your actual policy.
You can access the toolkit here.
If you are looking to grow your cyber security skills and advance your career, I have a Cyber Security Career Development Platform where you can get VIP membership to over 1,000 classes, virtual labs, practice tests, and exam simulations.