CSIRTとは?役割やインシデント対応の流れ、SOC・PSIRTとの違いを初心者向けに解説
はじめに
企業や行政機関がサイバー攻撃を受けたというニュースの中で、CSIRTという言葉を見かけることがあります。
CSIRTは、情報セキュリティインシデントへ組織的に対応するチームや機能のことです。
不正アクセスやマルウェア感染、情報漏えいなどが発生したときには、被害状況を確認し、被害の拡大を防ぎ、システムを復旧させなければなりません。
さらに、実際のインシデント対応では、技術部門だけでなく、経営層、法務、広報、人事、営業、取引先などとの調整が必要になる場合もあります。
そのような対応の中心となるのがCSIRTです。
ただし、初めてCSIRTについて学ぶ方にとっては、
- CSIRTは何の略なのか
- インシデントが起きたときだけ活動するのか
- CSIRTはセキュリティ製品を監視する部署なのか
- SOCや情報システム部門とは何が違うのか
- CERTとCSIRTは別の組織なのか
- PSIRTとは何が違うのか
- 自社で開発したシステムはCSIRTとPSIRTのどちらが対応するのか
- CSIRTは専任チームでなければならないのか
といった点が分かりにくいのではないでしょうか。
CSIRTを一言で表すと、
「情報セキュリティインシデントに備え、発生時の対応を組織横断で調整するチームや機能」
です。
CSIRTは、必ずしも大規模な専任部署である必要はありません。
組織の規模や業務、守る対象、利用できる人材などに応じて、専任型、兼任型、仮想チーム型など、さまざまな形で構築できます。JPCERT/CCも、すべての組織に同じ形を求めるのではなく、それぞれの状況に合ったCSIRTを構築することが重要だと説明しています。
この記事では、CSIRTの意味、平時と有事の役割、インシデント対応の流れ、SOC・PSIRT・CERTとの違いについて、会話を中心に初心者向けにわかりやすく解説します。
CSIRTとは?

CSIRTは、情報セキュリティインシデントに対応するチームや組織機能のことだよ。

えぇと、サイバー攻撃を受けたときに、ウイルスを削除する技術者チームのことかな?

技術的な対応もするけれど、それだけではないよ。被害の確認、対応方針の決定、社内外への連絡、復旧、再発防止まで、インシデント対応全体を調整するんだ。
CSIRTは、Computer Security Incident Response Teamの略です。
一般的には「シーサート」と読みます。
日本語では、次のように表現されることがあります。
- コンピュータセキュリティインシデント対応チーム
- セキュリティインシデント対応チーム
- インシデント対応組織
JPNICはCSIRTを、コンピュータセキュリティインシデントに関する報告を受け取り、調査し、対応活動を行う組織体と説明しています。専任チームの場合もあれば、問題が起きたときに関係者が集まる形の場合もあります。

CSIRTを消防隊で例えてみよう

会社の防火体制で考えてみよう。
火災が発生したとき、消火器を使って火を消す人だけでは、十分な対応はできません。
実際には、次のような活動が必要です。
- 火災を発見する
- 消防へ通報する
- 周囲の人を避難させる
- 火が広がらないようにする
- 被害範囲を確認する
- 建物を安全な状態へ戻す
- 火災の原因を調査する
- 再発防止策を考える
- 避難訓練や設備点検を行う
CSIRTも、情報システムにおける消防隊や防災本部のような役割を持ちます。

| 防火活動 | CSIRTの活動 |
|---|---|
| 火災を発見する | 不審な通信やマルウェア感染を検知する |
| 消防へ通報する | CSIRTや関係部署へ報告する |
| 避難させる | 影響を受ける利用者や業務を保護する |
| 延焼を防ぐ | 端末隔離や通信遮断で被害拡大を防ぐ |
| 被害を確認する | 影響範囲や漏えい情報を調査する |
| 建物を復旧する | システムやデータを安全な状態へ戻す |
| 原因を調査する | ログや侵入経路を分析する |
| 再発を防ぐ | 脆弱性修正や運用改善を行う |
| 防災訓練を行う | インシデント対応訓練を実施する |

火事が起きた後だけでなく、訓練や点検もするんだね。

そう。CSIRTも、インシデントが起きていない平時の準備がとても重要なんだ。
セキュリティインシデントとは?
セキュリティインシデントとは、情報システムや情報資産の安全を脅かす出来事です。
JPCERT/CCは、サイバーインシデントを、情報および制御システムの運用におけるセキュリティ上の問題として捉えられる事象と説明しています。
代表的な例には、次のようなものがあります。
- 不正アクセス
- マルウェア感染
- ランサムウェア被害
- 情報漏えい
- Webサイトの改ざん
- DDoS攻撃
- アカウントの乗っ取り
- メールの誤送信
- USBメモリや端末の紛失
- 内部不正
- 脆弱性を悪用した攻撃
- 設定ミスによる情報公開
- クラウド上のデータの公開範囲ミス
- 委託先や取引先を経由した被害

外部からのサイバー攻撃だけがインシデントではないの?

そう。人の操作ミスや内部不正、設定ミスなども対象になるよ。
CSIRTの主な役割
CSIRTの役割は、組織によって異なります。
すべてのCSIRTが、同じ業務をすべて担当するわけではありません。
FIRSTのCSIRT Services Frameworkでも、CSIRTが提供できるさまざまなサービスを整理しつつ、すべてのチームがすべてのサービスを提供する必要はなく、使命や対象者に合った機能を選ぶものとされています。
一般的な役割は、大きく次のように分けられます。
- インシデントへの準備
- 相談や通報の受付
- インシデントの分析
- 対応方針の決定と調整
- 被害の封じ込め
- システムの復旧
- 原因調査
- 関係者への連絡
- 再発防止
- 脅威情報や脆弱性情報の収集
- 教育や訓練
インシデントの受付窓口になる
CSIRTは、セキュリティ上の問題を報告する窓口になります。
例えば、従業員が次のような異常に気づいたとします。
- 不審なメールを開いてしまった
- パソコンの動作がおかしい
- 身に覚えのないログイン通知が届いた
- 顧客情報を誤った相手へ送った
- 社用スマートフォンを紛失した
- Webサイトに見覚えのない内容が表示されている
このような報告を受け付け、必要な対応へつなげます。


報告先が分からないと、対応が遅れてしまうね。

そう。誰に、どの方法で、何を報告するかを平時から決めておくことが大切だよ。
状況を確認して優先度を決める
すべてのインシデントが、同じ深刻度とは限りません。
CSIRTは、次のような情報を確認します。
- 何が起きたのか
- いつ発生したのか
- どのシステムが影響を受けたか
- 被害が続いているか
- 個人情報や機密情報が関係しているか
- 業務を停止する必要があるか
- 取引先や顧客へ影響するか
- 法令上の報告が必要か
- 攻撃がほかの端末へ広がる可能性があるか
そのうえで、対応の優先度や緊急度を判断します。

被害の拡大を防ぐ
被害が続いている場合は、まず拡大を防ぐ必要があります。
これを封じ込めと呼びます。
例えば、次のような対応があります。
- 感染した端末をネットワークから切り離す
- 不正利用されたアカウントを停止する
- 悪意のあるIPアドレスとの通信を遮断する
- 攻撃を受けたサーバーを一時停止する
- 外部公開を制限する
- パスワードや認証情報を変更する
- 関係する利用者へ注意を呼びかける
ただし、すぐに端末の電源を切ると、調査に必要な情報が失われる場合もあります。
そのため、証拠保全や業務への影響を考えながら対応します。

原因と影響範囲を調査する
CSIRTは、ログや端末、ネットワーク通信などを調べます。
主な確認事項は次のとおりです。
- どこから侵入されたのか
- どの脆弱性が悪用されたのか
- どのアカウントが使われたのか
- どの端末やサーバーが影響を受けたのか
- どの情報が閲覧・持ち出しされた可能性があるか
- 攻撃者が現在も内部へ残っていないか
- 同じ攻撃が別の場所でも起きていないか
高度な調査では、デジタルフォレンジックの専門家や外部のセキュリティ企業と連携することもあります。

関係部署を調整する
大きなインシデントは、情報システム部門だけでは処理できません。
例えば、次の部署との連携が必要になる場合があります。
| 関係者 | 主な役割 |
|---|---|
| 経営層 | 事業停止や公表などの重要判断 |
| 情報システム部門 | システム停止、設定変更、復旧 |
| SOC | 監視、検知、ログ分析 |
| 法務部門 | 法的義務、契約、責任の確認 |
| 広報部門 | 顧客や報道機関への説明 |
| 人事部門 | 従業員や内部不正への対応 |
| 営業・顧客対応 | 顧客への案内や問い合わせ対応 |
| 個人情報保護担当 | 個人データへの影響確認 |
| 委託先・ベンダー | 製品やサービスの調査・復旧 |
| 公的機関 | 届出、相談、情報共有 |


CSIRTのメンバーが、全部の作業を自分で行うの?

そうとは限らないよ。必要な専門部署へ依頼し、対応全体を調整することも重要な役割なんだ。
安全な状態へ復旧する
封じ込めと原因調査を行った後は、システムを安全な状態へ戻します。
例えば、次の対応があります。
- マルウェアを除去する
- 端末やサーバーを再構築する
- バックアップからデータを復元する
- 脆弱性を修正する
- 不正に作られたアカウントを削除する
- 認証情報を変更する
- セキュリティ設定を見直す
- 監視を強化する
- 段階的にシステムを再開する
単にシステムを動かせる状態へ戻すだけではありません。
攻撃者が内部へ残っていないことや、同じ方法で再び侵入されないことを確認する必要があります。

再発防止策を実施する
インシデントが収束した後は、対応内容を振り返ります。
例えば、次の点を確認します。
- 検知が遅れた理由
- 報告手順が機能したか
- 対応の責任者が明確だったか
- 必要なログが保存されていたか
- 関係部署への連絡が適切だったか
- 顧客への説明に時間がかからなかったか
- 同じ原因がほかのシステムにもないか
- 手順書を修正する必要があるか
再発防止策として、次のような改善を行います。
- 脆弱性管理の強化
- 多要素認証の導入
- アクセス権限の見直し
- バックアップ方法の改善
- ログ取得範囲の拡大
- 従業員教育
- インシデント対応手順の更新
- 監視ルールの追加
- 委託先管理の見直し

CSIRTの平時の活動

インシデントが起きていないとき、CSIRTは何をしているの?

情報収集、手順整備、教育、訓練など、インシデントへ備える活動をしているよ。
CSIRTの価値は、事件が起きたときだけに現れるものではありません。
平時には、次のような活動を行います。
- 脅威情報の収集
- 脆弱性情報の収集
- インシデント対応手順の作成
- 緊急連絡網の整備
- 関係部署との役割確認
- セキュリティ教育
- 標的型メール訓練
- インシデント対応演習
- 監視体制の見直し
- 外部CSIRTとの情報共有
- 委託先や製品ベンダーとの連絡経路確認
- 過去のインシデントの分析
JPCERT/CCのCSIRTマテリアルも、CSIRTの構想、構築、運用、インシデントハンドリング、対応演習などを一連の活動として扱っています。

インシデント対応の基本的な流れ
組織によって詳細は異なりますが、CSIRTによる対応は、一般的に次のような流れで進みます。
- 準備
- 検知・受付
- 分析・分類
- 封じ込め
- 根絶
- 復旧
- 事後対応
1.準備
インシデントが発生する前に、必要な準備を行います。
- 対応手順
- 連絡先
- 責任者
- 使用するツール
- ログの保存方法
- 外部専門家との契約
- 判断基準
- 訓練計画
準備が不十分だと、緊急時に誰も判断できず、被害が拡大する可能性があります。

2.検知・受付
SOC、従業員、顧客、取引先、外部機関などから異常の報告を受けます。
この段階では、単なる誤検知なのか、本当のインシデントなのか分からない場合もあります。

3.分析・分類
発生した事象について調査し、インシデントかどうか、どの程度深刻かを判断します。
- 影響範囲
- 緊急度
- 情報の機密性
- 業務への影響
- 法的な報告義務
- 被害拡大の可能性
などを確認します。

4.封じ込め
被害の拡大を防ぎます。
感染端末の隔離、アカウント停止、通信遮断などを行います。
短期的な封じ込めと、業務を継続しながら行う中長期的な対策を分けることもあります。

5.根絶
攻撃の原因や、攻撃者が残した仕組みを取り除きます。
- マルウェアの削除
- 脆弱性の修正
- 不正アカウントの削除
- 設定ミスの修正
- 侵入経路の閉鎖
などを行います。

6.復旧
システムを安全な状態で業務へ戻します。
復旧後も一定期間は監視を強化し、攻撃が再発していないか確認します。

7.事後対応
対応内容を振り返り、手順、技術、組織体制を改善します。

| 段階 | 主な活動 |
|---|---|
| 準備 | 手順、体制、連絡網、訓練 |
| 検知・受付 | 異常の発見と通報 |
| 分析・分類 | 原因、影響、深刻度の確認 |
| 封じ込め | 被害拡大の防止 |
| 根絶 | 原因や攻撃者の痕跡を除去 |
| 復旧 | 安全に業務を再開 |
| 事後対応 | 振り返りと再発防止 |
CSIRTはどのような人で構成される?
CSIRTには、セキュリティ技術者だけでなく、さまざまな知識や権限を持つ人が関わります。
- セキュリティ担当者
- ネットワーク担当者
- サーバー担当者
- クラウド担当者
- アプリケーション担当者
- 法務担当者
- 広報担当者
- 人事担当者
- 個人情報保護担当者
- リスク管理担当者
- 経営層
- 外部のセキュリティ専門家

広報や法務もCSIRTのメンバーになるの?

常時所属するとは限らないけれど、必要なときに連携できる体制が重要だよ。
情報漏えいが発生すれば、技術的な復旧だけでなく、顧客への説明、監督機関への報告、契約上の責任確認などが必要になる可能性があります。
CSIRTの体制の種類
CSIRTは、組織の規模や人材によって異なる形で構築できます。
専任型
CSIRTの仕事を主な業務とするメンバーで構成します。
| 長所 | 短所 |
|---|---|
| 専門性や対応速度を高めやすい | 人材と費用が必要 |
| 平時の活動を継続しやすい | 小規模組織では維持が難しい |
| 知識を蓄積しやすい | CSIRTだけで孤立する可能性がある |

兼任型
情報システム部門やセキュリティ部門などの担当者が、通常業務と兼任します。
| 長所 | 短所 |
|---|---|
| 少ない人員で始めやすい | 緊急時に通常業務と競合する |
| 既存の知識を利用できる | 平時の準備が後回しになりやすい |
| 組織の事情を理解している | 担当者への負担が大きい |

仮想チーム型
普段は別々の部署に所属し、インシデント発生時に集まって活動します。

正式なCSIRT専用部署がなくても作れるんだね。

そう。重要なのは名前ではなく、必要な人が迅速に集まり、判断し、対応できることだよ。

外部委託を利用する型
監視、フォレンジック、マルウェア解析などの一部を外部へ委託します。
ただし、すべてを外部へ任せても、自社の経営判断や業務上の優先順位まで外部事業者が決められるわけではありません。
組織内には、外部事業者からの報告を受け、社内を調整し、意思決定する責任者が必要です。

CSIRTとSOCの違い
SOCは、Security Operation Centerの略です。
一般的には、ネットワーク、サーバー、クラウド、セキュリティ製品などを監視し、不審な活動を検知・分析します。
CSIRTは、検知された問題について、被害確認、対応方針の決定、関係部署との調整、復旧、再発防止などを進めます。

| 項目 | CSIRT | SOC |
|---|---|---|
| 正式名称 | Computer Security Incident Response Team | Security Operation Center |
| 主な役割 | インシデント対応全体の調整 | 監視、検知、分析 |
| 主な活動時期 | 平時の準備とインシデント発生時 | 継続的な監視 |
| 注目するもの | 組織への影響と対応 | ログ、アラート、通信 |
| 関係部署との調整 | 重要な役割 | 主目的ではないことが多い |
| 復旧や再発防止 | 調整・推進する | 分析結果を提供することが多い |

SOCが異常を見つけ、CSIRTが対応を進めるの?

典型的にはそう考えられるけれど、組織によって役割の境界は違うよ。
SOCとCSIRTの役割は重なる場合もあり、一つの組織が両方の機能を持つこともあります。
大切なのは名称ではなく、監視、判断、連絡、復旧などの責任が明確になっていることです。
CSIRTとPSIRTの違い
PSIRTは、Product Security Incident Response Teamの略です。
企業が顧客などへ提供している製品やサービスの脆弱性、またはそれに関係するセキュリティインシデントへ対応するチームです。

| 項目 | CSIRT | PSIRT |
|---|---|---|
| 主な保護対象 | 自組織の情報システムや業務 | 顧客へ提供する製品・サービス |
| 主な問題 | 社内システムへの攻撃、情報漏えい | 製品の脆弱性、利用者への影響 |
| 主な関係者 | 社内各部署、経営層、取引先 | 開発部門、品質保証、顧客、研究者 |
| 主な対応 | 封じ込め、復旧、社内調整 | 脆弱性検証、修正版、情報公開 |
| 例 | 社内端末のランサムウェア感染 | 販売した製品の脆弱性発見 |
JPCERT/CCのCSIRTマテリアルも、近年の対応範囲の変化として、PSIRTに代表される「組織の提供物」に対するセキュリティ活動を取り上げています。
自社で開発したシステムはCSIRTとPSIRTのどちら?

自社が開発したシステムなら、すべてPSIRTが対応するの?

自社で開発したかどうかだけでは決まらないよ。誰が利用し、何を守るための対応かを考えるんだ。
自社内部で使用するシステムの場合
自社の従業員だけが利用する勤怠管理システムや社内業務システムで、サイバー攻撃や情報漏えいが発生した場合は、一般的にはCSIRTの対応範囲になります。
開発者が自社であっても、守る対象は自組織の業務や情報だからです。
顧客へ提供する製品・サービスの場合
顧客へ販売したソフトウェアや、顧客が利用するクラウドサービスに脆弱性が見つかった場合は、PSIRTの対応範囲になります。
一つの問題に両方が関係する場合
自社のクラウドサービスに脆弱性があり、実際に攻撃を受けた場合は、両方が関係する可能性があります。
- PSIRT:製品の脆弱性を調査し、修正版や顧客向け情報を準備する
- CSIRT:自社環境への侵入、情報漏えい、業務影響へ対応する
| 状況 | 主に関係する組織 |
|---|---|
| 社内システムへの不正アクセス | CSIRT |
| 社員用端末のマルウェア感染 | CSIRT |
| 販売製品に脆弱性が見つかった | PSIRT |
| 顧客向けクラウドサービスの脆弱性 | PSIRT |
| 脆弱性が悪用され、自社環境も侵害された | CSIRTとPSIRT |
| 製品利用者から脆弱性報告を受けた | PSIRT |
| 社内開発システムから社内情報が漏えいした | CSIRT |

開発した会社で分けるのではなく、自組織を守るのか、提供製品の利用者を守るのかで考えるんだね。

その理解が分かりやすいよ。ただし、実際の担当範囲は組織ごとの規程で決める必要があるよ。
CSIRTとCERTの違い
CERTは、Computer Emergency Response Teamの略として使われます。
CSIRTとCERTは、実務上、同じようなインシデント対応組織を表す名称として使われることがあります。


CERTとCSIRTは、まったく別の仕組みではないの?

名称や歴史的な背景は違うけれど、インシデント対応組織を表す言葉として近い意味で使われることが多いよ。
ただし、CERTという名称は、組織名や登録商標との関係から、特定のチーム名として使われている場合があります。
試験対策では、どちらもセキュリティインシデントへ対応する組織として押さえておくとよいでしょう。
CSIRTと情報システム部門の違い
情報システム部門は、組織のIT環境を日常的に運用します。
- アカウント管理
- パソコンの導入
- ネットワーク管理
- システム運用
- 利用者サポート
- バックアップ
- ソフトウェア管理
CSIRTは、セキュリティインシデントへの準備と対応を中心とします。
| 項目 | CSIRT | 情報システム部門 |
|---|---|---|
| 主な目的 | インシデントへの対応 | IT環境の安定運用 |
| 主な対象 | セキュリティ上の問題 | IT全般 |
| 緊急時 | 対応方針と全体調整 | 停止、設定変更、復旧作業 |
| 平時 | 手順、訓練、情報収集 | 運用、保守、利用者支援 |
| 関係 | 情シスへ作業を依頼することがある | CSIRTのメンバーになることがある |
小規模な組織では、情報システム部門がCSIRT機能を兼ねることもあります。
CSIRTとセキュリティ担当者の違い
セキュリティ担当者は、規程、教育、リスク評価、製品導入など、幅広いセキュリティ業務を担当します。
CSIRTは、その中でもインシデントへの備えと対応に焦点を当てた機能です。
一人のセキュリティ担当者が、CSIRTの責任者や窓口を兼任することもあります。
CSIRTとJPCERT/CCの違い

CSIRTはJPCERT/CCのこと?

JPCERT/CCはCSIRTの一つだけれど、会社の中に作る組織内CSIRTとは役割が違うよ。
JPCERT/CCは、特定の企業内だけを対象とするのではなく、日本の窓口CSIRTとして、国内外のCSIRTとの連携や情報共有、インシデント対応の調整などを行う組織です。

| 項目 | 組織内CSIRT | JPCERT/CC |
|---|---|---|
| 主な対象 | 自組織 | 国内外の広い関係者 |
| 主な目的 | 自社のインシデント対応 | 調整、情報共有、支援 |
| 設置者 | 企業、大学、行政機関など | 独立した調整機関 |
| 例 | ○○社CSIRT | JPCERT/CC |
CSIRTのメリット
インシデントへ迅速に対応しやすくなる
報告先、責任者、連絡経路を事前に決めておくことで、初動の遅れを減らせます。
被害の拡大を防ぎやすくなる
誰が端末隔離やアカウント停止を判断するか明確にしておけば、必要な対応を早く実施できます。
組織横断で対応できる
技術部門、経営層、法務、広報などをつなぎ、技術面だけでなく事業面を含めて対応できます。
対応経験を蓄積できる
インシデントの記録、原因、対応内容、改善点を残すことで、次回の対応へ生かせます。
社外との連携窓口を明確にできる
取引先、セキュリティ企業、公的機関、外部CSIRTなどとの連絡窓口を一本化しやすくなります。
平時の対策を改善できる
インシデントや訓練の結果を、教育、監視、脆弱性管理などの改善へつなげられます。
CSIRTのデメリット・課題
人材の確保が難しい
CSIRTには、技術、法務、コミュニケーション、リスク判断など、幅広い能力が必要です。
すべての能力を一人で持つことは難しいため、複数部署や外部専門家との連携が必要です。
平時には成果が見えにくい
大きなインシデントが発生しないと、CSIRTの活動が費用としてだけ見られることがあります。
しかし、訓練や手順整備は、被害を防ぎ、対応時間を短縮するために重要です。
責任や権限が曖昧になりやすい
CSIRTを作っても、システム停止や対外公表を判断する権限がなければ、対応が進まない可能性があります。
兼任者の負担が大きくなる
通常業務を持つメンバーが兼任している場合、緊急対応が重なると大きな負担になります。
他部署との連携が必要
CSIRTだけで対応を完結できないため、日頃から関係部署との信頼関係を築く必要があります。
CSIRTを構築する基本的な流れ
1.守る対象を明確にする
まず、CSIRTが誰に、どのようなサービスを提供するのかを決めます。
- 自社全体
- 特定の事業部門
- 国内拠点
- 海外を含むグループ全体
- 顧客向けサービス
- 工場や制御システム
守る対象が曖昧だと、問題が起きたときに担当範囲でもめる可能性があります。

2.対応するインシデントを決める
- マルウェア感染
- 情報漏えい
- 不正アクセス
- 端末紛失
- 内部不正
- クラウド設定ミス
- 委託先の被害
など、どのような事象を受け付けるか整理します。

3.責任と権限を決める
次のような権限を誰が持つか決めます。
- システムの停止
- アカウントの停止
- 外部専門家への依頼
- 顧客への連絡
- 行政機関への報告
- インシデントの公表
- 証拠の保全

4.メンバーと連絡先を決める
技術担当者だけでなく、法務、広報、経営層などへの連絡経路も決めます。

5.対応手順を作る
通報受付から復旧、振り返りまでの手順を作成します。

6.必要なツールや外部サービスを準備する
- ログ管理
- EDR
- SIEM
- チケット管理
- 緊急連絡手段
- フォレンジック
- マルウェア解析
- インシデント対応支援
などを検討します

7.訓練して改善する
手順書を作っただけでは、緊急時に動けるとは限りません。
机上演習や実践的な訓練を行い、連絡や意思決定に問題がないか確認します。

CSIRT運用で重要なポイント
報告しやすい窓口を作る
従業員が失敗を隠すような環境では、発見が遅れます。
「不審なメールを開いた」「誤送信した」と早く報告できる文化が重要です。
技術用語だけで説明しない
経営層へは、単に「マルウェアを検知した」と報告するだけでなく、事業への影響を説明します。
- 顧客サービスが停止する可能性
- 個人情報が漏えいした可能性
- 復旧までに必要な時間
- 公表や届出の必要性
- 想定される費用
などを伝えます。
記録を残す
対応中は、次の内容を時系列で記録します。
- 発生時刻
- 発見時刻
- 報告内容
- 判断した内容
- 実施した操作
- 関係者への連絡
- 証拠の保管場所
- 復旧状況
記録は、事後分析、説明、法的対応などに役立ちます。
定期的に手順を更新する
組織、システム、取引先、連絡先は変化します。
古い手順書のままでは、緊急時に連絡が取れない可能性があります。
ITパスポート・基本情報・応用情報の試験対策
CSIRTは、情報セキュリティ管理やインシデント対応に関する重要用語です。
試験では、名称だけでなく、SOCやPSIRTとの違いを押さえておくと理解しやすくなります。
試験別に押さえたい内容
| 試験 | 主な対策ポイント |
|---|---|
| ITパスポート | セキュリティインシデントへ対応する組織 |
| 基本情報技術者 | インシデントの受付、調査、対応、復旧 |
| 応用情報技術者 | SOC・PSIRTとの違い、組織横断的な調 |
試験で覚えたい重要用語
| 用語 | 覚える内容 |
|---|---|
| CSIRT | セキュリティインシデントへ対応するチーム |
| インシデント | 情報資産やシステムの安全を脅かす事象 |
| SOC | 監視、検知、分析を行う組織 |
| PSIRT | 提供製品やサービスの脆弱性へ対応する組織 |
| CERT | インシデント対応組織を表す近い名称 |
| JPCERT/CC | 日本の窓口CSIRT |
| 封じ込め | 被害の拡大を防ぐ |
| 根絶 | 原因や攻撃者の痕跡を取り除く |
| 復旧 | 安全な状態で業務を再開する |
| フォレンジック | 電子的な証拠を収集・分析する |
試験問題で注目する表現
| 問題文の表現 | 考えられる答え |
|---|---|
| セキュリティ事故へ組織的に対応する | CSIRT |
| ログを常時監視して攻撃を検知する | SOC |
| 自社製品の脆弱性報告を受け付ける | PSIRT |
| 被害の拡大を防ぐため端末を隔離する | 封じ込め |
| 原因となったマルウェアを除去する | 根絶 |
| バックアップからシステムを戻す | 復旧 |
| 国内外のCSIRTと調整する日本の窓口 | JPCERT/CC |
| インシデント後に対応を振り返る | 事後対応・再発防止 |
CSIRT・SOC・PSIRTの試験対策比較
| 組織 | 主な対象 | 主な役割 | 覚え方 |
|---|---|---|---|
| CSIRT | 自組織のインシデント | 対応と調整 | 事故対応の司令塔 |
| SOC | システムやネットワーク | 監視・検知・分析 | 見張る組織 |
| PSIRT | 提供製品・サービス | 脆弱性対応 | 製品を守る組織 |
| JPCERT/CC | 国内外の関係組織 | 情報共有・調整 | 日本の窓口CSIRT |
よくある誤解
CSIRTはインシデントが起きたときだけ活動する

何も起きていないときは、CSIRTの仕事はないよね?

平時の準備がなければ、緊急時に適切に動けないよ。
CSIRTは、手順整備、情報収集、教育、訓練、関係者との連携などを平時から行います。
CSIRTはウイルスを駆除する技術者だけで構成される
CSIRTには技術力が必要ですが、インシデント対応には経営判断、法務、広報、顧客対応なども関係します。
すべてをCSIRTの固定メンバーにする必要はありませんが、必要な部署と連携できる体制が必要です。
CSIRTとSOCは同じである
SOCは主に監視、検知、分析を行います。
CSIRTは、検知されたインシデントに対して、対応方針を決め、関係者を調整し、復旧や再発防止を進めます。
ただし、組織によっては同じチームが両方の機能を持ちます。
自社開発のシステムは必ずPSIRTが対応する
自社で作ったかではなく、何を守る対応かで考えます。
社内利用システムの侵害はCSIRT、顧客へ提供する製品の脆弱性はPSIRTが中心になるのが基本です。
一つの問題に両方が関係することもあります。
CSIRTを設置すればインシデントを防げる
CSIRTは、インシデントの予防にも関わりますが、すべての攻撃やミスを防げるわけではありません。
インシデントが起こる可能性を前提に、被害を小さくし、早く復旧する体制を作ることが重要です。
専任チームでなければCSIRTではない
兼任型や仮想チーム型でも、必要な責任、連絡経路、手順、権限が整っていればCSIRT機能を持てます。
組織の規模に合わせて設計します。
CSIRTがすべての作業を行う
CSIRTは、対応全体を調整する役割を持ちます。
実際のシステム停止や復旧は情報システム部門、顧客への説明は広報や営業、法的判断は法務が行う場合があります。
CSIRTを作れば情報システム部門は不要になる
CSIRTと情報システム部門は目的が異なります。
CSIRTはインシデント対応を調整し、情報システム部門は日常運用や技術的な復旧作業を担います。
インシデントの報告は確証を得てから行う
不審な状況を完全に調査してから報告しようとすると、初動が遅れます。
従業員は、インシデントか確定していなくても、異常を早く報告できることが大切です。
CSIRTが情報を確認し、対応の必要性を判断します。
CSIRTの成功はインシデント件数が0であること
報告件数が少ない理由が、問題が起きていないからとは限りません。
従業員が報告方法を知らない、失敗を隠している、検知できていない可能性もあります。
対応時間、検知時間、訓練結果、改善状況など、複数の観点で評価する必要があります。
まとめ
CSIRTとは、情報セキュリティインシデントに備え、発生時の対応を組織横断で調整するチームや機能です。
CSIRTは、Computer Security Incident Response Teamの略で、一般的には「シーサート」と読みます。
インシデント発生時には、次のような活動を行います。
- 通報や相談の受付
- 状況と影響範囲の調査
- 優先度の判断
- 被害の封じ込め
- 原因の除去
- システムの復旧
- 経営層や関係部署との調整
- 顧客や外部機関への連絡
- 再発防止
また、インシデントが起きていない平時には、手順整備、脅威情報の収集、教育、訓練、連絡網の確認などを行います。
CSIRTと混同されやすい組織として、SOCとPSIRTがあります。
SOCは主にシステムの監視、攻撃の検知、分析を行います。
PSIRTは、企業が顧客へ提供する製品やサービスの脆弱性へ対応します。
自社が開発したシステムであっても、社内だけで利用するシステムの侵害であればCSIRT、顧客へ提供する製品の脆弱性であればPSIRTが中心になるのが基本です。
ただし、一つの問題にCSIRTとPSIRTの両方が関係する場合もあります。
最後に要点を整理します。
| 項目 | 内容 |
|---|---|
| 用語 | CSIRT |
| 正式名称 | Computer Security Incident Response Team |
| 読み方 | シーサート |
| 一言でいうと | セキュリティ事故対応の司令塔 |
| 主な対象 | 自組織の情報システム、情報、業務 |
| 平時の活動 | 情報収集、手順整備、教育、訓練 |
| 有事の活動 | 受付、分析、封じ込め、復旧、再発防止 |
| 主な関係者 | 経営、情シス、SOC、法務、広報など |
| SOCとの違い | SOCは監視・検知、CSIRTは対応・調整 |
| PSIRTとの違い | PSIRTは提供製品・サービスの脆弱性対応 |
| CERTとの違い | 近い意味で使われるインシデント対応組織 |
| JPCERT/CC | 日本の窓口CSIRT |
| 体制 | 専任型、兼任型、仮想チーム型など |
| 専任者 | 必須ではない |
| 重要な点 | 責任、権限、連絡経路を明確にする |
| 試験対策 | 「インシデントへの対応と組織間の調整」と覚える |
| 覚え方 | SOCが見つけ、CSIRTが動かし、PSIRTが製品を守る |

CSIRTは、ウイルスを削除する技術者だけのチームではないんだね。

そう。被害の確認、対応方針、社内外の連絡、復旧、再発防止まで、対応全体を調整するんだ。

SOCが異常を監視して見つけ、CSIRTが関係部署を動かして対応するイメージだね。

分かりやすくいえばそうだよ。ただし、実際の役割分担は組織ごとに決める必要があるよ。

PSIRTは、顧客へ提供している製品やサービスの脆弱性へ対応するんだね。

そう。社内システムを守るならCSIRT、提供製品を守るならPSIRTと考えると、基本的な違いをつかみやすいよ。

インシデントが起きてから集まるだけでなく、平時から手順や訓練を準備することも大切なんだね。

バッチリ。CSIRTは、事故が起きたときに慌てないための、組織の防災体制のような存在なんだ。

