はじめに

少し前の私は、インシデント対応について聞かれると「気をつけます」「再発防止に努めます」くらいの言葉しか持っていませんでした。インシデント対応計画のドキュメントは存在する。けれど、いざ本当に障害が起きたとき、自分が最初に何を見て、誰に上げて、どこで「これはインシデントだ」と判断するのかは、一度も具体的に考えたことがなかったのです。

それを思い知ったのが、講義で体験した机上演習でした。シナリオの中で目の前のシステムが止まり、連絡先につながらず、刻々と状況が変わる。そのとき「計画書を持っていること」と「有事に実際に動けること」は、まったく別物だと痛感しました。「気をつけます」は気持ちであって、手順ではありません。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログです。本シリーズの通し番号では #9 にあたります。想定読者は、少し前の私と同じく「インシデント対応を『気をつけます』程度の言葉でしか持っていない」エンジニア・情シスです。有事に誰が・どの順で・何を判断して動くのかを、まだ具体的に説明できない人を念頭に置いています。平時の改善ループとは別物の動き方、インシデントレベルの切り分け、CSIRT の役割といった具体が、言葉になっていない段階の人です。

前回(#8)は「平時・捉え方編」として、攻撃の分業化(RaaS)・MITRE ATT&CK・組織の盲点を扱いました。この記事はその「有事・対応編」で、#8 で扱った内容(攻撃の分業化や3事例など)は再解説せず、「攻撃を受けたあと、どう動くか」に集中します。

この記事の軸になる見方を、先に1行で書いておきます。

「気をつけます」「再発防止します」という言葉では、インシデントは止まらない。止めるのは、①有事の動き方(OODA)、②機能としての CSIRT、③情勢判断=インシデントレベルのトリアージという、平時に決めておく具体的な型である。

結論を先に3点でまとめておきます(TL;DR)。本文はこれをほどいていく形です。

有事は、平時の改善ループ(PDCA)ではなく、適応ループ(OODA)で動く。 PDCA は「じっくり良くする」ためのループ、OODA は「不確実な状況で素早く生き延びる」ためのループです。インシデント対応は後者です。
CSIRT は「部署」ではなく「機能」。 インシデント対応を専門に行う部署を新設しなくても、有事に「観測 → 情勢判断 → 意思決定 → 対処」を回す機能があれば、それが CSIRT です。検知に特化した SOC とは役割が違います。
情勢判断の核は、インシデントレベルのトリアージ。 「これはレベルいくつか」を即答できると、誰を巻き込み、どれだけ急ぐかが自動的に決まります。この基準は平時に作っておくものです。

読み終えたとき、有事の動き方を「気をつけます」ではなく「まず観測、次にレベル判定、それから誰に上げるか」と順番で語れるようになっていれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

平時のPDCA、有事のOODA ── ループが違う

まず、いちばん持ち帰ってほしい対比から始めます。平時と有事では、回すべきループが違います。

なぜ有事に PDCA ではダメなのか

多くの組織は、平時の運用改善に PDCA(Plan-Do-Check-Act)を使っています。計画を立て、実行し、評価し、改善する。じっくり時間をかけて品質を上げていく、優れたループです。

一方、インシデントの最中はどうでしょうか。アラートが鳴り、状況は刻々と変わり、情報は断片的で、しかも待ってくれません。ここで「まず詳細な計画を立てましょう」と腰を据えてしまうと、その間に被害が広がります。

そこで有事に向くのが OODA ループです。OODA は、アメリカ空軍のジョン・ボイド(John Boyd)が1970年代初頭に提唱した意思決定モデルで、Observe(観測)・Orient(情勢判断)・Decide(意思決定)・Act(対処)の頭文字です(Wikipedia: OODA loop)。

両者の違いは、「いつ動くか(コミットのタイミング)」にあります。

	PDCA	OODA
向く場面	平時の継続的改善	有事・不確実で変化が速い状況
性格	改善ループ(じっくり良くする)	適応ループ(素早く生き延びる)
コミット	早めに計画を固める	状況を見てから動く(遅らせる)
起点	計画(Plan)から	観測(Observe)から

念のため補足すると、これは「PDCA が時代遅れ」という話ではありません。平時の改善には PDCA が向き、有事の適応には OODA が向く、という使う場面の違いです。両方を持ち、切り替えられることが大事です。

OODA の4ステップを、インシデントの言葉で読む

OODA をインシデント対応の文脈に置き換えると、4ステップはこうなります。

Observe(観測): 異変の兆候を集めます。IDS のアラート、SOC からの連絡、外部からの問い合わせ、新しい脆弱性情報など、入口は複数あります。
Orient(情勢判断): 集めた情報から「これはどれくらい深刻か」を見立てます。ここがインシデントレベルのトリアージで、後述するこの記事のいちばんの持ち帰りです。
Decide(意思決定): 組織として方針を決めます。誰の承認で、どこまでやるか。現場だけで決められないことも多く、ここで巻き込む人が変わります。
Act(対処): 封じ込め、根絶、復旧といった実際の手を打ちます。

そして OODA は1周で終わりません。対処した結果をまた観測し、状況が変わればレベルを見直し、また動く。この回り続けるところが、固定の手順書との違いです。

CSIRT とは「組織」ではなく「機能」

OODA を回す主体が CSIRT です。ここで多くの人(かつての私を含む)がつまずくのが、「CSIRT = 専門部署を作ること」という誤解です。

CSIRT の役割と、SOC との違い

CSIRT は Computer Security Incident Response Team の略で、組織内で起きたセキュリティインシデントに対して、受付・状況把握・対応方針の決定・原因排除・復旧・再発防止までを担う機能です。

ここで JPCERT/CC の整理が効いてきます。同センターの「CSIRT ガイド」では、CSIRT は必ずしも「インシデント対応を専門に行う部署」である必要はなく、必要なのは「インシデント対応を専門に行う機能」だ、とされています(JPCERT/CC「CSIRTガイド」)。つまり、専任チームを新設できなくても、有事に OODA を回す機能を組織内に用意できていれば、それが CSIRT です。

混同されやすい SOC との違いも押さえておきます。一般には、次のように整理されることが多いです。

	SOC	CSIRT
主な役割	監視・検知(アラートを上げる)	受付・判断・対応・復旧の調整
OODA での位置	Observe(観測)を支える	Orient 以降を回す司令塔

SOC が「異変を見つけるアンテナ」だとすれば、CSIRT は「見つかった異変にどう動くかを決める司令塔」です。役割の区切り方は組織によって幅があるため、ここでは一般的な整理として捉えてください。

経営・マネジメント・現場の3層で回す

有事の意思決定(OODA の Decide)は、現場だけで完結しません。ここは #8 で触れた「経営・マネジメント・現場」の3レイヤーを、有事の側で具体化する話になります。

軽微なものは現場で対処できますが、業務全体や全社に影響する事態になると、部門長や CISO といった上位の判断が要ります。「どのレベルなら誰が決めるのか」を決めておくこと自体が、CSIRT の準備の一部です。そして、そのレベルを決める基準が次のトリアージです。

情勢判断の核心:インシデントレベルのトリアージ

OODA の Orient(情勢判断)を具体的にすると、「このインシデントはレベルいくつか」を決める作業になります。これがこの記事のいちばんの持ち帰りです。

講義では、インシデントレベルを4段階に分ける一例が示されました。次の表は講義で示された一例であり、特定の公的標準の数値ではありません。組織によって基準は変わりますが、考え方の型として有用です。

レベル	影響範囲	主な判断者	対応の目安
レベル4	業務影響なし	現場	数週間以内に対応
レベル3	業務の一部	専門部署	1日〜数日
レベル2	業務全体	部門長	4時間以内に着手・待機
レベル1	全社	CISO	2時間以内・24時間体制

この表を縦に読むと、影響範囲が広くなるほど、判断する人は上位になり、対応の時間は短くなることがわかります。これがトリアージの一般原則です。具体的な時間や役職は組織ごとに調整するとしても、この「影響が広いほど、上位者が、より速く」という構造は共通します。

トリアージが効くのは、レベルを決めた瞬間に、巻き込む人と動く速度が自動的に決まるからです。「とりあえず偉い人に全部報告」でも「現場で抱え込む」でもなく、レベルに応じて適切な相手を、適切な速さで巻き込めます。だからこそ、この基準は有事の最中ではなく平時に作っておくものなのです。

机上演習(TTX)で痛い経験をする ── 一般化した学び

ここまでの型(OODA・CSIRT・トリアージ)を、講義では机上演習(TTX: Table Top Exercise)で体験しました。以下は、特定のシナリオの再現ではなく、演習から引き出された一般的な学びとして整理したものです。

演習は、おおまかに「システム運用を受託する立場で、クラウド基盤のランサムウェア被害の初動を、観測 → 情勢判断 → 意思決定 → 対処の順で考える」というものでした。時系列でつながる複数の場面を、グループで議論しながら進めます。

初動・再発・クロージングで見えた盲点

演習は、時間を追って状況が悪化していく構成でした。そこで見えた盲点を、固有のシナリオから切り離して挙げます。

初動の場面: システムにアクセスできない。これは自社だけの障害なのか、利用しているサービス側の広域障害なのか。ここで Downdetector のような第三者の障害情報サイトを見て、影響範囲の当たりをつける、という動きが出ました。Downdetector は公式の検知ツールではなく、利用者の報告から障害の広がりを推測する外形的な手段です。一次情報ではないので「当たりをつける」用途に留めるのが適切です。
再発の場面: いったん復旧したと思ったら、翌日に再発。さらに脅迫文が届く(暴露型恐喝)。ここで「目の前を止める短期的対策」と「根本原因をつぶす長期的対策」を分けて考える必要が出てきました。
クロージング: 落ち着いて調べると、被害を受けたのは本番ではなくデモ環境で、実害は限定的だった、という結末でした。それでも「もし本番だったら」を考えると、対応の不備が次々と見つかります。

いちばん刺さったのは、「連絡先につながらない」「慌ててしまう」という、技術以前の生々しさでした。計画書があっても、有事には連絡が滞り、人は慌てます。だからこそ、動き方を平時に型として決めておく意味があるのだと、身をもって理解しました。

演習から持ち帰る実務原則

演習で出た学びを、実務原則として整理します。

連絡窓口を一本化する: 「何かあったらここに言う」という窓口を平時に決めておく。有事に連絡先を探すのでは遅すぎます。
24時間・365日のサポート体制を確認する: インシデントは業務時間内に起きてくれません。委託先のサポートが何時まで対応するかを把握しておきます。
サプライチェーンを把握する: 連携先がブラックボックス化していると、どこが侵入経路になりうるかが見えません。
短期的対策と長期的対策を分ける: 止血(短期)と根治(長期)を混同しないことが、混乱を防ぎます。
慌てない: 当たり前のようでいて、有事にいちばん難しい原則です。型を持っていることが、慌てない支えになります。

サイバー保険や、身代金交渉のためのネゴシエータといった選択肢の存在も話題に出ました。ただし、身代金を払うべきかどうかは、法的な論点(たとえば制裁対象への支払いになりうるリスク)も絡む難しいテーマです。ここでは「そういう選択肢と論点がある」とだけ記し、是非の断定は避けます。

再発防止は「技術・組織・人」の三層で

演習の締めは、再発防止策を「技術・組織・人」の三層で考える、というものでした。痛い経験を、次への準備に変えるステップです。ここからは、演習の生々しさから一歩引いて、再発防止を体系的に整理します。

技術面 ── マイクロセグメンテーションとゼロトラスト

技術面の代表が、マイクロセグメンテーションです。ネットワークを細かいゾーンに分け、たとえ一部が侵入されても、そこから他へ横移動できないようにする考え方です。

これは #8 で扱った「攻撃のバリューチェーン」の②水平展開(Lateral Movement)に効きます。入口を1つ破られても、内部で自由に動き回れなければ、被害は1ゾーンに封じ込められます。

この考え方を体系化したのが、NIST のゼロトラストアーキテクチャです。NIST SP 800-207 は、ゼロトラストを「ネットワークの場所による暗黙の信頼をやめ、すべてのアクセスを継続的に検証することで、攻撃者の横移動を困難にする」戦略として定義しています(NIST SP 800-207 Zero Trust Architecture)。マイクロセグメンテーションは、その実装手段の1つにあたります。

組織・人 ── インシデント対応ライフサイクルに織り込む

組織・人の面では、対応を場当たりにせず、ライフサイクルとして回します。ここで参照したいのが NIST のインシデント対応ガイドです。

NIST SP 800-61 は、最新の Revision 3(2025年4月公開)で大きく姿を変えました。正式名称は "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile" で、インシデント対応を NIST サイバーセキュリティフレームワーク(CSF)2.0 の機能に統合する形になっています(NIST SP 800-61 Rev. 3)。

CSF 2.0 の機能は、Govern(統治)・Identify(識別)・Protect(防御)・Detect(検知)・Respond(対応)・Recover(復旧)の6つです。講義のメモにあった「運用を回す5段階(識別・防衛・レスポンス・復旧・監視)」は、おおむねこの Identify・Protect・Respond・Recover・Detect に対応づけて読めます。

この図のとおり、CSF 2.0 の Govern は他の5機能を時系列でなく横断的に統べる位置づけで、Identify から Recover までを1本で流す線形プロセスではありません。

旧版の NIST SP 800-61 Rev. 2(2012年8月)は、インシデント対応を「準備(Preparation)→ 検知と分析(Detection & Analysis)→ 封じ込め・根絶・復旧(Containment, Eradication & Recovery)→ 事後活動(Post-Incident Activity)」という4フェーズのライフサイクルで説明していました。Rev. 3 はこの直線的なライフサイクルをやめ、CSF 2.0 の機能にマッピングする形へ再構成しています。古い記事や教材では4フェーズの図が今も多く使われているので、新旧の違いを知っておくと混乱しません。

ここで大事なのは、机上演習そのものが「準備(Preparation)」にあたるということです。CSF 2.0 で言えば、有事の動き方を平時に整え、痛い経験から学ぶことは Govern と Identify、そして Preparation の営みです。「CSIRT で痛い経験をちゃんとしたうえで、どうするかを考える」という講義の言葉は、まさにこのライフサイクルを回すことを指しています。

まとめ

この記事では、CySec 第8回「CSIRT起点によるセキュリティマネジメント技法」の内容を、「『気をつけます』『再発防止します』という言葉では止まらない。止めるのは、有事の OODA・機能としての CSIRT・インシデントレベルのトリアージという、平時に決めておく具体的な型である」という1本の軸で再構成しました。タイトルの「『気をつけます』では止まらない」とは、気持ちではなく型で動く、という意味です。

この記事の幹は3つです。これだけ持ち帰れば十分です。

有事は OODA で動く。 平時の改善ループ PDCA に対し、OODA(観測 → 情勢判断 → 意思決定 → 対処)は不確実な状況で素早く適応するためのループです。1周で終わらず、状況を再観測しながら回り続けます。「PDCA が時代遅れ」ではなく、場面で使い分けるものです。
CSIRT は部署ではなく機能。 専任チームを新設できなくても、有事に OODA を回す機能があればよい、というのが JPCERT/CC の整理です。検知に特化した SOC とは役割が違います。
情勢判断の核はインシデントレベルのトリアージ。 「これはレベルいくつか」を決めると、巻き込む人と動く速度が自動的に決まります。影響が広いほど、上位者が、より速く。この基準は平時に作っておくものです。

そして、これらの型は痛い経験(机上演習)を通してしか身につきません。再発防止を「技術(マイクロセグメンテーション・ゼロトラスト)・組織・人」の三層で考え、インシデント対応ライフサイクル(NIST SP 800-61r3 / CSF 2.0)に織り込んでいく。演習そのものが、その「準備」の一部です。

最後に、手を動かしてほしいことを1つ。自組織で「いま障害が起きたら、最初に何を見て、誰に上げ、どこでインシデントと宣言するか」を1枚の紙に書き出してみてください。 あわせて、インシデントレベルの基準を1つだけでも作ってみると、有事の動き方が一気に具体的になります。少し前の私は「気をつけます」としか言えませんでしたが、今は「まず観測、次にレベル判定、それから誰に上げるか」と、順番で考えられるようになりました。

#8 の最後にあった講義のメッセージ、「守るセキュリティから、つなげるセキュリティへ」は、有事の側でも同じです。守りを固めるだけでなく、有事に組織と人と委託先をつないで動けることが、安心して使えるデジタル社会につながります。ここまで読んでいただき、ありがとうございました。冒頭にも書いたとおり、私自身まだ学習中の身です。間違いや、より正確な捉え方があれば、指摘していただけると助かります。

参考資料

本記事で挙げたフレームワーク・用語・年号は、次の一次情報・公的情報で確認できます。記事中の内容は学習・執筆時点(2026年6月現在)のもので、最新は各サイトで確認してください。

※ インシデントレベルのトリアージ4段階表(レベル1=2時間/24時間体制など)は、講義で示された一例であり、特定の公的標準の数値ではありません。組織ごとに基準を調整することを前提に、「影響が広いほど上位者が短時間で対応する」という構造だけを普遍的なものとして扱っています。
※ SOC と CSIRT の役割の区切り方は組織によって幅があるため、本記事では「一般にこう整理される」という前提で書いています。
※ サイバー保険・身代金交渉・ネゴシエータについては、是非や法的論点(制裁対象への支払いリスク等)を断定せず、選択肢と論点が存在することの紹介に留めています。

あわせて読みたい

同シリーズ #1 前編: なぜ情報セキュリティは標準化されるのか ── ISO/IEC とマネジメントシステムの基礎【CySec復習ログ#1】
同シリーズ #2 後編: ISMSの歴史と2022年大改定 ── BS7799からリスクマネジメント(ISO 31000)まで【CySec復習ログ#2】
同シリーズ #3: 内部統制を「リスク(脆弱性)に打つ実装戦略」として理解し直す【CySec復習ログ#3】
同シリーズ #4: 「ルールを守っているか」では、セキュリティは守れない ── 準拠性監査から有効性監査へ【CySec復習ログ#4】
同シリーズ #5: 暗号の歴史は「秘密を小さくする」歴史 ── シーザー暗号からTLS 1.3へ【CySec復習ログ#5】
同シリーズ #6: その多要素認証、どの攻撃に効いてますか？ ── 脅威で認証を整理し直す【CySec復習ログ#6】
同シリーズ #7: 数学的に安全な暗号が寿命を迎える2つの理由【CySec復習ログ#7】
同シリーズ #8: ランサム攻撃は「単発事件」ではなく「分業された産業」── MITRE ATT&CKで攻撃の連鎖を読む【CySec復習ログ#8】 ← 本記事(#9)の「平時・捉え方編」にあたるペアです。攻撃の分業化・RaaS・ATT&CK・3事例はこちらで扱っています。
同じ「復習ログ」シリーズ(セキュリティ資格の学習ログ)。CCT Day3 はインシデント対応・フォレンジック・BC/DR を扱う回で、本記事の有事対応と地続きです。