なぜCSIRTは「作っても機能しない」のか｜構築でつまずく5つのポイントと対策

CSIRTは「作ること」より「機能させること」が難しい

CSIRTは、組織図に置けば機能するものではありません。有事に誰も動けない『形だけのCSIRT』は珍しくないからです。本記事では、CSIRT構築が「作っても機能しない」状態に陥る原因を5つのつまずきポイントに構造化し、それぞれの対策を整理します。

サイバー攻撃の高度化と、インシデント対応への社会的要請の高まりを背景に、CSIRT（Computer Security Incident Response Team：インシデント対応の専門チーム）を立ち上げる組織が増えています。一方で、現場でよく聞かれるのが「CSIRTを作ったが、いざというときに機能しない」という声です。

組織図上にCSIRTが存在しても、有事に誰も動けない。インシデントが検知されても対応が宙に浮く。経営に判断が上がらない。こうした「形だけのCSIRT」は珍しくありません。問題は構築の手順を知らないことではなく、機能するために必要な条件が抜け落ちていることにあります。

本記事では、CSIRT構築が「作っても機能しない」状態に陥る原因を、5つのつまずきポイントとして構造化し、それぞれの対策を整理します。CSIRTの立ち上げを任されたセキュリティエンジニア・情シス担当・CISO候補が、形だけで終わらせないための実務の勘所として活用いただける内容を目指します。

前提整理：SOCとCSIRTは役割が違う

本題に入る前に、混同されやすいSOCとCSIRTの違いを整理します。両者は連携しますが、役割が異なります。

SOCが「検知する目」だとすれば、CSIRTは「対応を仕切る司令塔」です。この役割の違いを曖昧にしたまま構築を進めることが、後述するつまずきの一因にもなります。

つまずき① ミッション・スコープ・権限が曖昧

最も多いのが、CSIRTの「何のために、何を、どこまで」が定義されないまま立ち上げてしまうケースです。守る対象（スコープ）、対応する範囲、そして有事に行使できる権限が曖昧だと、インシデント発生時に動けません。

特に致命的なのが権限の欠如です。「インシデント時にシステムを停止する判断ができるか」「対応のために各部門へ指示を出せるか」「経営へ直接エスカレーションする導線があるか」。これらの権限が与えられていないCSIRTは、有事に「調整のお願い」しかできず、対応が後手に回ります。

たとえば、ランサムウェア感染が疑われる端末を発見したとき、ネットワークから即座に遮断・隔離する判断が遅れれば、被害は社内全体へ拡大します。しかし、その判断権限がCSIRTになく、事業部門や情報システム部門の合議を待つ設計になっていると、対応は決定的に後手に回ります。「誰が、どの範囲まで、止める判断をできるのか」を平時に決めておくことが、有事の初動スピードを左右します。

対策：ミッションと権限を文書化し、経営の承認を得る

CSIRTのミッション・スコープ・対応範囲・権限を文書化し、経営の正式な承認を得ることが出発点です。CSIRTは情シスの一機能としてではなく、経営に直結する位置づけ（CISO配下や経営直下）に置くことで、有事の意思決定が機能します。経営のコミットメントなしに機能するCSIRTは作れません。

つまずき② SOCとの役割分担が不明確

SOCとCSIRTの責任境界が曖昧だと、検知されたインシデントが「どちらの担当か」で宙に浮いたり、二重対応や抜け漏れが発生したりします。SOCを持つ組織でも、SOCからCSIRTへのハンドオフ基準が定義されていないと、対応の初動が遅れます。

対策：検知と対応の境界、エスカレーション基準を定義する

「検知・一次トリアージはSOC、対応の統括はCSIRT」のように責任境界を明確にし、どの深刻度でSOCからCSIRTへエスカレーションするかの基準を定めます。SOCを持たない組織では、CSIRTが監視機能をどこまで兼ねるか、あるいは外部のセキュリティ監視サービス（MSSP）を活用するかを構築段階で判断します。

つまずき③ 専任人材とスキルが足りない

CSIRTを兼任メンバーだけで構成し、必要なスキルが揃わないまま立ち上げるケースも多く見られます。インシデント対応には、ログ分析・フォレンジック・マルウェア解析といった技術スキルに加え、社内外を動かす調整力が求められます。これらをすべて内製で揃えるのは、多くの組織にとって現実的ではありません。

対策：内製と外注の線引きを設計し、平時から外部支援を確保する

コアとなる機能（対応の統括・意思決定・社内調整）は内製で持ち、高度な専門技術（フォレンジック・高度な解析）は外部の専門ベンダーやインシデント対応サービスと契約して補う、という線引きが現実的です。重要なのは、有事になってから探すのではなく、平時のうちに外部支援の契約（リテイナー）を結んでおくことです。

CSIRTに必要な主な役割

「専任の技術者を何人も揃える」と考えると人材確保のハードルが上がりますが、必要なのは人数よりも役割の充足です。1人が複数の役割を兼ねても、外部で補ってもかまいません。最低限カバーすべき役割を整理します。

重要なのは、これらの役割と、それを担う人・連絡先を平時に明確にしておくことです。有事に「誰がフォレンジックをやるのか」「広報は誰が判断するのか」を探し始めるようでは、対応は成立しません。

つまずき④ 対応プロセスが「文書止まり」で訓練されていない

インシデント対応手順書を整備しただけで満足し、訓練していないケースです。手順が文書にあっても、実際に動いた経験がなければ、有事には機能しません。連絡網が古い、担当者が手順を知らない、夜間休日の体制がない——こうした穴は、実際に動かしてみて初めて見つかります。

対策：プロセスを定義し、演習で繰り返し回す

インシデント対応を「検知 → トリアージ → 封じ込め → 根絶 → 復旧 → 事後分析」のプロセスとして定義し、典型的なインシデント別のプレイブックを整備します。そのうえで、机上演習（テーブルトップエクササイズ）や実地訓練で繰り返し回し、手順と連絡体制を検証します。訓練で見つかった穴を手順に反映するサイクルが、対応力を育てます。

演習で特に効果的なのが、机上演習（テーブルトップエクササイズ）です。実際のインシデントを想定したシナリオ——たとえば取引先経由のマルウェア感染、ランサムウェアによる基幹システム停止、内部不正による情報持ち出しなど——を用意し、関係者が机上で「自分なら何を判断し、誰に連絡するか」を順に追います。実機を止めずに対応の流れと連絡体制を検証でき、手順書の矛盾や連絡網の不備を低コストで洗い出せます。

プレイブックには、判断基準・連絡先（夜間休日を含む）・各フェーズの担当・外部連携先（インシデント対応ベンダー、JPCERT/CC、必要に応じて警察・監督官庁）までを具体的に盛り込みます。そして演習で見つかった穴を反映して更新し続けることで、文書は「読むもの」から「有事に動けるもの」へと変わります。

つまずき⑤ 平時の活動と改善ループがない

CSIRTを「インシデントが起きたときだけ動くチーム」と捉えると、平時に何も活動せず、練度も成熟度も上がりません。有事にしか動かないチームは、有事にも動けないというのが実態です。

対策：平時活動をルーチン化し、成熟度を継続的に高める

脅威インテリジェンスの収集、脆弱性管理、社内教育、訓練、そしてインシデントからの学びの反映——これらの平時活動をルーチンとして組み込みます。さらに、自組織のCSIRTがどの成熟段階にあるかを評価し、継続的に高めていく視点を持ちます。日本シーサート協議会（NCA）やJPCERT/CC、FIRSTといった外部コミュニティとの連携も、知見と練度を高める有効な手段です。

• 脅威インテリジェンス：自組織に関連する脅威動向を継続的に収集する
• 脆弱性管理：資産の脆弱性を把握し、対応の優先度をつける
• 教育・訓練：全社員のセキュリティ意識向上と、CSIRTメンバーの実地訓練
• 改善ループ：インシデントと訓練の教訓を手順・体制に反映し続ける

成熟度を段階で捉える

CSIRTは一度の構築で完成するものではなく、段階的に成熟させていく組織です。立ち上げ直後は「インシデントが起きてから動く」受動的な段階にとどまりますが、平時活動と訓練を重ねるにつれて、「脅威を先読みして備える」能動的な段階へと進みます。自組織が今どの段階にあるかを定期的に評価し、次の段階へ引き上げる目標を持つことで、形骸化を防げます。完璧な体制を最初から目指すのではなく、現在地を把握し、改善を積み重ねていく姿勢が重要です。

小さく立ち上げて育てる ― CSIRT構築の現実的な順序

5つのつまずきを踏まえると、CSIRT構築は「最初から完璧な体制を作る」のではなく、機能する最小単位から立ち上げて段階的に育てるのが現実的です。立ち上げの順序を整理します。

• ① ミッション・スコープ・権限を明文化し、経営の承認を得る（つまずき①の解消が起点）
• ② 少人数のコア体制を組み、不足する専門技術は外部リテイナーで補完する（つまずき③）
• ③ 自組織で起こりやすい重大インシデントを1つ想定し、対応プレイブックを1本作る（つまずき④）
• ④ そのプレイブックでテーブルトップ演習を実施し、穴を洗い出して手順に反映する
• ⑤ SOCや既存の監視との役割分担・エスカレーション基準を定義する（つまずき②）
• ⑥ 脅威情報収集・脆弱性管理・教育などの平時活動を少しずつ定常化する（つまずき⑤）

この順序のポイントは、最初に「権限と経営コミット」という土台を固めてから、対応力を一つずつ積み上げることです。すべてを同時に整えようとすると、どれも中途半端になり「形だけのCSIRT」に陥ります。まず1つの重大インシデントに本当に対応できる状態を作り、そこから守備範囲を広げていく発想が、機能するCSIRTへの近道です。

まとめ：機能するCSIRTにするために

CSIRTが「作っても機能しない」のは、構築手順を知らないからではなく、機能するための条件が抜け落ちているからです。本記事で挙げた5つのつまずきと対策を、構築・点検のチェックリストとして整理します。

CSIRT構築は、組織図にチームを置く作業ではなく、有事に機能する人・権限・プロセスをどう設計し、訓練を通じて育てるかという取り組みです。AIを業務の前提として組み込み、BPR起点で戦略から実装・運用まで一気通貫で担うアプローチは、こうした「仕組みを作って終わりにしない」セキュリティ体制づくりにおいても有効です。手順や組織図を整えるだけでなく、有事に本当に動ける形まで育て切れるかが、インシデント対応体制の実効性を分ける分岐点になります。