情シス／社内CSIRT向け｜PSIRTとの切り分けと連携設計

結論：CSIRTは社内IT、PSIRTは製品

FIRSTのPSIRT Services Frameworkは、PSIRTの主な差別化要素は製品に焦点を当てることだと説明しています。一般的なEnterprise CSIRTは、組織のインフラを構成するコンピュータシステムやネットワークのセキュリティに焦点を当てます。

一方で、PSIRTとCSIRTには重要な違いがあるものの相乗効果もあり、PSIRTは組織内の他部門から独立して動くものではありません。切り分けの基本は次の通りです。

領域	主担当	典型的な対象
社内PC・サーバ・ネットワークの侵害	情シス／社内CSIRT	マルウェア感染、アカウント侵害、不正アクセス、社内ネットワーク障害
工場・社内システムの停止や復旧	情シス／社内CSIRT	生産管理、ファイルサーバ、VPN、認証基盤、バックアップ
納入製品の脆弱性対応	PSIRT	ECU、ファームウェア、組込みソフト、診断ツール、製品付属アプリ
SBOM・CVE・VEX・製品影響回答	PSIRT	製品構成、依存ライブラリ、影響有無、修正予定、回避策
顧客・OEMへの製品セキュリティ説明	PSIRT中心、品質保証・営業連携	影響回答、暫定対策、是正計画、証跡提出

この表だけ見ると単純ですが、実務では境界が重なります。たとえば社内開発サーバが侵害され、製品ソースコードやビルド成果物に影響する可能性がある場合、初動はCSIRTでも、納入済み製品への影響判断はPSIRTが必要です。

CSIRTが主導すべき案件

情シス／社内CSIRTが主導すべきなのは、社内の情報システム、業務継続、インフラ防御に関わる案件です。

社内PCやサーバのマルウェア感染
VPNや認証基盤への不正アクセス
メールアカウント乗っ取り
社内ファイルサーバからの情報漏えい
工場ネットワークや業務システムの停止
バックアップ、復旧、ログ保全、端末隔離
SOC/SIEM、EDR、ファイアウォール、ID管理の運用

これらは、会社のIT環境を守るためのインシデント対応です。CSIRT側が一次対応、封じ込め、復旧、ログ保全、社内報告を担い、必要に応じてPSIRTへ「製品影響の可能性あり」と連携する形が適切です。

PSIRTが主導すべき案件

PSIRTが主導すべきなのは、納入済みまたは納入予定の製品に関わる脆弱性対応です。

OEMからCVE影響有無の確認が来た
SBOM提出や更新版SBOMの提出を求められた
上流ベンダーから製品搭載部品に関する脆弱性通知が来た
オープンソースライブラリの脆弱性が製品に影響する可能性がある
研究者や顧客から製品脆弱性の報告が来た
製品ファームウェア、通信機能、診断機能に関する脆弱性が疑われる
OEMへ暫定対策、修正予定、影響なし根拠を説明する必要がある

FIRSTのPSIRT Frameworkでは、PSIRTが扱う製品コンポーネントの脆弱性には、自社ソースコード、社内由来コンポーネント、外部由来コンポーネントが含まれると整理されています。PSIRTは単なる問い合わせ窓口ではなく、製品一覧、SBOM、サポート対象バージョン、技術判断、顧客回答、是正計画をつなぐ役割です。

連携が必要になる5つの場面

1. 社内侵害が製品へ影響する可能性がある場合

開発端末、ソースコード管理、ビルドサーバ、署名鍵、成果物保管場所が侵害された可能性がある場合、CSIRTだけでは完結しません。CSIRTは侵害範囲、ログ、封じ込め、復旧を担当し、PSIRTは納入済み製品、出荷予定品、顧客説明、是正要否を判断します。

2. 製品脆弱性の調査に社内ログや環境確認が必要な場合

OEMから製品脆弱性の照会が来た場合でも、開発環境、ソース管理、CI/CD、脆弱性スキャン結果、SBOM生成履歴の確認が必要になることがあります。このときはPSIRTが顧客回答を主導し、CSIRTまたは情シスが社内システム上の証跡確認を支援します。

3. SBOM、CSAF/VEX、脆弱性管理基盤をつなぐ場合

SBOM、CSAF、VEXは、顧客の透明性、リスク判断、脆弱性管理の優先順位付けに役立ちます。この領域では、PSIRTが製品影響や顧客回答を持ち、情シスがツール、認証、権限、ログ、保管基盤を支える分担が現実的です。

4. 脆弱性情報の監視ソースを共有する場合

社内CSIRTが見ている脆弱性情報、脅威情報、EDR/SIEMアラート、外部フィードの中に、製品部品に関わる情報が混ざることがあります。CSIRTがすべてをPSIRTへ転送するのではなく、製品対象の可能性がある情報だけを渡すルールが必要です。

5. 経営報告・OEM報告が同時に必要な場合

大きなインシデントでは、経営報告とOEM報告が同時に必要になります。社内IT被害の説明はCSIRT、製品影響の説明はPSIRT、取引先への正式説明は品質保証や営業、法的表現は法務が関わります。

RACIで切ると揉めにくい

CSIRTとPSIRTの境界は、文章だけでなくRACIで決めると運用しやすくなります。Rは実行責任、Aは最終説明責任、Cは相談先、Iは共有先です。

業務	情シス/CSIRT	PSIRT	品質保証	設計/開発	経営/部長
社内IT侵害の初動	R	C	I	I	A
ログ保全・端末隔離	R	I	I	C	A
製品脆弱性の受付	C	R	C	I	A
製品影響判断	C	R	C	R	A
SBOM提出管理	C	R	R	C	A
OEM向け回答作成	I	R	R	C	A
顧客提出前の承認	I	C	R	C	A
社内IT復旧報告	R	I	I	I	A
製品是正計画	C	R	C	R	A

この表で重要なのは、CSIRTをPSIRTの下請けにしないこと、PSIRTを情シスの延長にしないことです。それぞれの専門性を分けたうえで、接点だけを設計します。

よくある失敗

すべてのセキュリティ問い合わせを情シスに集めてしまう

情シスは社内ITには強くても、製品の対象バージョン、サポート期限、搭載ライブラリ、顧客別仕様までは判断できません。その結果、OEM回答が遅れます。

PSIRTが社内ITの証跡にアクセスできない

調査のたびに情シスへ個別依頼する状態では、連携ではなく都度調整になります。重大案件で必要なログや基盤情報を、案件IDで相互参照できる設計が必要です。

顧客回答と社内報告の内容がずれる

CSIRTが「社内影響なし」と言っていても、PSIRT側では「製品影響は調査中」ということがあります。これは矛盾ではなく、社内IT影響と製品影響が別軸だからです。

最小限決めるべき連携ルール

中小サプライヤーなら、最初から大きな合同組織を作る必要はありません。まずは次の5つを決めれば十分です。

一次受付の振り分け基準：社内IT障害・侵害はCSIRT、納入製品・SBOM・CVE・OEM照会はPSIRTに振り分けます。
相互エスカレーション条件：社内侵害が開発環境や製品成果物に関わる場合はCSIRTからPSIRTへ、製品脆弱性調査で社内ログ確認が必要な場合はPSIRTからCSIRTへ渡します。
証跡の置き場：CSIRT側のログ保全記録と、PSIRT側の製品影響判断・顧客回答履歴は別管理でも構いません。ただし、重大案件では相互参照できる案件IDを持つべきです。
対外回答の承認者：社内IT被害の説明と、製品影響の説明は分けて承認します。OEMへ出す回答は、PSIRT、品質保証、必要に応じて設計・経営が承認します。
月次レビュー：CSIRTとPSIRTが月1回だけでも、製品影響の可能性があった社内インシデント、CVE照会、SBOM提出、回答遅延を見直すと、境界の抜け漏れが減ります。

まとめ

情シス／社内CSIRTとPSIRTの違いは、単純に言えばこうです。

CSIRTは社内ITを守る。PSIRTは顧客に納める製品を守る。

ただし、実務では完全に分離できません。開発環境、SBOM、脆弱性情報、ログ、顧客回答、経営報告が交差するためです。

最初にやるべきことは、大きな組織再編ではありません。社内ITインシデント、製品脆弱性、SBOM/CVE照会、OEM回答、開発環境侵害の5場面について、誰が主導し、誰に相談し、誰が承認するかを決めることです。

情シス／社内CSIRT向け：
PSIRTとの切り分けと連携設計