「PSIRT徹底解説」製品セキュリティ統括組織PSIRTの全貌を解き明かす：まず備えたいPSIRTの機能（その２：取り組み運用編）

製品に利用されているHW/SWコンポーネント管理

本連載の第3回において、脆弱性情報を入手した際には「自社の製品に該当するのかを確認し、対応を要する脆弱性情報かどうかを見極める」という該非確認のステップを踏むことの必要性について説明しました。この該非確認を行うためには、市場に展開されている自社の製品を構成する正確なコンポーネントリストを手元に用意しておく必要があります。脆弱性情報を受け取ってから、「この情報は自社製品に該当するのか」と調査しているようでは、大量に報告される新たな脆弱性情報をさばくことはできません。

公開される脆弱性情報の多くはOSS¹に関係するものが多いため、近年はSBOM²の整備の重要性が話題に上がりますが、実はそれだけではなく、無線チップや映像処理チップなどのハードウェアチップに関係する脆弱性も多く報告されています。そのため、ソフトウェアだけでなくハードウェア部品のBOM³についても今一度確認するとよいでしょう。

社内外関係者との関係構築と連絡先明確化

PSIRTがいくら頑張っても、社内外の関係者の協力なしに適切な製品の脆弱性対応は行えません。連載の第2回で紹介したように、組織内部の関係者および社外の関係者の連絡先を整備し、脆弱性対応の必要性が出てきた際に備えましょう。製品の脆弱性を修正し、事前の調整を図った上で、適切なタイミングで修正パッチや脆弱性対応に関する情報を顧客へ提供していくために協力を仰ぐ必要のあるメンバーを明確化します。同時にそのメンバーとは、どのような内容について連絡を取り合うかも事前に合意しておき、常に連絡の取れる関係性を構築しておくことが重要となります。なお、各組織のメンバーは異動などにより入れ替わるものなので、定期的に連絡先を保守しておくことも重要となります。

製品の担当窓口の連絡先を明確化することは特に重要です。できれば事業部単位ごとに窓口担当者を用意し、PSIRT側からの連絡に迷うことがないようにしておくとよいでしょう。製品側の窓口担当者は、開発部門の方でもよいですし、品質保証部門の方でもよいです。双方に連絡担当者を設置できると理想的です。

また、脆弱性情報はPSIRT以外に直接持ち込まれることも想定されますので、直接受領した部門から当該情報を即座にPSIRTと共有してもらうといった取り決めをしておくことも重要です。

社内外の連絡窓口担当者との関係を維持するために、PSIRTから製品セキュリティに関する話題を積極的に提供するという方法が挙げられます。仮に担当者がセキュリティに詳しくない場合、具体的な脆弱性情報がないと、担当窓口としての意識も薄れてしまいます。それを防ぐためにも、できるだけ頻繁に脆弱性情報やセキュリティのトピックを投げかけることが重要になります。結果としてセキュリティへの興味も増すかもしれませんし、セキュリティ用語に慣れてもらうことも期待できます。

社内にCSIRT⁴がある場合には、CSIRTとの協力関係、PSIRTの役割分担を明確にしておくことも大事です。インシデントが起きた場合に、CSIRTとPSIRTのどちらが対応すべき領域か双方判断できず、結果的に誰も対応しないということが起こらないように、役割分担を定めておくことが肝要です。一例として、顧客がユーザとなる製品やサービスはPSIRT、社員がユーザとなる社内インフラはCSIRTといった役割分担が考えられます。そのようなケースであっても、顧客向けクラウドサービスを展開しているとき、その運用バックエンドシステムは社員がユーザであってもPSIRTの管轄にするのか、ユーザは社員なのでCSIRTの管轄にするのか、といった判断に迷う場合が生じる可能性があるので、事前に両者で対応ルールを決めておきましょう。

標準的なインシデント対応プロセスの明確化

基本的なインシデント対応の手順を明確化しておきましょう。手順書として明文化することで、実施すべきことを忘れず、漏らさず、一定のプロセスに則ってインシデントに対応することができます。また、PSIRTのメンバーが異動などにより変更になった際も、一連の流れを文書で理解することができるため、引継ぎもスムーズにできます。

脆弱性の深刻度や脆弱性報告者の要求によって、臨機応変に対応することが求められますが、以下の基本的なインシデント対応プロセスを押さえた手順書を作成することで抜け漏れなく対応することができます。また、インシデント対応の取り組み範囲が拡大したり、取り組みが高度化したりするにしたがって、内容を拡充することが求められます。

1. 脆弱性報告の受付／脆弱性情報の受領
2. 脆弱性情報の該非の確認と深刻度評価
3. 製品開発もしくは品質保証部門での対処方針の決定
   　改修する場合：不具合改修プロセスへ
   　次期対応とする場合：申し送り事項に登録
4. リリース調整
   　リリースの日程、内容、方法、手順について関係者と合意形成
   　監督官庁やJPCERT/CCへ事前報告
5. リリース後
   　社内報告、インシデント対応事例管理

インシデント対応の訓練

整備したインシデント対応プロセスを実践できるよう、関係者を交えて定期的に訓練を行いましょう。実際に受領した脆弱性情報を事例にしたシナリオでもよいですし、仮想的な脆弱性情報でもよいです。できるだけ、多くの関係者が参加できるよう、複数のシナリオを用意するとよいでしょう。

脆弱性情報の管理

確認された脆弱性情報が製品の開発部門や品質保証部門に伝達された後、伝達を受けた部門にて適切に対処されているか把握し、管理できる環境を整備しましょう。脆弱性の深刻度などによっては、次期バージョン対応として即改修を行わないケースもあります。適切に対処が完了していない場合は、改修が完了するまで追跡し、対処の方向性に行き詰まっていたら、対処方針を一緒に検討するなど、対処の完了まで支援しましょう。

また、将来の製品が同じ脆弱性を作りこむことがないよう、対処した脆弱性情報とその対象コンポーネントについては、過去トラブル情報として管理する必要があります。同じコンポーネントを搭載している製品が複数ある場合は、それぞれの製品の窓口担当者に情報を横展開するようにしましょう。