Why do you ask if it is merely a misconfiguration?

The misconfiguration of an IT system does not necessarily constitute a vulnerability within the context of the CVD procedure and therefore does not lead to the initiation of a CVD procedure. An example of a misconfiguration of an IT system, which is not a vulnerability in the sense of the CVD procedure, is, for example, a misconfiguration of the web server that allows the listing of directories.

For example, if the URL https://intern.behörde.bund[.]de/Ressourcen can be accessed from the Internet, it is a misconfigured web server and/or DNS record. A vulnerability in the system/web application was not exploited or was not needed to access the resources.

A CVD procedure would be initiated if, for example, a cross-site request-forgery (CSRF) was used to call the internal resources on the web application. In such a procedure, a software vulnerability exists in the web application, which is why the report can qualify for processing in the CVD procedure.

Why do you ask if a patch exists?

For the purposes of the CVD process, a report must contain a previously unknown vulnerability. For already fixed vulnerabilities (for which patches or mitigation measures exist), your information is received, checked and passed on to the competent body, but they do not qualify for further processing in the context of the CVD process.

A typical example are unverified vulnerability discoveries that are based exclusively on version numbers, because security updates can also be included in earlier versions (backports), especially with large distributions. However, these are not reflected in the server tag. Without verification, false-positive findings can therefore occur particularly frequently with large distributions such as Debian, exim, postfix, Apache or sshd.

Why is it important if a PoC is publicly known?

For the purposes of the CVD process, a report must contain a previously unknown vulnerability. Vulnerabilities that can already be exploited by public PoCs have already been published (fully) and can no longer be forwarded to the manufacturer/product manager in the sense of the coordinated vulnerability process.

If the manufacturer or those responsible for the product do not respond to your vulnerability report or there is a risk that the CVD process may be unsuccessfull, security researchers can contact the BSI (see the question "Why the BSI CVD process?").

Vulnerabilities affecting federal products or web applications can and should be reported to the BSI in any case. As the national cyber security authority of the federal government, the reported vulnerabilities are processed according to the CVD process, passed on to the responsible manufacturers or product managers and the goal is to remedy the vulnerabilities.

The CVD process of the BSI offers security researchers the opportunity to involve the BSI as a mediating party in CVD processes that are in danger of failing. In this way, the BSI can contribute to a de-escalation between manufacturers and security researchers with the goal of eliminating vulnerabilities as quickly as possible. In addition, the BSI can arrange contacts with manufacturers and, in its function as a coordinator, support inexperienced parties in the CVD process.

CERT-Bund tries to react promptly to every vulnerability report, to give an assessment within the scope of our resources, and to outline the further procedure.

Security researchers can independently set a reasonable deadline by which affected manufacturers should have fixed vulnerabilities. This period should be within the internationally customary 45 to 90 days. However, depending on the criticality and complexity of a vulnerability, the corresponding period can be shortened or extended in consultation with the security researcher. For hardware vulnerabilities, the deadline can differ significantly. Any deviations that become necessary must be justified by the security researchers or manufacturers and clarified as part of the coordination process. An extension of the maximum period must be carried out in consultation with security researchers. If the security researchers have also set a deadline, the manufacturer must be informed of this when the BSI contacts them.

Here individual decisions are often necessary; in all cases, CERT-Bund coordinates closely with all parties involved in order to develop the best possible solution.

If the process fails, the BSI examines possible further steps in accordance with its statutory mandate. For example, the BSI can continue to use the knowledge gained from the CVD process to fulfil the legal tasks without further involvement of the manufacturer, share it with other bodies in a suitable manner and publish short-term warnings if necessary. These decisions are generally discussed with the security researchers and further joint action is closely coordinated.

Depending on the criticality and the need for a timely response, the BSI checks whether advance information with further information needs to be distributed to the target groups of the BSI in accordance with the statutory mandate.

The CERT-Bund offers security researchers the option of specifying a PGP key using the vulnerability report form. This is then used for encrypted communication with the security researchers. Therefore, the CERT-Bund currently does not offer any EE2E messengers for reports of vulnerabilities. We continue to evaluate additional reporting options (besides the reporting form and email) for security researchers.

The referencing (name, alias, etc.) usually takes place shortly after the successful completion of the CVD process. Security researchers will be informed about successful introduction to the Hall of Fame.

The BSI currently does not offer security researchers any financial compensation as part of a CVD process that has been carried out.

Vulnerabilities that were reported before the publication date of the CVD guideline are not eligible to be recognized retroactively.