Preparing a CVD policy
By formulating its own CVD policy, an organisation as the owner clarifies how it deals with reports of vulnerabilities in their IT systems. In this way, an organisation itself determines the way in which it wants to receive reports and accept assistance from reporting parties.
Formulating a CVD policy requires that an organisation must be aware of the security of IT systems with online access. In this policy, the organisation states the rules under which researchers may look for vulnerabilities, the techniques that are permitted, as well as the systems which do and do not fall within the scope.
Five steps to a CVD policy
In our guideline entitled Coordinated Vulnerability Disclosure, we set out how an organisation can prepare a CVD policy in five steps. The CVD process takes place between an organisation and a reporting party.
- Establish the rules
- Make capacity available
- Receive reports
- Resolve the problem
- Reward the reporting party
The NCSC encourages the owners of critical IT systems to set up a CVD process. If an organisation so wishes, we can share information about the vulnerability with our target groups in order to mitigate as far as possible the security risks that stem from the vulnerability.
If necessary, the NCSC also acts as an intermediary; for instance, when the owner of the IT system does not respond to a report.
1. Establish the rules
By laying down the rules, the organisation sets a low threshold for a reporting party to submit a report about a vulnerability or flaw. Useful tools are a standard online form or an exclusive email address for reports.
Another rule is the decision whether or not to accept anonymous reports. It is also important to state the systems which do or do not fall under the scope of the CVD policy. This process also shuts down the possibility of accepting reports about systems outside of the scope.
2. Make capacity available
The organisation reserves internal capacity and sets up a process in order to respond adequately to reports. One example is designating a team or department best suited to receiving reports.
In this respect, the origin of the report is irrelevant. The vulnerability could also be discovered by an employee or by a system test.
Experience shows that there will be a greater interest in reporting vulnerabilities to the organisation after the publication of a CVD policy. The organisation takes this fact into account by deploying additional personnel.
3. Receive reports
When the organisation receives the vulnerability report, it ensures that it reaches the department that deals with it as soon as possible. The reporting party receives an acknowledgement of receipt of the report, preferably signed digitally to emphasise its priority.
Next, the organisation contacts the reporting party to agree whether and when the vulnerability or report is disclosed. The period depends on the nature of the vulnerability and the type of system. A frequently used guideline is a period of 60 days (approximately two months) for the publication of vulnerabilities in software. Resolving vulnerabilities in hardware often requires more time, up to six months.
4. Resolve the problem
The organisation sets to work on resolving the problem and keeps the reporting party informed about the resolution process.
A vulnerability may prove difficult or impossible to resolve, or there might be high costs involved in resolving it. An organisation sometimes decides to regard the vulnerability as an accepted risk and not remedy it.
It appears that communication with the reporting party about the resolution of vulnerabilities makes a positive contribution to the organisation’s reputation.
5. Reward the reporting party
If the reporting party has adhered to the rules in the CVD policy, it is recommended to reward the reporting party for its efforts; for instance, by publicly thanking the reporting party for its contribution to improving the security of the IT systems. A monetary reward is also appreciated. The level of the reward can depend on the quality of the report.
Granting a reward and/or giving public recognition creates a better relationship between the reporting party and the organisation. It also increases the willingness to submit new reports. If there is a possibility of the vulnerability also existing in other places (in other organisations or in other IT systems), the organisation can agree with the reporting party to inform the wider IT community.