Pandora FMS セキュリティ開示ポリシー

Pandora FMS セキュリティチームは、Pandora FMS のセキュリティ問題に対する支援およびアドバイスを提供し、セキュリティ脆弱性の取り扱いに関する調整を行うために存在します。

脆弱性の報告

潜在的なセキュリティ上の脆弱性を見つけた場合、公開する前に、まず私たちに報告いただくことを強くお願いします。

脆弱性やセキュリティ問題を報告するためのメールアドレスは、security@pandorafms.com です。 他の汎用的な連絡先を使用すると、セキュリティ問題を適切に管理できませんので、まだ公開されていない新たなセキュリティ脆弱性を報告する場合は、このアドレスを使用してください。

セキュリティ連絡先は、Pandora FMS の未公開のセキュリティ脆弱性の報告や、そのような脆弱性を修正するプロセスの管理にのみ利用してください。 通常のバグ報告や、セキュリティアーキテクチャに関する質問は、このアドレスでは受け付けません。これらのアドレスに送られたメールのうち、Pandora FMS の未公開のセキュリティ問題に関連しないものはすべて無視されます。

また、セキュリティチームは、Pandora FMS の脆弱性を取り扱うのであり、サポート、コンサルティングサービス、デプロイメント、カスタム機能の開発を提供するものではありません。脆弱性に関するすべての報告は、security@pandorafms.com までお願いします。

報告する脆弱性ごとに1通のプレーンテキストのメールを送信してください。画像、動画、HTML、PDFなどの添付ファイルでお送りいただいた場合は、再提出をお願いすることがあります。一度に複数の問題を含むメールを送らないでください。

暗号化された報告書は、回答に時間がかかるため、必須ではありませんし、望ましいものでもありません。 

セキュリティ問題を報告するには?

以下の情報は、Pandora FMS セキュリティチームの参考になります。

  • セキュリティ上の不具合を確認した日時。
  • 影響を受けた Pandora FMS のバージョン範囲。
  • 報告するセキュリティ上の問題の種類(例:XSS, CSRF, SQLi, RCEi)
  • 影響を受けるコンポーネント(例:コンソール、サーバ、エージェント、API…)
  • スクリーンショット、スクリーンレコーディング、httpトランザクションログ、POCエクスプロイトなど、提供できる詳細情報 (認証されていないファイル共有サービスで証拠を共有したり、機密情報を共有したりしないでください。)
  • 問題が容易に特定できない場合もあるため、問題を再現するための詳細手順。

脆弱性情報

Pandora FMS の脆弱性に関する情報は、通常、リリースノートに記載されています。もし、プロジェクトのウェブサイトで探している情報が見つからない場合は、フォーラムで質問してください。 セキュリティ連絡先は、 次のような問い合わせや状況の場合には利用しないでください。 :

  • パッケージのセキュリティ設定方法。
  • 公開されている脆弱性が、利用している Pandora FMS パッケージの特定のバージョンに当てはまる場合。
  • 公開された脆弱性が、利用している Pandora FMS パッケージの設定に適用されるかどうか。
  • 公開された脆弱性に関する詳細情報の入手。
  • 公開された脆弱性に対処するためのパッチや新しいリリースの有無確認。

脆弱性情報に関する質問をする場所として、パブリックフォーラムがあります。Pandora FMSセキュリティチームに送られた質問は無視されます。

脆弱性の取り扱い

新しいセキュリティ脆弱性を取り扱う典型的なプロセスは以下の通りです。

注意:このプロセスの最後に正式に発表されるまで、その脆弱性に関する情報を公開しないでください。つまり、例えば、この問題を追跡するためにGithubのissueを作成しないでください。また、コミットに関連するメッセージで、そのコミットのセキュリティに関連する内容に一切言及しないでください。

  1. 問題を発見した人(報告者)は、その脆弱性を security@pandorafms.com に非公開で報告します。
  2. Pandora FMS の未公開のセキュリティ脆弱性の報告や管理に関係のないメッセージは無視され、それ以上の対応は必要ありません。
  3. security@pandorafms.com に報告された内容は、セキュリティチームの他のメンバーに報告を(確認せずに)転送します。
  4. プロジェクトチームは、オリジナルの報告者に報告確認メールを送ります。 
  5. プロジェクトチームは報告書を調査し、報告書を却下するか受理します。
  6. 報告書が却下された場合、プロジェクトチームは報告者に理由を説明する書面を送付します。 
  7. 報告が受理された場合、プロジェクトチームは報告者に対して、受理されたことと修正に取り組んでいることを知らせる文書を作成します。
  8. セキュリティチームは、内部のセキュリティ・ケース番号を割り当て、そのセキュリティ・ケース番号に割り当てられた 1 つ以上の開発チケットを作成します。 
  9. セキュリティチームは報告者に CVE 番号を尋ねます。 
  10. プロジェクトチームは報告者に修正プログラムのコピーと脆弱性発表のドラフトを提供し、コメントを求めます。 
  11. セキュリティチームは、修正プログラム、発表内容、リリーススケジュールについて報告者と合意します。報告書にどの程度の詳細情報を含めるかは個々の判断です。一般的には、報告書には、システムの脆弱性に関連するリスクを評価するのに十分な情報が含まれるべきであり、それ以上の情報は含まれません。脆弱性を再現するための手順は通常含まれません。
  12. プロジェクトチームが修正プログラムをコミットし、リリースに含めます。 
  13. プロジェクトチームがリリースを発表します。リリースの発表は、通常のチャネル(ニュースレター、フォーラム、ウェブサイト)で行います。
  14. 有効なサポート契約を結んでいるお客様には、問題が一般に知られる前にアップグレード可能な期間をメールでお知らせします。
  15. 15. プロジェクトチームが、脆弱性を一般に公表します(CVE の更新を含む)。脆弱性の発表は、リリース発表の後に行うべきです。多くの場合、ユーザーや顧客がソフトウェアをアップデートするのに十分な時間を確保するために、修正プログラムのリリースから少なくとも1ヶ月後に公表します。

情報は、プロジェクトのセキュリティチームの判断により、組織内(社内の同僚など)で共有することができます。ただし、情報が一般に公開されるものではないことを明確にし、脆弱性に関する連絡には必ず security@pandorafms.com を含めることを条件とします。