PSIRT
掲載:2019年06月12日
用語集
PSIRTとはProduct Security Incident Response Teamの略称です。自社が製造・販売した製品やサービス、ソリューションなどに存在するセキュリティ上の脆弱性に対応する「体制・機能」を指します。近年はサプライチェーンリスクが叫ばれ、製品やサービスがサイバー攻撃の温床になるとの懸念から、日本国内の企業においても自社製品の安全性と信頼の確保に向け、設置が進んでいます。
PSIRTの設置が進む背景
CSIRTとの違い
PSIRT とCSIRTとの違いは、大まかに以下のように整理することができるでしょう。
カテゴリ | PSIRT | CSIRT |
---|---|---|
守る対象 | 自社製品・サービス | 自社IT環境(例:自社PC、サーバ等) |
インシデント発生時に対象がある場所 | 対処が必要な対象が、ユーザの手元にある場合が多い (例:自社製の電化製品等) |
対処の必要な対象が、自組織で管理できる場合が多い (例:自社PC、サーバ等) |
利用できる情報量 (インシデント対処事例やフレームワーク等) |
独自で開発を進めているため、入手できる情報量がCSIRTに比べ少ない | 扱っている製品が汎用的なため、入手できる情報量がPSIRTに比べ多い |
PSIRTとCISRTでは、そもそも守る対象が異なることが大きな違いでしょう。ただし、セキュリティ関連の情報収集、検知したインシデントの対応、発見された問題の分類・分析、必要に応じた改修作業等、共通する部分も多々あります。
PSIRTの主な機能
PSIRTの機能を表すフレームワークとして、「PSIRT Services Framework 1.0 Draft」があります。これは、PSIRTの体制・機能をサービスエリアとして6つに分類しています。ステークホルダーの管理から、自社製品の脆弱性の発見、トリアージ、修正、開示に加えて、従業員の教育までを一連のサイクルとして定義しています。
【Stakeholder Ecosystem Management (Service Area1)】
ステークホルダーと情報共有するプロセスとメカニズムを確立する
サービス 1.1 | 内部のステークホルダー管理 |
サービス 1.2 | 発見者のコミュニティとの交流 |
サービス 1.3 | コミュニティと組織との交流 |
サービス 1.4 | 下流のステークホルダーマネジメント |
サービス 1.5 | 組織内でのインシデントに関するコミュニケーションの調整 |
サービス 1.6 | 表彰と謝辞による報酬を発見者に伝える |
サービス 1.7 | ステークホルダーメトリクス |
【Vulnerability Discovery (Service Area2)】
製品の脆弱性、脆弱なサードパーティ製品、アーキテクチャ上の弱点について、さまざまな情報源から情報収集するプロセスとメカニズムを確立する
サービス 2.1 | 脆弱性報告の受付 |
サービス 2.2 | 報告されない脆弱性を特定する |
サービス 2.3 | 製品コンポーネントの脆弱性のモニタリング |
サービス 2.4 | 新しい脆弱性を特定する |
サービス 2.5 | 脆弱性発見のメトリクス |
【Vulnerability Triage (Service Area3)】
どのように脆弱性レポートがトリアージされるか定義する
サービス 3.1 | 脆弱性の認定 |
サービス 3.2 | 発見者との関係構築 |
サービス 3.3 | 脆弱性の再現 |
【Vulnerability Remediation (Service Area4)】
サービス対象者にどのプロダクトがサポートされるのか、セキュリティ修正プログラムが提供されるメカニズム
および、提供間隔を教育する
サービス 4.1 | セキュリティパッチリリースマネジメント計画 |
サービス 4.2 | 対策 |
サービス 4.3 | インシデントハンドリング |
サービス 2.4 | 脆弱性リリースメトリクス |
【Vulnerability Disclosure (Service Area5)】
脆弱性情報や対策情報を適切に開示するために、発見者、調整機関、下流ベンダなどと、どのように連携しているかを、ステークホルダーやパートナーが把握できるように透明性を確保する
サービス 5.1 | 通知 |
サービス 5.2 | コーディネーション |
サービス 5.3 | 情報開示 |
サービス 5.4 | 脆弱性情報マネジメントの評価指標 |
【Training & Education (Service Area6)】
各サービスエリアに対応する人員の教育等を行う
サービス 6.1 | PSIRTチームのトレーニング |
サービス 6.2 | 開発チームのトレーニング |
サービス 6.3 | すべてのステークホルダーへの継続的な教育 |
サービス 6.5 | フィードバック機能の提供 |
このフレームワークに基づきPSIRTを構築・運用することが理想ですが、組織によって取り扱う製品や規模等が異なるため、全ての機能を持たせる必要はありません。一部のサービスエリアについて対応し、不足を感じる部分があれば実装に向けて参考とすることも可能です。
例えば、自社製品・サービスの脆弱性を収集する方法として、バグバウンティがあります。これは自社で公開している製品・サービス等に脆弱性がないか外部に自由に調査してもらい、発見した脆弱性の内容に応じて、発見者に報酬が支払われる仕組みです。
この仕組みを導入する場合は、サービスエリア2のVulnerability Discoveryを参考にするとよいでしょう。「サービス 2.1脆弱性報告の受付」では、外部からの受付先を明確にすることに加え、受付方法として、ウェブフォームや公開のチケットシステム、メールサポートホットライン等のチャンネルを検討するように記載があります。多数の脆弱性情報について同時に報告があることに備え、「受理できない」というクレームの発生を避けるためです。
終わりに
我々の身の回りにあるモノのIoT化と、それに伴うサイバー攻撃の多様化により、自組織だけではなく、自組織が作った製品やサービスもサイバー攻撃から守る必要が生まれています。最近のIoT機器は、生体情報や位置情報など個人情報等を収集して、サービスに活用するものも多くあります。反面、セキュリティ面で脆弱性対応が後手にまわる傾向も強く、自社製品やエンドユーザーを守るために、PSIRTを始めとした体制構築が必須となることが予想されます。そして、このような組織を持つことが、企業のマーケティングとしても有効に働く可能性があります。こうした点を踏まえ、自社のサイバーセキュリティを考える上で「どこまでやるか」という選択肢の中に、PSIRT構築を含めることも検討したいところです。