CSIRT構築の実務ガイド｜セキュリティインシデント対応チームを現場で立ち上げる方法

ランサムウェアに感染した、不審なログインが検出された、情報漏洩の可能性がある、といった事態が発生したとき、対応の司令塔がなければ現場は混乱します。

誰が判断し、誰に報告し、何を優先するのか。これを事前に決めておくのがCSIRTです。

本記事ではCSIRTの基本的な役割から、現場で実際に機能する体制の作り方まで解説します。

インシデント対応の基本フローについては「セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方」を参照してください。

CSIRTとは
1. セキュリティインシデントに対応する専門チーム
2. SOCとCSIRTの違い
CSIRTに必要な機能と役割
1. 最低限必要な4つの機能
2. 小規模組織での現実的な体制
CSIRT構築のステップ
現場でよくある失敗
チェックリスト
インシデントが起きたとき、最初に誰に連絡しますか？
あわせてご覧ください
参考文献

CSIRTとは

セキュリティインシデントに対応する専門チーム

CSIRTとは、組織内でセキュリティインシデントの検知・対応・収束・再発防止を担う専門チームです。

CSIRT（Computer Security Incident Response Team：シーサート）
セキュリティインシデントに対応するための専門チーム。インシデントの検知・トリアージ・対応・報告・再発防止までを一貫して担う。社内の関係部門や外部機関との調整役も果たす。

CSIRTがない組織では、インシデント発生時に「誰が対応するか」「何を優先するか」「誰に報告するか」が決まっていないため、対応が後手に回ります。被害が拡大し、証跡が消え、経営層への報告も遅れます。

CSIRTは大企業だけのものではありません。中小規模でも「インシデント対応の役割と手順を決めた体制」を持つことが重要です。専任のチームが作れない場合でも、兼任メンバーで構成したCSIRTを整備することで、有事の対応力は大きく変わります。

SOCとCSIRTの違い

CSIRTとよく混同されるのがSOCです。役割の違いを整理します。

SOC（Security Operation Center：セキュリティオペレーションセンター）
ログ・アラートを24時間365日監視してインシデントを検知する組織。主に「監視・検知」を担う。検知した脅威をCSIRTに引き渡すのが一般的な役割分担。

項目	SOC	CSIRT
主な役割	監視・検知	対応・収束・再発防止
活動タイミング	常時（24時間365日）	インシデント発生時を中心に活動
アウトプット	アラート・検知レポート	対応報告書・再発防止策
外部連携	少ない	多い（警察・JPCERT等）

SOCが「火災報知機」でCSIRTが「消防隊」というイメージです。両者は補完関係にあり、規模が小さい組織ではCSIRTがSOCの機能を兼ねるケースもあります。SOCとCSIRTの役割分担については「SOCとCSIRTの違い｜セキュリティ運用体制の考え方と規模別の設計パターン」も参照してください。

CSIRTに必要な機能と役割

最低限必要な4つの機能

CSIRTが担う機能は組織の規模によって異なりますが、最低限以下の4つが必要です。

機能	内容
1. インシデント受付・トリアージ	報告されたインシデントの受付・深刻度の評価・優先度付け
2. インシデント対応・調査	原因の特定・被害範囲の把握・封じ込め・復旧
3. 情報共有・報告	社内関係部門・経営層・外部機関への報告・情報共有
4. 再発防止・改善	事後レビュー・根本原因分析・対策の実施

この4つがすべて機能して初めてインシデント対応が完結します。「対応できたが報告しなかった」「収束したが振り返りをしなかった」という状態では、次のインシデントへの備えができません。

小規模組織での現実的な体制

専任チームを作れない中小規模の組織では、兼任メンバーでCSIRTを構成します。最小構成の例を示します。

役割	担当者（例）	主な責任
CSIRTリーダー	情報システム部長・IT責任者	意思決定・経営層への報告・外部機関との窓口
技術担当	インフラエンジニア・セキュリティ担当	原因調査・封じ込め・復旧作業
連絡調整担当	情報システム部員・総務	社内関係部門・ベンダーへの連絡調整
法務・コンプライアンス担当	法務・コンプライアンス部門	法的対応・個人情報漏洩時の対応判断

4名いれば最小限の体制は作れます。重要なのは「誰がCSIRTのメンバーか」を事前に決め、各自の役割を明確にしておくことです。インシデント発生後にメンバーを集めるのでは遅すぎます。

CSIRT構築のステップ

ステップ1：スコープと権限を決める

CSIRTが対応する範囲（スコープ）と、CSIRTに与える権限を明確にします。

スコープの例：

対象システム：社内ネットワーク全体・クラウド環境・業務端末
対象インシデント：マルウェア感染・不正アクセス・情報漏洩・DDoS攻撃
対象外：物理的セキュリティ（別組織が対応）

権限の例：

感染端末のネットワーク切断を独断で実施できる
調査のためにログへのアクセス権を持つ
外部のセキュリティベンダーへの支援要請を判断できる

権限が曖昧なままだと、いざというとき「上司の承認が必要」「他部門の許可が要る」と対応が止まります。CSIRTが迅速に動けるよう、あらかじめ権限を明文化しておくことが重要です。

ステップ2：連絡体制とエスカレーションフローを整備する

インシデント発生時に「誰に・いつ・どうやって報告するか」を事前に決めておきます。

【エスカレーションフローの例】

インシデント検知・報告
　↓
CSIRTリーダーへの第一報（30分以内）
　↓
深刻度の評価（トリアージ）
　↓
【深刻度：高】経営層・法務・広報へ報告（2時間以内）
【深刻度：中】部門長へ報告・技術対応開始
【深刻度：低】技術対応のみ・翌営業日に報告
　↓
外部機関への報告判断（個人情報漏洩の場合は72時間以内に個人情報保護委員会へ）

特に個人情報漏洩が疑われる場合は、個人情報保護法に基づき72時間以内の報告義務があります。対応が遅れると法的リスクになるため、フローに組み込んでおいてください。

ステップ3：インシデント分類基準を作る

すべてのインシデントを同じ優先度で対応するのは現実的ではありません。深刻度の分類基準を定めて、対応の優先度を判断できるようにします。

深刻度	基準の例	初動目標
Critical（最高）	ランサムウェア感染・DCへの不正アクセス・大規模情報漏洩	即時対応・経営層報告
High（高）	マルウェア感染（1台）・不審な外部通信・特権アカウント侵害疑い	2時間以内に対応開始
Medium（中）	フィッシングメール受信・不審なログイン試行	翌営業日までに対応
Low（低）	スパムメール・軽微な設定ミス	1週間以内に対応

証跡保全の手順については「証跡保全の基本｜インシデント対応で最初にやること」を参照してください。

ステップ4：ツールと手順書を準備する

インシデント発生時に「何を使って・何をするか」を事前にまとめておきます。

最低限準備しておくツール：

インシデント管理台帳（ExcelまたはチケットツールのテンプレートでOK）
連絡先リスト（社内関係部門・外部ベンダー・JPCERT/CC・警察サイバー犯罪相談窓口）
証跡保全ツール（WinPmem等）と手順書
インシデント対応報告書テンプレート

シナリオ別の手順書（最低限3本）：

ランサムウェア感染対応手順書
不正アクセス対応手順書
情報漏洩対応手順書

手順書は「インシデント発生時に初めて読んでも動ける」レベルの粒度で書いてください。専門知識がなくても手順通りに動けることが重要です。インシデント対応報告書の書き方については「インシデント対応報告書の書き方｜現場で使えるテンプレートと記載のポイント」を参照してください。

現場でよくある失敗

1. 「作ったけど動かない」形骸化CSIRT

規程上CSIRTを作ったものの、実際にインシデントが起きたときに機能しないケースがあります。原因は「メンバーが自分の役割を把握していない」「手順書が古くなっている」「訓練をしていない」の3つです。年1回以上の机上訓練（テーブルトップ演習）を実施して、手順と役割を実際に動かして確認することを推奨します。