インシデント対応フローは「描いて終わり」じゃない ── 机上演習で作って・壊して・連絡手段まで決める【CySec復習ログ#11】

Last updated at 2026-08-25Posted at 2026-08-23

はじめに

少し前の私は、「OODA で回す」「インシデントレベルでトリアージする」「RFC2350 で自己紹介状を書く」という型を、本やスライドでひととおり学んだ気になっていました。ところが、いざ「では、あなたの組織のインシデント対応フローを1枚描いてください」と言われると、白紙のまま手が止まったのです。

検知源の箱までは描けます。けれど、「どこに連絡が来て」「誰が受けて」「どの相手に、どの手段(電話なのか、暗号化メールなのか)で連絡するのか」を線でつなごうとすると、急に解像度が落ちました。さらに、たとえ全部きれいに描けても、「で、有事に一番詰まるのはどこ?」と聞かれると、自分では答えられませんでした。型は知っている。でも、手が動かない。これが少し前の私でした。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログで、シリーズ通し番号では #11 です。このインシデントレスポンス演習は2日間の演習で、1日目(シリーズ #10)に RFC2350 の CSIRT 記述書(自己紹介状)を作り、2日目(本記事 #11)で、その記述書を出発点に対応フローを作図します。

想定読者は、少し前の私と同じく、型(OODA・トリアージ・RFC2350)は本で読んだけれど、自組織の対応フローを実際に作図したことがなく、「計画は作って終わり」になりがちなエンジニア・情シス・セキュリティ担当です。資格学習中の方や、社内で体制づくりを任され始めた方を念頭に置いています。

本記事は、#9・#10 で学んだ型を「手に動かす実践編」です。三部作の着地点にあたります。

#9 は「有事の動き方編」。OODA(観測 → 情勢判断 → 意思決定 → 対処の適応ループ)と、インシデントレベルのトリアージ(緊急度の切り分け)で、攻撃を受けたあとにどう動くかを理解する話でした。
#10 は「平時の宣言編」。本演習の1日目にあたり、RFC2350 という自己紹介状で「何を守るか(Constituency)・何をして・何はしないか」を書く話でした。本記事は、この1日目に書いた自己紹介状をそのまま下敷きにします。
そして本記事(#11)は、その型と1日目の記述書を使って、実際に対応フローを作図し、壊して(弱点を炙り出して)、相手ごとに連絡手段まで決める、組み立ての実践編です。

OODA・トリアージ・RFC2350・Constituency といった型そのものは、#9・#10 で扱ったため、ここでは深追いしません。必要なところで #9・#10 にリンクで送り、本記事は「演習で手を動かす」一点に集中します。

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

インシデント対応フローは「描いて終わり」ではない。価値は、描いたフローから「有事に一番詰まる1か所」を炙り出し、相手ごとに連絡手段まで決めておくことにある。机上演習は、それを平時に安全に体験するための装置である。

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

対応フローは「描く」だけでは半分。価値は「壊して・つなぐ」にある。 描いたフローから有事に一番詰まる1か所を選び、相手ごとに連絡手段まで決めて、はじめて使える計画になります。
「一番詰まる1か所」を1つだけ選ぶ。 あれもこれもは回りません。最弱点(連絡先につながらない・24時間体制の切れ目・クローズ要件の曖昧さなど)に資源を集中するのが、演習後半の肝です。
相手で連絡手段は変わる。 報告者には暗号化メールや Web フォーム、法執行機関には電話と正式文書。「速さ」より「本物の相手か(真正性)」と「記録が残るか」で選びます。

読み終えたとき、自組織の対応フローを「描いて終わり」にせず、「ここが一番詰まる。だからこの相手に、この手段で連絡する」と1か所まで具体化できるようになっていれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

演習の全体像 ── 「描く → 壊す → つなぐ」の3ステップ

「インシデントレスポンス演習」は、丸2日かけてインシデントレスポンスを体験する演習でした。1日目(第9回)はウォーミングアップと、CSIRT 体制をめぐる演習で、RFC2350 にもとづく CSIRT 記述書(自己紹介状)を作りました(→ #10)。2日目(第10回=本記事)は、その記述書を出発点に、グループでインシデント対応計画を組み立て、最後に発表する、という流れです。

演習の狙いは、講義の言葉を借りると「できるだけ現場の感覚に近づけてやってみる」「対応の現場とどうコミュニケーションを取るのかを体験する」ことでした。読むだけ・聞くだけでは身につかないものを、手を動かして掴む時間です。

この2日間を、自組織でも再現できる最小ステップに抽象化すると、次の3つになります。本記事の章立ても、この3ステップに沿っています。

描く: CSIRT の対応プロセスを中心に、検知から解決までのフローを作図する。
壊す: そのフローの中から「有事に一番詰まる1か所」を選び、どう低減・回避するかを考える。
つなぐ: 組織の外とやり取りする箇所について、相手ごとに連絡手段まで決める。

演習が前提にする3つのおさらい

演習に入る前に、講義は3つの前提を繰り返し確認しました。いずれも #9・#10 で詳しく扱った内容なので、ここでは箇条書きで思い出すだけにとどめます。

すべては守れない(事故前提): 100%守り切ることはもう現実的ではありません。攻撃を受けたあとのことも織り込み、対応時間の短縮を重視します。
「何を守るか」から始める: 守り方ではなく、「何が起こってほしくないか」「何を守りたいか」という価値観を先に決めます。これが RFC2350 でいう Constituency(守るべき対象)で、フロー作図もここが定まってからです(→ #10)。
一人ではやりきれない: だから組織で役割分担し、さらに外部とも連携します。CSIRT は、その役割分担の結果として現れる機能です(→ #9)。

この3つを前提に、いよいよフローを描きます。

ステップ1:対応フローを「描く」 ── 段階ボックスと登場人物

最初のステップは、検知から解決までの対応フローを1枚に描くことです。2日目の演習は、まず1日目に作った CSIRT 記述書(自己紹介状)をグループで紹介し、「自分たちは何を守る CSIRT なのか」を共有するところから始まりました。守る対象(Constituency)を確認したうえで、いきなり自由に描くのではなく、用意された凡例(部品)を使ってフローを組み立てます。この部品立てが、そのまま自組織で描くときの足場になります。

部品は大きく2種類です。1つは、対応がどの段階にあるかを示す段階ボックス。もう1つは、フローに登場する関係者です。

段階ボックス: 受付 → 内容確認 → 解析 → 処理 → 解決。インシデントが、どの段階を通って解決に向かうかを示します。
関係者: 報告者・被害者・攻撃者・法執行機関・JPCERT/CC など。誰が登場し、誰と誰がやり取りするかを示します。

そして演習には、1つ重要なルールがありました。組織の外とやり取りする箇所には、情報伝達方法(連絡手段)も必ず書く、というものです。社内で完結する線は手段を省いてもかまいませんが、外に出る線は「どうやって連絡するか」まで明記します。この一手間が、後のステップ3で効いてきます。

検知から解決までの全体像を、JPCERT/CC の「CSIRTガイド」が示す対応サイクルに沿って整理すると、次のようになります。

ここで用語の出どころを整理しておきます。この図のサイクル(検知源 → トリアージ → インシデント報告 → 解決フェーズ)は JPCERT/CC「CSIRTガイド」の対応プロセスに沿ったもので、組織が対応をどう回すかという大きな流れを表します。一方、先に挙げた段階ボックス(受付 → 内容確認 → 解析 → 処理 → 解決)は演習で配られた凡例で、1件のインシデントが解決に向かう細かい進み具合を表します。両者は粒度が違い、段階ボックスは図の「解決フェーズ」の内側で1件ずつ進んでいくもの、と捉えると混乱しません。

この図は、JPCERT/CC「CSIRTガイド」が示す対応プロセス(複数の検知源 → トリアージ → インシデント報告 → 解決フェーズのサイクル)の構造を、筆者が要約して描き直したものです。原図そのものの転載ではありません。正確な図と記述はJPCERT/CC「CSIRTガイド」を参照してください。

検知源は「複数の入口」がある前提で描く

図のいちばん上に注目してください。検知源は1つではありません。監視ログのような技術的な入口だけでなく、電子メール、お客様窓口、外部からの連絡(取引先や JPCERT/CC 経由など)と、入口は複数あります。

ここを「監視ログから1本」だけで描いてしまうと、現実とずれます。実際には、社外からの問い合わせで初めて異変に気づく、ということが珍しくありません。複数の入口があり、そのどれもがトリアージへ合流する、という形で描くのが、現実に近いフローです(検知=観測の話は OODA の Observe にあたります。詳しくは → #9)。

ステップ2:フローを「壊す」 ── 一番詰まる1か所を炙り出す

ここが、この記事のいちばんの核です。演習の後半は、描いたフローを眺めて、「最も対応上の問題となり得る部分」を1つだけ選び、そのリスクをどう低減・事前回避するかのアイデアを出す、というものでした。

ポイントは「1つだけ」というところです。フローを描くと、気になる箇所はいくつも出てきます。それでも、あえて最弱点に絞り込みます。理由はシンプルで、あれもこれもと手を広げると、結局どれも回らないからです。一番痛いところを見定めて、そこに資源を集中する。これは平時に何度でもやり直せる、安全な思考実験です。

では、どこが詰まりやすいのか。演習や講義で挙がった「詰まりやすい所」を類型化すると、次のようになります。自分のフローを見て、どれが一番痛いかを選ぶ材料にしてください。

詰まりやすい所	何が起きるか	平時にできる手当て
連絡先につながらない	一報を上げたいのに担当に届かず、初動が遅れる	連絡窓口を一本化し、不在時のエスカレーション先まで決めておく
24時間体制の切れ目	委託先のサポートが夜間・休日に止まり、対応が翌営業日まで待ちになる	委託先のサポート時間(24時間365日か)を契約・運用の両面で確認する
対外連携の判断者が不在	「法執行機関に連絡してよいか」を誰も決められず、止まる	レベルごとに「誰が外部連携を判断するか」を平時に決めておく
クローズ要件が曖昧	「もう終わってよいのか」が決まらず、対応がだらだら続く	後述の「クローズ要件」を平時に定義しておく

これらは、いずれも高度な攻撃技術の話ではありません。「連絡がつかない」「誰が決めるか決まっていない」といった、技術以前の生々しい詰まりです。だからこそ、平時に1か所選んで潰しておく価値があります。

「クローズ要件」を平時に決めておく

詰まりやすい所のうち、見落とされがちなのがクローズ要件です。これは「どうなったら、このインシデントは終わったと言えるか」という、対応を締めくくる条件のことです。

クローズ要件を決めていないと、対応が締まりません。「もう大丈夫そう」という空気で終わらせてしまい、後から再発したときに「あれは終わっていたのか、続いていたのか」が曖昧になります。逆に、終わらせる条件が明確なら、対応チームは安心して手じまいでき、関係者にも「ここで一区切り」と説明できます。

講義では、クローズ要件の作り方として、リオープン(再開)を許容するという考え方も示されました。いったんクローズしても、新たな兆候が出たら同じインシデントとして再開できるようにしておく、という割り切りです。「完全に終わったと言い切れないなら、いったん閉じて、必要なら開け直せばよい」という設計にしておくと、無理に白黒つけずに前へ進めます。クローズ要件は「終わりの線を引くこと」と「引き直せる余地を残すこと」の両方を含む、と捉えると実務的です。

ステップ3:相手ごとに「つなぐ」 ── コミュニケーション手段の使い分け

3つめのステップは、ステップ1で「外に出る線には手段を書く」と決めたルールの回収です。組織の外とやり取りする箇所について、相手ごとに連絡手段を決めます。

演習で示された、相手別の連絡手段の一例が次の表です。

相手	主な連絡手段	重視する性質
報告者(社員・顧客など)	暗号化メール / Web フォーム / 電話	真正性(本物の本人か)
法執行機関	電話(初期連絡)+ オフィシャルレター(正式文書)	記録性(やり取りを正式に残す)
対外連携先(他組織の CSIRT など)	暗号化された電子メール	真正性 + 守秘性

上の表は、講義で示された一例です。具体的な手段は、相手や状況、組織のルールによって変わります。

ここで大事なのは、相手によって、選ぶ基準が「速さ」ではないということです。インシデント対応は時間との戦いなので、つい「いちばん速い手段で」と考えがちです。けれど、外部連絡で本当に効くのは、速さよりも次の2つです。

真正性(本物の相手か): その通報は、本当に本人から来たものか。逆に、こちらが連絡する相手は、本物の窓口か。攻撃者がなりすまして混乱させてくる可能性まで考えると、相手を確認できる手段(暗号化メールの署名など)が要ります。この「真正性」は、RFC2350 の安全な通信の文脈で出てくる "A"(Authenticity)と同じ発想です(→ #10)。
記録性(やり取りが残るか): 特に法執行機関とのやり取りは、後から「いつ・何を伝えたか」が問われます。初期は電話で速報しつつ、正式には文書で残す、という二段構えになるのはこのためです。

「外に出る線には手段を書く」というルールは、こうして「相手ごとに、真正性・記録性・守秘性のどれを優先するか」を考えさせるための仕掛けだったわけです。

演習で見えた「現場のギャップ」 ── 計画と実務のあいだ

ここまでが、演習で手を動かす3ステップです。最後に、演習を通して見えた「計画と現場実務のあいだのギャップ」に触れておきます。きれいなフローを描いても、現場では思わぬところでつまずく、という話です。

そもそも講義は、「100%守り切るのは難しい」「相手は悪意を持った人間で、対応時間の短縮が大事」「CSIRT は一つの組織だけでやりきるのではなく、外部と連携しながらやる」という前提から出発しています。フローはあくまで地図であって、地図どおりに現場が動くとは限りません。代表的なギャップを2つ挙げます。

「払うと決めても、すぐには払えない」

ランサムウェア被害で、身代金を払うと決断したとします。支払いは暗号資産(ビットコインなど)を求められることが多いのですが、ここに実務上のギャップがあります。払うと決めても、すぐには払えないのです。

事業として暗号資産を平時に保有・即時調達する手段を持っていない組織は少なくありません。いざ支払うとなると、暗号資産交換業者の口座を用意し、本人確認(KYC)を済ませ、社内の決裁を通し、という手順を踏むことになります。国内の交換業者では、本人確認自体は最短で即日〜数日というケースもあります(暗号資産の利用者のみなさまへ(金融庁))。ただし、法人としての口座開設、大口の入金、社内承認まで含めると、攻撃者が突きつける期限に即応できるとは限りません。

つまり「払う・払わない」という意思決定の手前に、「そもそも実行できる状態にあるか」という準備の問題が横たわっています。これも、平時に考えておくべき論点の1つです。

そもそも「払うべきか」には法的論点がある

実行できるかどうか以前に、「払うべきか」自体が難しいテーマです。ここには法的な論点が絡みます。

米国財務省の OFAC(外国資産管理室)は、ランサムウェアの身代金支払いを仲介・実行することの制裁リスクについて勧告を出しています。初版は2020年10月、更新版は2021年9月21日に公表されました。支払先が制裁対象者(SDN リスト掲載者など)であった場合、たとえ被害者であっても、その支払いの仲介・実行が制裁違反になりうる(しかも厳格責任で問われうる)、という内容です。同日には、ランサムウェアの資金洗浄に関与したとして、暗号資産交換業者に対する初の制裁指定も行われました(OFAC のランサムウェア支払いに関する更新ガイダンスの解説(Covington / Inside Privacy))。

これは米国の制度なので日本の組織にそのまま適用されるわけではありませんが、グローバルに事業を展開する組織や、海外の保険・対応事業者を使う場合には無視できない論点です。サイバー保険や、身代金交渉を担うネゴシエータといった選択肢の存在も、講義では話題に出ました。ただし、いずれも「そういう選択肢と論点がある」という紹介にとどめ、是非の断定は避けます。ここでも軸は、平時にこうした論点を知り、判断の前提を整えておくことです。

机上演習は「準備」そのもの ── 安全に痛い思いをする装置

最後に、演習という形式そのものの意味を確認しておきます。机上演習は、遊びでも研修のためのお飾りでもなく、インシデント対応の準備(Preparation)そのものです。

NIST のインシデント対応の考え方でも、CSF 2.0 の機能でいう Govern・Identify でも、「有事の動き方を平時に整え、痛い経験から学ぶこと」は準備の中核に置かれています(→ #9)。演習で「連絡先につながらない」「クローズ要件が決まっていない」と痛い思いをしておけば、本物の有事で同じ場所に落ちずに済みます。安全に痛い思いをするための装置、というわけです。

そして心強いことに、演習の教材は独学でも手に入ります。ENISA(欧州連合サイバーセキュリティ機関)は、CSIRT 向けの演習教材を公開しており、その1つに、トリアージと基本的なインシデント対応を扱う "Triage and Basic Incident Handling" があります(ENISA CERT Exercises and training material)。教える側のハンドブックと学ぶ側のツールセットが揃っているので、グループがなくても流れを追体験できます。日本語では、JPCERT/CC が CSIRT 構築・運用を支援するマテリアルを公開しています(JPCERT/CC CSIRTマテリアル)。

結局のところ、フローは読むだけ・眺めるだけでは身につきません。実際に描いて、壊して、つないでみて、はじめて「ここが詰まる」と気づけます。これは #10 で書いた「自己紹介状は書いてみて初めて気づく」という話と、根は同じです(→ #10)。

まとめ

この記事では、CySec 第10回「インシデントレスポンス演習」の内容を、「インシデント対応フローは描いて終わりではない。価値は、有事に一番詰まる1か所を炙り出し、相手ごとに連絡手段まで決めておくことにある。机上演習は、それを平時に安全に体験するための装置である」という1本の軸で再構成しました。タイトルの「描いて終わりじゃない」とは、描いたフローを壊して(弱点を見つけて)、つなぐ(連絡手段を決める)ところまでやって初めて使える、という意味です。

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

対応フローは「描く → 壊す → つなぐ」の3ステップで仕上げる。 検知源は複数の入口がある前提で描き(描く)、有事に一番詰まる1か所を選び(壊す)、外に出る線は相手ごとに連絡手段まで決めます(つなぐ)。描いただけでは半分です。
「一番詰まる1か所」を1つだけ選ぶ。 あれもこれもは回りません。連絡先につながらない・24時間体制の切れ目・対外連携の判断者不在・クローズ要件の曖昧さといった、技術以前の詰まりに資源を集中します。クローズ要件は、リオープンを許容する設計にしておくと実務的です。
相手で連絡手段は変わる。基準は「速さ」ではない。 報告者には真正性、法執行機関には記録性、対外連携には真正性と守秘性。本物の相手か、記録が残るか、で手段を選びます。

そして、これらは机上演習という「準備」を通してしか身につきません。演習で安全に痛い思いをしておくことが、本物の有事で同じ場所に落ちないための一番の近道です。

「描く → 壊す → つなぐ」を自組織で1周するための手順を、1枚の表にまとめておきます。次の宿題は、この表をそのままなぞる形で進められます。

ステップ	自組織でやること	自分への問い	出力物
描く	検知から解決までを1枚に。外に出る線には連絡手段の欄を付ける	入口が監視ログ1本になっていないか?	フロー図1枚
壊す	一番詰まる箇所を1つだけ選ぶ	連絡がつかない/誰が決めるか未定の箇所はどこか?	最弱点1つ + 手当て案
つなぐ	その相手への連絡手段を1つ決める	速さでなく真正性・記録性で選べているか?	相手1件の連絡手段

最後に、手を動かしてほしいことを1つ。自組織のインシデント対応フローを1枚描き、有事に一番詰まる1か所を選び、その相手への連絡手段を1つ決めてみてください。 描く・壊す・つなぐを1周するだけで、「計画はある」が「動ける」に一歩近づきます。少し前の私は、型は知っていても白紙の前で手が止まりましたが、いまは「ここが一番詰まる。だからこの相手に、この手段で連絡する」と、1か所まで具体化できるようになりました。

この実践編(#11)で手を動かす土台になったのは、「有事の動き方」を扱った #9(OODA・トリアージ)と、「平時の宣言」を扱う #10(RFC2350)です。特に #10 は、本演習の1日目にあたる回です。そこで作った自己紹介状(CSIRT 記述書)を、本記事の2日目でそのまま対応フローへ落とし込みました。平時に何を宣言し、有事にどう動き、それを演習でどう手に馴染ませるか。3つは表裏一体です。ここまで読んでいただき、ありがとうございました。冒頭にも書いたとおり、私自身まだ学習中の身です。間違いや、より正確な捉え方があれば、指摘していただけると助かります。

参考資料

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

※ 本文の対応フロー図は、JPCERT/CC「CSIRTガイド」が示す対応プロセスの構造を筆者が要約して描き直したものであり、原図そのものの転載ではありません。正確な図と記述は同ガイドを参照してください。
※ インシデントの段階ボックス(受付 → 内容確認 → 解析 → 処理 → 解決)、トリアージの考え方、相手別の連絡手段の対応表は、いずれも講義で示された一例です。具体的な区分・手段は組織ごとに調整することを前提に、「複数の入口がトリアージへ合流する」「相手によって優先する性質(真正性・記録性・守秘性)が変わる」という構造だけを普遍的なものとして扱っています。
※ ランサムウェアの身代金支払いについては、「払うと決めても即座には実行できない」という準備上のギャップと、OFAC の制裁リスクという法的論点を紹介するにとどめ、支払いの是非は断定していません。国内の暗号資産交換業者における口座開設・本人確認の所要期間は事業者や条件によって異なるため、本記事では特定の日数を断定せず、一次情報(金融庁)へのリンクにとどめています。