PANDORA FMS DISCLOSURE POLICY
Providing coordination of the handling of security vulnerabilities

Pandora FMS

Reporting a vulnerability

 

We strongly encourage the reporting of potential security vulnerabilities to us first, before disclosing them in a public forum.

The main email address to report any vulnerability or security issue is [email protected]. Usage of other general-purpose addresses of contact will not render a proper management of security issues, please use this address for  undisclosed security vulnerability to report.

Please note that the security contacts should only be used for reporting undisclosed security vulnerabilities in Pandora FMS  and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or questions about security architecture at this addresses. All mail sent to these addresses that does not relate to an undisclosed security problem in Pandora FMS will be ignored.

Also note that the security team handles vulnerabilities in Pandora FMS, not provide support, consulting services, deployment or develop custom features. All reports of vulnerabilities should be sent to [email protected] only.Please send one plain-text email for each vulnerability you are reporting. We may ask you to resubmit your report if you send it as an image, movie, HTML, or PDF attachment when it could just as easily be described with plain text. Please do not send a single mail containing several issues at once.

Encrypted submissions are not required or preferred as it will take us much longer to respond to these reports.

How to report a security issue?

 

The following information will be helpful for Pandora FMS Security team:

  • Date and time when you identified the security defect.
  • Affected Pandora FMS version range.
  • Type of security issue you are reporting, e.g.: XSS, CSRF, SQLi, RCE.
  • Affected components, e.g.: Console, Server, Agent, API…
  • Any details you can provide, e.g. screenshots, screen recordings, http(s) transaction logs, POC exploits (please do not share any evidence via unauthenticated file sharing services and avoid sharing sensitive information.
  • Step by step instructions to reproduce the issue as the problem might not be easily identifiable.

Vulnerability information

 

Information on the published vulnerabilities for Pandora FMS can usually be found on the release notes. If you can’t find the information you are looking for on the project’s web site, you should ask your question on the forums. The security contacts should not be used to ask questions about

  • How to configure the package securely;
  • If a published vulnerability applies to specific versions of the Pandora FMS packages you are using;
  • If a published vulnerability applies to the configuration of the Pandora FMS packages you are using;
  • Obtaining further information on a published vulnerability;
  • The availability of patches and/or new releases to address a published vulnerability.

Our public forums are the place to ask such questions. Any such questions sent to the Pandora FMS Security Team will be ignored.

Vulnerability handling

 

A typical process for handling a new security vulnerability is as follows:

Note: No information should be made public about the vulnerability until it is formally announced at the end of this process. That means, for example that a Github issue must NOT be created to track the issue since that will make the issue public. Also the messages associated with any commits should not make ANY reference to the security nature of the commit.

  • The person discovering the issue, the reporter, reports the vulnerability privately to [email protected].
  • Messages that do not relate to the reporting or managing of an undisclosed security vulnerability in Pandora FMS are ignored and no further action is required.
  • If reported to [email protected], the security team will forward the report (without acknowledging it) to other members of the security team.
  • The project team sends an e-mail to the original reporter to acknowledge the report.
  • The project team investigates the report and either rejects it or accepts it.
  • If the report is rejected, the project team writes to the reporter to explain why.
  • If the report is accepted, the project team writes a report to let them know it is accepted and that they are working on a fix.
  • The security team will assign an internal security case number and one or more development tickets assigned to the security case number.
  • The security team will assign the reporter for a CVE number. Pandora FMS is now a CVE CNA.
  • The project team provides the reporter with a copy of the fix and a draft vulnerability announcement for comment.
  • The security team agrees with the fix, the announcement and the release schedule with the reporter. The level of detail to include in the report is a matter of judgement. Generally, reports should contain enough information to enable people to assess the risk associated with the vulnerability for their system and no more.
  • Steps to reproduce the vulnerability are not normally included.
  • The project team commits the fix and includes it in a release.
  • The project team announces the release. The release announcement should be sent to the usual channels (newsletter, forums, website).
  • Clients with valid support agreements are emailed giving a period of time when it is possible to upgrade before the issue becomes known to the public.
  • The project team announces the vulnerability to the public (including CVE update). The vulnerability announcement should be sent AFTER the release announcement. Most times the public notice is at least ONE MONTH later the release of the fix, to give enough time to users and customers to update the software.

Information may be shared with domain experts (e.g. colleagues at your employer) at the discretion of the project’s security team providing that it is made clear that the information is not for public disclosure and that [email protected] must be copied on any communication regarding the vulnerability.