PSIRT Services Framework
Version 1.0 Draft 日本語抄訳
日本語抄訳はSoftware ISAC(一般社団法人コンピュータソフトウェア協会)と一般社団法人JPCERTコーディネーションセンターによって翻訳された後、Panasonic PSIRTとSony PSIRTによってレビューされました。FIRST.Orgは関係者の協力に深く感謝します。
1
はじめに
製品セキュリティインシデント対応チーム（PSIRT）は、組織が開発?販売する製品、ソリューション、コンポーネント、サービスなどの、脆弱性リスクの特定や評価、対処に焦点を当てた組織内のエンティティである。
適切に設置された PSIRT は、製品開発から切り離された独立したグループではなく、むしろ、組織における幅広いセキュアなエンジニアリングを主導する一部として存在するものである。このような構成をとることによって、セキュリティ品質保証に関する活動を「セキュア開発ライフサイクル（SDL）」のなかに統合することができる。
製品のセキュリティインシデント対応は、多くの場合、SDLのメンテナンス段階と位置づけられている。これは、製品の脆弱性の多くが報告されるのが、製品やサービスが市場に提供された後だからである。しかしPSIRTの活動は、製品の構造、設計、計画、リスクモデリングフェーズの早期の要件収集の段階にも働きかけることができる。
PSIRTとCSIRTの違い
PSIRTが組織内CSIRT等と異なる点は、その活動の中心が製品のセキュリティである、ということである。一般に組織内CSIRTの活動は、組織のインフラを構成するコンピュータシステムやネットワークのセキュリティに重きを置いている。
組織内CSIRTとPSIRTには重要な違いがあるが、両者の間の相乗効果を認識しておくことも重要である。PSIRTは、組織の他の部分から独立して機能するものではない。このフレームワークでは、PSIRTの活動において推進すべきコラボレーションと相乗効果（シナジー）に焦点を当てる。
PSIRTの組織構造
2
PSIRTの組織構造は、守る製品が多種多様であるのと同じようにさまざまな形がある。同じ分野や同じ業界内であっても、ビジネス特性や運用モデル、製品ポートフォリオ、組織全体の構造、および製品開発戦略の違いなどがあるだろう。結果として、どんな組織にも適用できる単一の製品セキュリティインシデント対応戦略やチームテンプレートは存在しない。ただし、現在構築?運用されているPSIRTのほとんどは、分散モデル、集中モデル、ハイブリッドモデルという3つのモデルのいずれかにあてはまるだろう。
分散モデル
分散モデルでは、PSIRT自体はごく小規模な組織であり、製品開発チームの代表者と協力して脆弱性に対処する。このモデルでは、PSIRTは以下のような役割を持つ:
3
? 脆弱性対応において、解決策?緩和策?その他アドバイザリに関する情報の取り扱いや、
トリアージ?分析?対策作成?コミュニケーションなどの活動に関するポリシー?プロセス手順?ガイドラインを作成する。
? 組織全体を通して、製品セキュリティエンジニアリング担当者の（階層化された）マト
リクスを確立する。
? 製品の脆弱性対応と潜在的なビジネスリスクについて、リーダーシップを発揮したり、
助言したりする。
? 組織のなかで外部から寄せられる脆弱性情報の集中管理を行う部署として機能するこ
とで、スケールメリットをもたらす。
? 新しい脆弱性をセキュリティエンジニアの代表者に通知し、修正対応などの計画作成
を支援し、修正や緩和策の草案作成や公表を行う。さらに、インシデント管理を行う。
組織の規模が大きく、多様な製品ポートフォリオを持つ組織は、PSIRTのコストが全体に分散されるため、分散モデルの恩恵を受けることができる。また、このモデルでは、製品開
4
発チームの熟練者をPSIRTの活動に巻き込むことで、PSIRTの活動拡大に対応できる。 一方、分散モデルの課題は、脆弱性のトリアージや修正プログラム提供の担当者がPSIRTの直接の管理下にないことや、PSIRTに報告を行わない可能性があることである。
集中モデル
集中モデルは多くのスタッフを抱えるPSIRTのモデルであり、各部門から選抜されたスタッフが組織の製品セキュリティを担当する上級幹部に報告する。このモデルは次のような構造を持ち得る。
? PSIRTプログラム管理部門：セキュリティ脆弱性のトリアージ、分析、緩和、修復、コ
ミュニケーションのためのポリシー、プロセス手順、ガイドラインを作成する。また全体的なPSIRTイニシアティブ活動やチケッティングシステムを管理し、組織においてPSIRTのリーダーシップを示す。
? セキュリティインテリジェンスとトリアージ：脆弱性に関するさまざまな外部ソース
を監視する。組織の製品ポートフォリオに対する脆弱性の影響を初期評価する。 ? 対策とコミュニケーション：製品のエンジニアリングチームに脆弱性に対する修正を
直接提供する。
5