「モノ」を製造していない企業も参考にすべきPSIRTの役割と脆弱性管理のポイント

製品やソフトウェアを提供する企業の脆弱性管理

近年「PSIRT（Product Security Incident Response/Readiness Team）」という、製品やソフトウェアを提供する法人組織内のセキュリティインシデントチームが注目されています。JPCERTによると、PSIRTは、“製品を提供している組織において、製品にセキュリティ上の問題が発見された際に、報告の窓口を努めるとともに、組織内の対策活動を円滑にすすめるための司令塔となる機能”としています。

多くの国内組織^※1では、法人組織のセキュリティインシデント対応を行う役割として、CSIRT（Computer Security Incident Response/Readiness Team）が認識されています。しかし、組織内のシステムインフラに関するセキュリティインシデントと、組織が顧客などに提供する製品やサービスに関するセキュリティインシデントは、性質が異なるため、CSIRTと区別した役割としてPSIRTという概念が登場するようになりました。
※1 日本シーサート協議会の加盟組織は488チーム（2023年1月13日時点）

近年では、顧客ニーズを満たすために、自組織が開発したアプリや会員向けWebサイトを顧客に提供する企業も多くなってきています。PSIRTが担う役割はこのような組織にとって参考になるものです。例えば、PSIRTで求められる役割・機能が改めて注目された事例として、2023年1月4日にCI/CD SaaSサービス(プログラム開発におけるビルド・デプロイメントの自動化を支援するサービス)の米CircleCIが公開した、セキュリティインシデントの報告があります^※2。CircleCIは、インシデント報告とともに、ユーザに対しどのような対応をとるべきか推奨事項の掲載や、本セキュリティインシデントの最終報告レポートを1月14日に公開するなど、スピード感ある対応が注目されました。
本事例では明確にPSIRTが機能したとは謳われていませんが、同様の目的と機能を持った組織が迅速に対応したと推測されます。「モノ」を作っていない組織であってもこうした対応が必要な状況であることは、すべてのモノ・サービスを提供する組織にとって、参考とすべき事例とも言えるでしょう。
※2 CircleCIブログ

本記事では、国際的なCSIRTのフォーラムであるFIRST（Forum of Incident Response and Security Teams）が、PSIRTがその役割を担う際に必要となる機能や資産についてまとめたガイドラインである『PSIRT Services Framework』を参考にし、自社の製品やサービスの品質を向上していくか、また脆弱性が発生した場合などのセキュリティインシデントが発生した場合に備えてどのような管理体制を整備しておかなくてはいけないのかを考察します。

PSIRTに求められること

PSIRTに求められる行動、つまり自組織の製品やサービスの脆弱性に対処するために行う行動としては以下があげられます。

・継続的なプロセスとポリシーの作成：製品セキュリティに関する組織の方針、行動手順を確立
・利害関係者の教育：利害関係者に求められる役割を教育し、方針の実効性を確立
・メトリクスの重要性：評価指標を定め、評価の実施・課題の分析

図1:PSIRTに求められる行動（『PSIRT Services Framework』図General PSIRT Activitiesを参考）

一方で、PSIRTには絶対にこのような要件を揃えなくてはいけないという条件はありません。どのようなミッションを持つか、どのような体制で構築されるかによって、PSIRTに求められる活動内容は変わります。それは、製品やサービスが組織によって異なるように、どのようなミッションを持った組織体制でPSIRTを運用するかは、様々な形があり、同じ業界であっても、組織全体の体制や製品の開発戦略によっても異なってくるからです。そのため、どのような組織にも適用できるフレームワークというものは存在しません。PSIRTに求められる役割は組織の戦略によって異なります。

つまり、PSIRTの存在意義はあくまでビジネスを守るという組織の事業戦略そのものに組み込まれるべきものということです。そのため、PSIRTが作成する製品/サービスのセキュリティポリシーは組織内でレビューされ、権限を伴うかたちで組織内に浸透していなければなりません。また、PSIRTの役割を最大化するためにも、セキュリティポリシーと行動手順に沿った管理システムを組織に構築する必要があります。そのため、PSIRTには、製品やサービスの脆弱性やセキュリティインシデントへの対応のために、組織内部だけではなく、開発に関わった取引先をはじめとしたさまざまな企業・組織・機関との連携も求められます。PSIRTは、製品やサービスを提供するまでに関わる取引先や関係者、そして提供した後に関わる顧客をはじめとする関係者を管理していくという意味では、組織のサプライチェーンセキュリティマネジメントに近しい活動を求められるということなります。

ひと昔前と比べると現在は、組織で採用されているシステムやアプリには、自組織が開発した製品やサービスだけでなく、API（Application Programming Interface）のように他組織が開発したサービスと連携し、利用するシステムの価値を高めていくことが多くなっています。例えば、金融機関と連動する家計簿アプリなどが身近な例としてあげることができます。このように、現代の組織は、サプライチェーンセキュリティマネジメントや実行するための体制作りは求められるようになってきているのです。これは裏を返すと、製品・サービスを顧客に提供する組織でなかったとしても、情報システムを利用する組織であれば、PSIRTの取り組みはサイバーセキュリティを考えるうえで参考になるものです。

PSIRT構築前に実施しておく基本的事項

『PSIRT Services Framework』では、組織がPSIRTを構築し、運用できるようにするために大前提となる、組織が実施しておかなくてはいけない基本的な事項を次のようにあげています。

＜戦略の策定＞
・経営層の支援：組織がPSIRTを確立し運用するための基本的な要素を、計画および実行できるようにする
・ステークホルダ（利害関係者）の特定：PSIRTが誰にサービスを提供し、誰と連携するのかを理解する
・PSIRT憲章の作成：PSIRTが実施する業務の基本的な要素を特定、記述、文書化する
・PSIRTの組織モデルを決定：PSIRTが運営する組織モデルを特定、記述、文書化し、役割や責任を明確にしたチーム構成を作る
・マネジメントとステークホルダ（利害関係者）の支援：PSIRTの効果的な運用を可能にするために、他部門の経営層および利害関係者からの支援の合意を得る

＜戦術の策定＞
・予算の制定：PSIRT運営に必要な資金の調達方法を特定、記述、文書化する
・スタッフの確保：PSIRTメンバーに必要な役割・スキルを特定、記述、文書化する
・リソースとツール：PSIRTが機能するために必要なリソース、機器、ツールの特定と調達を行う

＜運用方針の策定＞
・ポリシーと手順：PSIRTの運用方針と手順の特定、記述、文書化
・評価と改善：PSIRTの改善点を特定できるようにするため、パフォーマンスおよび/または有効性を評価するための指標を定める

PSIRTの領域別目的と求められる成果

加えて、『PSIRT Services Framework』では、PSIRTが達成するべき目的と結果を分類・整理し、全体の構成を理解しやすくするため、6つのサービスエリア（領域）を設定しています。本項では、各領域別にPSIRTが実施すべきこと、考慮しておくべきことの概要を記載します。

＜サービスエリア1　ステークホルダエコシステムマネジメント＞
連携可能なまたは連携しなければならない利害関係者を特定し、対象者と情報共有するプロセスとメカニズムを明確にしておく。このことによって、セキュリティ脆弱性について利害関係者に伝えなければならないときに、タイムリーかつ必要な利害関係者／パートナーに納得のいく報告が行える体制を作る（例えば、報告書の作成タイミングや内容の文書化など）。利害関係者には、経営層、広報、法務、事業部門、開発、営業、サポートなどの内部関係者に加え、脆弱性の発見・報告者、他組織のPSIRT、セキュリティベンダ、バグバウンティベンダ、サードウェア、サプライヤなどの外部関係者があげられる。

＜サービスエリア2　脆弱性の発見＞
自組織の製品/サービスの脆弱性、脆弱なサードパーティ製品、アーキテクチャ上の弱点について、様々な情報源から情報収集するプロセスとメカニズムを確立する。具体的には、利害関係者の製品に関する脆弱性情報に関して、受付窓口を設置し明確にし、かつ報告をしやすい体制を整備するなどがあげられる。加えて、公的機関などから配信される脆弱性情報の監視やペネトレーションテストなどを活用した能動的な脆弱性を検出する体制を確立することも有効。

＜サービスエリア3　脆弱性情報のトリアージと分析＞
どのように脆弱性レポートがトリアージされるか定義する。内部および外部の関係者に脆弱性の取り扱いの透明性を提供できるような、明確な基準と優先順位付け基準を定義する必要がある。一方、脆弱性の判定基準の範囲外であっても、脆弱な状態になりうる条件を検証し理解するため、制限性は確認する必要がある。

＜サービスエリア4　対策＞
顧客及び利害関係者に脆弱性への対応を通知するために必要なプロセスやメカニズムを確立する必要がある。あらかじめ修正プログラムや修正措置および製品・サービスのサポート（製品のライフサイクルポリシーなど）の提供方法、提供間隔を明確に定め、伝えることによって、顧客や利害関係者は事前に自らの予定を計画することができるようになる。

＜サービスエリア5　脆弱性の開示＞
脆弱性が発見された場合に、その情報開示を円滑に進めるためには、自組織内の関係者だけでなく、他組織のPSIRT（中間ベンダとなる公的機関など）、発見・報告者がそれぞれの利害関係者と情報を共有し、透明性の高い協力的な環境を整えることが重要になる。製品・サービスの提供組織は脆弱性情報の情報開示ポリシーを公開し、調整機関や他のベンダ、発見・報告者などが参照できるようにすべきである。

＜サービスエリア6　トレーニングと教育＞
トレーニングと教育のニーズは、組織の中でも異なる可能性があり、例えば、ファームウェア開発者とソフトウェアサービスの開発者の関心は異なり、非常に特殊性の高い独自のトレーニングが必要なこともある。しかしながら、すべての利害関係者に教育をサポートする上でPSIRTは重要な役割を果たすことを意識すべきである。『PSIRT Services Framework』では、PSIRTプロセスに関与する4つの利害関係者グループ、PSIRT、製品開発、製品検証、およびその他の利害関係者に関するトレーニングに分類し、その目的および概要が掲載されている。

図2：PSIRTが目的をもって実施すべき６つの領域（『PSIRT Services Framework』図Organizational Structureを参考）

顧客ニーズを満たすPSIRT

前節までで、『PSIRT Services Framework』に沿って、組織がどのように製品・サービスの脆弱性管理体制の構築や運営を行うべきかを概観してきました。

ややもすると製造物責任の一環として義務のように捉えられがちですが、PSIRTの活動を実施することは、組織の顧客に求められていることを実施することに繋がっているということを忘れてはいけません。

利用できる技術がある程度市場に浸透し、できることが増加している昨今においては、組織が提供する製品やサービスは、新たな機能を次々と開発・提供することが顧客から求められるようになっています。その一方で、製品やサービスの安全性やアクセシビリティを確保することは顧客の絶対条件になりつつあります。この顧客ニーズに適切に応え、顧客から継続的な支持を獲得するためには、この記事で書いたようなPSIRTで求められている活動をひとつひとつ実施していくことが組織に求められています。

まとめ

本記事では、『PSIRT Services Framework』に沿って、製品・サービスを提供する組織が行分ければいけない対策について解説いたしました。特に脆弱性を悪用する攻撃が絶えない近年の状況下においては、組織にとって脆弱性管理は重要な課題と言えます。加えて、ビジネスサプライチェーン攻撃による被害が顕在化してきた昨今において、今後は自組織のサプライチェーンの中に脆弱性な箇所を含めないよう、取引の条件に、脆弱性が発生した際ににどのような対応をするか・体制を整備しているかなどセキュリティへの取り組みの透明性を求められる可能性も想定されます。『PSIRT Services Framework』は、製品・サービスを顧客に提供する組織だけでなく様々な組織に役立たせることのできるガイドラインです。

本情報サイトSecurity GOやトレンドマイクロのセキュリティブログでは、脆弱性を悪用する攻撃などの脅威事例やそれに対する対策を紹介する記事を掲載しています。これらの記事が、組織の脆弱性管理体制を定期的に評価、改善する参考になりますと幸いです。
脆弱性管理については、以下の記事もご覧ください。