Home | About this website | Privacy Statement: Apeldoorn Municipal Council | Coordinated Vulnerability Disclosure (CVD)

Coordinated Vulnerability Disclosure (CVD)

The municipality of Apeldoorn attaches great importance to the security of its systems. As part of our commitment to cybersecurity and the protection of our systems, we recognise the importance of identifying and reporting vulnerabilities. The CVD is designed to provide a structured framework within which security experts can report vulnerabilities.

We ask that you do the following when reporting a CVD

  • Reporting
    Please report the vulnerability to us as soon as possible after discovering it. The reporting procedure is set out below. Findings can only be brought to the organisation’s attention in this way.

    Please email your findings to cvd@apeldoorn.nl (to be used only for CVD reports). You can also submit the findings securely and in encrypted form via the website https://crypt.apeldoorn.nl/.

  • Information
    We would also ask you to provide sufficient information to enable us to reproduce the problem, so that we can resolve it quickly. The IP address or URL of the system in question and a description of the security issue will suffice. Any additional relevant information and tips are always welcome, as they may help us resolve the issue more quickly. Please do avoid promoting specific (security) tools, however.

    Information about the security issue should not be shared with others until the issue has been resolved. Once the matter has been dealt with, it is possible to publish details of the vulnerability, subject to consultation.

  • Contact
    We would ask you to provide your contact details so that we can work together to resolve this issue. Please provide at least one email address or telephone number. This will enable our Security Operations Centre to get in touch with you.

The following actions are not permitted

  • Installing malware.
  • The brute-forcing regarding access to systems.
  • Using social engineering, unless this proves strictly necessary to demonstrate that an employee has failed in their duty to handle sensitive information with due care.

This must be done entirely by lawful means; in other words, not through blackmail or other dishonest practices. Any findings obtained through social engineering must be intended to identify a security issue in the municipality’s procedures and working practices, not to cause harm to a municipal employee.

  • Publishing or disclosing the security issue before it has been resolved.
  • Carrying out unnecessary actions that go beyond what is strictly necessary to identify and report the security issue. Downloading, modifying or deleting data or system configurations is never permitted.

An alternative to this is to create a directory listing or take a screenshot.

  • The use of techniques, such as a DoS attack, which limit the availability and/or usability of our systems or services.

What else you can expect

Legal aspect

  • If you meet all the above conditions, we will not take any legal action in response to this report. However, if it transpires that you have breached the above conditions, we may still decide to take legal action against you.

Contact regarding the report

  • We will send you an (automatic) confirmation of receipt within 1 working day.
  • We will respond to your report within three working days with our (initial) assessment, including an expected resolution date.
  • We will keep you informed of any progress regarding the report. We will resolve the security issue you have identified as quickly as possible and aim to resolve the problem within 30 days. In doing so, we are often dependent on our suppliers.

How we will handle your case and the report

  • We will treat your report in confidence and will not share your personal data without your consent, unless we are required to do so by law or by a court order.
  • We always share any reports we receive with the Information Security Service for Local Authorities (IBD). In this way, we ensure that local authorities can share their experiences in this area with one another.
  • The manner in which the vulnerability is to be disclosed can be determined by mutual agreement. This will only take place once the problem has been resolved.

Remuneration

  • We can offer you a reward as a token of our appreciation for your help. Depending on the severity of the security issue and the quality of the report, this reward can range from a simple ‘thank you’ to a sum of up to €300. However, the issue must be a previously unknown and serious security issue.

In the case of a vulnerability involving a low or accepted risk, the Municipality of Apeldoorn may decide not to offer a reward for a report. Below are some examples of such vulnerabilities. This list is not exhaustive.

  • HTTP 404 codes or other non-HTTP 200 codes.
  • Adding plain text to 404 pages.
  • Version banners on public services.
  • Files and folders containing non-sensitive information that are accessible to the public.
  • Clickjacking on pages without a login function.
  • Certificates with weak or outdated ciphers.
  • Cross-site request forgery (CSRF) on forms that can be accessed anonymously.
  • Absence of ‘secure’ / ‘HTTP Only’ flags on non-sensitive cookies.
  • Using the HTTP OPTIONS method.
  • Host Header Injection.
  • Absence of SPF, DKIM and DMARC records.
  • One or more HTTP security headers are missing.
  • Support for ‘auto-complete’ or ‘save password’ functions. Brute-force attacks on the ‘forgot password’ form and ‘account lockout’ are not prevented.
  • The absence of a confirmation step, such as re-entering a password or requesting an additional email confirmation.
  • The absence of HTTP Public Key Pinning (HPKP).
  • Content spoofing and text injection on pages displaying an error message.
  • Reporting old software versions without a proof-of-concept or a working exploit.
  • Expired or inactive domain names.
  • Same-Site Scripting or use via a localhost DNS rule.
  • Lack of DNSSEC.
  • Potentially outdated server or application versions (from third parties) without evidence that these versions are vulnerable and without evidence of exploitation.
  • Potentially outdated server or application versions (from third parties) without evidence that these versions are vulnerable and without evidence of exploitation.
  • Missing or incorrectly configured HTTP security headers, such as:
    • Strict Transport Security (HSTS).
    • HTTP Public Key Pinning (HPKP).
    • Content Security Policy (CSP).
    • X-Content-Type-Options.
    • X-Frame-Options.
    • X-WebKit-CSP.
    • X-XSS-Protection.

This text has been drawn up in accordance with the guidelines issued by the National Cyber Security Centre (NCSC).