「PSIRT徹底解説」製品セキュリティ統括組織PSIRTの全貌を解き明かす：まず備えたいPSIRTの機能（その１：脆弱性対応編）

PSIRTが備えるべき機能

脆弱性対応におけるそれぞれの取り組みを解説するとともに、PSIRTが備えるべき機能について実務的な視点から紹介します。

a. セキュリティに関する脆弱性報告の受付と情報提供者の確認

PSIRTには、提供する製品やサービスに関する脆弱性報告をいつでも受け付けられる対外的な受付窓口を用意し、待機することが求められます。報告を受け付ける際には、脆弱性問題の収束まで脆弱性報告者と連絡が取れるように、身元と連絡先を確認するようにします。

受付窓口機能

脆弱性対応に係る一連の取り組みの入り口として、受付窓口は最も重要な機能となるので、まずこの機能を用意しましょう。受付用の電子メールアドレスを公開し、報告用ウェブフォームを準備するなどしても良いでしょう。

ただ、脆弱性情報はどこに寄せられるかわかりません。ユーザサポートや営業など外部と接点のある部門と連携し、セキュリティに関連する可能性のある内容の場合は、PSIRTと情報共有するようにしておく必要があります。海外の営業窓口に脆弱性情報が寄せられたとしても、その内容を理解できずに放置してしまうと、対処前の脆弱性情報が開示され、大きくブランドの評判を落としてしまう可能性もあります。

また、受付窓口で脆弱性報告を待っているだけでは、脆弱性情報を得る機会は限られてしまいます。そこで、脆弱性情報を扱う組織の情報提供サービスへ登録し（例えば、JPCERT/CCの製品開発者の登録^[1]）、脆弱性情報の入手先を広げましょう。

b. 受領した情報の該非の確認（脆弱性の認定）

入手した脆弱性情報が、自社の製品に該当するのか、報告者の指摘内容のとおりに製品に問題が発現するか、などの確認を行い、脆弱性情報の該非の確認を行います。

該非確認を行うための２つのポイントをご紹介します。

コンポーネント情報：BOM/SBOM

一般に展開された脆弱性情報が自社の製品に該当するかどうかの該非判断を行うには、自社の製品に搭載されるハードウェアやソフトウェアのコンポーネントの台帳が必要です。ハードウェアの場合は、多くの企業では製品のBOM²（部品構成表）が整備されていますが、ソフトウェアの場合、部品表の形で管理されていないケースが多いです。ただ、多くの企業においてOSS³ライセンス管理用の台帳は、知的財産部門や法務部門で管理されています。そこで、このOSS管理台帳を活用して、展開された脆弱性情報が製品に該当するかをまず確認できるようにし、搭載するOSSの範囲から製品のSBOM⁴（ソフトウェアの部品構成表）を整備しましょう。詳しくは連載の第4回で解説します。

セキュリティ技術者の育成

製品固有の脆弱性として報告された情報は、脆弱性報告者の指摘内容どおりの問題が発現するか、発現手順や条件などを社内で詳しく確認する必要があります。そのために、脆弱性報告の内容やセキュリティ用語を理解し、指摘された問題を再現できるセキュリティ技術者を少なくとも1名は育成できるとよいでしょう。やや難易度の高い対応ですが、組込み製品の開発技術者でデバッグが得意であれば、技術習得は早いと言われています。

c. 製品開発部門／品証部門への対応要否判断要請

自社製品に該当する脆弱性情報を開発部門や品質保証部門に展開した後、PSIRTは一定の期限を決めて改修対応要否の判断を要請します。

対応要否判断基準の事前制定

製品の開発部門は、心情的に一度リリースした製品を改修することに抵抗感があったり、事業部側も改修コストの掛かる対応を渋ったりすることもあると思います。改修対応の要否判断に時間を要することがないよう、脆弱性のCVSS評価値による深刻度や事業リスクレベルによる対応要否判断基準を設けておくとよいでしょう。

d. 製品開発部門による対策設計（脆弱性の修正）

製品を改修すべきと判断された場合は、製品開発部門が改修設計を行います。サプライヤの提供するコンポーネントに脆弱性がある場合は、サプライヤに改修を要請します。特別なプロセスは必要なく、既存の不具合改修プロセスと同様の対応で問題ありません。

深刻度やリスクが低いことから次機種にて対応すると判断する場合は、脆弱性を抱えた製品を安全に利用いただくための運用回避策などをユーザに提供すべきです。

e. 対策効果検証／リリース判断

対策版や運用回避策に対し、その効果検証（脆弱性の解消、別の脆弱性の有無）を品質保証部門と最終確認し、リリース判断を仰ぎます。ここも特別なプロセスの必要はなく、既存のリリース判断プロセスと同様の対応で問題ありません。

第三者による効果検証

脆弱性が解消されたかどうかを確認するにあたっては、自社内の技術では評価しきれない可能性もあります。そのため、改修効果を第三者の専門的な視点から検証できる事業者とのつながりを持っておくとよいでしょう。

f. 対策版の公開調整／脆弱性情報の開示・リリース

情報のリリースにあたっては、製品の営業や顧客サポート、広報、法務などの社内の関係部門で連携して対応します。また、脆弱性報告者やその他外部の関係者とも、リリースの内容を調整します。重大なリスクにつながる可能性のある脆弱性については監督官庁への報告が必要であり、リリースの公表前に報告を済ませておく必要があります。このリリースにより、ユーザに対策版が届けられて案件は対処完了として管理されます。

関係者リストの整備

脆弱性情報の管理や、関係者間での情報共有とその改修のリリース日は、関係者間で認識を合わせながら対応する必要があります。脆弱性対応の際に連携・協力が必要な社内外の関係者の連絡先リストは事前に整備しておきましょう。詳しくは第4回で解説します。