CSIRTは自社のシステムとネットワークの事故に対応するチーム、PSIRTは自社が開発し販売する製品の脆弱性に対応するチームです。守る対象が社内か、出荷した製品かで分かれます。
今日やることは2つです。通信機能のある自社製品とソフトを一覧にしてください。次に、会社のサイトを開き、製品の脆弱性を見つけた人がどこへ連絡すればよいか分かるかを確かめます。分からなければ、それが最初に直す点です。
CSIRTとPSIRTは何が違う？
国際的な団体FIRSTのPSIRT Services Framework 日本語版は、違いを明確に書いています。PSIRTの活動の中心は製品のセキュリティです。組織内CSIRTの活動は、組織のインフラを構成するコンピュータシステムやネットワークに重きを置きます。
| 比べる点 |
CSIRT |
PSIRT |
| 守る対象 |
自社のシステムと網 |
自社が開発し販売する製品 |
| 主な相手 |
社員、取引先、委託先 |
顧客、発見者、調整機関 |
| 起きること |
感染、不正侵入、漏えい |
製品の脆弱性の報告、悪用 |
| 主な仕事 |
隔離、調査、復旧、報告 |
分析、修正、利用者への公表 |
両者は別々に動くわけではありません。FIRSTのCSIRT Services Framework 日本語版は、CSIRTとPSIRTの双方が互いに独立して活動しないと述べています。多くのCSIRTが社内へ出す脆弱性の警告は、ベンダーのPSIRTが提供する情報に基づくからです。
社内の事故に備える話はセキュリティ運用の考え方にまとめています。この記事で扱うのは、製品を外へ出している会社に追加で要る部分です。
製造業ではどう分かれる？
たとえば、ネットワークにつながる検査装置を作っているメーカーの場合で考えます。工場の事務用パソコンがランサムウェアに感染したら、CSIRTの役割です。出荷した検査装置の管理画面に脆弱性があると、外部の研究者から連絡が来たら、PSIRTの役割です。
後者では、自社の工場は無傷でも、顧客の現場が危険にさらされる場合があります。社内の隔離や復旧の手順だけでは答えられません。修正版を作り、どの機種のどの版が影響を受けるかを顧客へ伝える流れが別に要ります。
機械メーカーで通信機能を後から足した製品は、ここが抜けやすいと私たちは見ています。問い合わせは営業か品質保証へ届き、脆弱性の話だと気づかれないまま止まるおそれがあるからです。
製品メーカーに窓口が要るのはなぜ？
報告先が分からなければ、発見者は報告できません。IPAの脆弱性対処に向けた製品開発者向けガイドは、窓口を分かりやすく公開しないと、脆弱性が放置されて悪用されるかもしれないと説明しています。主に中小規模の開発事業者を読者に想定した資料です。
このガイドの対象
IPAのガイドが想定する製品は、主に一般消費者が使うネットワーク機器です。PLCやシーケンサなど、工場やプラントで使う制御機器は対象外と明記されています。産業用の製品を作る会社は、考え方を借りて自社の取引形態に合わせてください。
国内には、脆弱性情報を受け渡す公的な枠組みもあります。情報セキュリティ早期警戒パートナーシップです。発見者はIPAへ届け出て、調整機関のJPCERT/CCが製品開発者へ連絡し、対応を依頼します。
連絡先が分からない会社へも、この連絡は届く可能性があります。受けた側に手順がなければ、そこで慌てることになります。
EUへ製品を出す会社はさらに確かめる
欧州委員会のサイバーレジリエンス法のページによると、この法律は2024年12月10日に発効しました。主な義務は2027年12月11日から、報告義務は2026年9月11日から適用されます。
報告義務の説明では、製造業者は積極的に悪用された脆弱性と、製品のセキュリティに影響する重大なインシデントを届け出ます。期限は次のとおりです。
| 届け出 |
期限 |
| 早期警告 |
把握から24時間以内 |
| 通知 |
把握から72時間以内 |
| 最終報告（脆弱性） |
修正手段の提供から14日以内 |
| 最終報告（重大なインシデント） |
72時間の通知から1か月以内 |
規則の本文は、製造業者に対し、利用者と直接やり取りできる単一の連絡先を指定するよう求めています。協調された脆弱性開示の方針を持つこと、脆弱性の報告先を示すことも、要件に入っています。
輸出は商社任せで、最終的な販売先を把握していない会社もあるでしょう。自社製品が対象か、誰が製造業者の立場になるかは、法律の専門家と確かめてください。
中小メーカーの窓口はどう作る？
FIRSTの枠組みには、ステークホルダ管理、脆弱性の発見、トリアージと分析、修正、開示、教育の6つの領域があります。最初から全部は要りません。製品を出している中小メーカーなら、次の順で形にできます。
1. 製品と版の一覧を作る
製品名、ファームウェアやソフトの版、販売期間、サポートの終了日を1つの表にします。報告が来たとき、対象の機種と顧客をすぐ引けるようにするためです。
組み込んでいる部品やオープンソースも控えます。EUの規則は、製品のソフトウェア部品表の作成を要件に含めています。脆弱性管理ツールの比較で扱う製品は主に社内のIT資産向けなので、製品の部品管理に使えるかは個別に確かめます。
2. 受付の入口を公開する
IPAのガイドは、受付窓口は脆弱性情報専用でなくてよいとしています。受け付けていることが分かるように明示すれば足ります。問い合わせフォームに「製品のセキュリティ」という選択肢を足す形で始められます。
発見者が探しやすいよう、製品ページや製品情報のページからたどれる場所に置きます。ウェブサイトには、RFC 9116で定められた security.txt という書式もあります。/.well-known/security.txt に連絡先と有効期限を書いておくファイルです。
3. JPCERT/CCに窓口を伝える
早期警戒パートナーシップガイドライン2026年版は、製品開発者に対し、JPCERT/CCとやり取りする窓口を設置して連絡するよう求めています。この窓口が製品開発者リストに登録されます。社名をリストで公表するかどうかは、あわせて伝えます。
担当者の個人アドレスにしないでください。異動や退職で届かなくなるからです。部署で受ける共有アドレスにします。
4. 受けてからの流れを決める
ガイドラインの流れに合わせ、次の手順を1枚にします。
- 受信した旨を7日以内に返信する
- 再現できるかを確かめ、影響する機種と版を特定する
- 危険度を判断し、修正か回避策かを決める
- 修正版を作り、顧客への案内文を用意する
- 発見者や調整機関と公表日を調整して公表する
公表日は、JPCERT/CCが最初に連絡を試みた日から45日後が目安です。修正にもっと時間が要るなら、JPCERT/CCへ相談します。夏季休暇や年末年始の時期は、7日以内の返信が難しくなることもガイドラインが触れています。休暇中の受信担当も決めておきます。
5. 役割を3つに分ける
PSIRTの組み方として、FIRSTは分散、集中、ハイブリッドの3つのモデルを挙げています。分散モデルは小さなPSIRTが調整を担い、修正は製品の開発チームが受け持つ形です。
人数の少ない会社では、次の3役を既存の部署に割り当てる形が現実的だと私たちは考えます。
| 役割 |
仕事 |
担当の例 |
| 受付 |
受領の返信、記録、発見者との連絡 |
品質保証 |
| 技術判断 |
再現、影響範囲、修正 |
開発の責任者 |
| 公表判断 |
顧客への案内、公表の決定 |
事業責任者か社長 |
IPAのガイドは、窓口の担当者だけで回答せず、開発部門に確認してから答えるよう周知することを求めています。誤った回答は、利用者の被害と信頼の低下につながるからです。
社内のCSIRTと担当が重なっても構いません。事故の連絡網と体制の描き方は、社員50人の会社を例にしたCSIRTの体制図で示しています。
外の力を借りるなら何を頼む？
分析や修正そのものは製品を知る社内にしかできない部分が多く、外に任せやすいのは体制作りと診断です。手順書の整備はセキュリティコンサル・CSIRT支援の比較で候補を探せます。依頼のときは、社内の情報システムだけでなく製品の脆弱性対応まで支援範囲に入るかを確かめてください。
製品そのものの守りを見直すなら、IoTセキュリティ製品の比較が入口になります。日本にはJC-STARというIoT製品のセキュリティ要件適合評価及びラベリング制度もあります。★1と★2は、基準に沿った自己評価のチェックリストに基づく仕組みです。
報告が来たとき、やってはいけないことは？
発見者への対応を誤ると、解決が遠のきます。IPAのガイドと枠組みの考え方に沿うと、避けたいのは次の3つです。
- 製品の担当が分からず、返事をしないまま放置する
- 調べる前に「問題ありません」と答える
- 公表の条件を確かめずに、社内の判断だけで公表する
FIRSTの枠組みは、PSIRTは発見者や報告組織が示した公開条件を尊重するべきとしています。発見者は敵ではなく、問題を先に知らせてくれた相手です。社内で報告の扱いをどう定義するかは、インシデントの定義と報告の決め方が参考になります。
