1.　はじめに

インターネット接続された情報システムは常に外部からの攻撃に晒されており，今や情報セキュリティ技術は社会インフラである情報システムを守るために不可欠な要素となった．一方で，情報システムは規模や要求の多様化により複雑化しており，これらを管理・運用する技術者にも幅広い技術領域の習熟を要求している．さらに，情報システムの社会的重要性の増大とともにシステム管理者には法的・社会的な責任も求められるようになった．このような職責を担える優秀な技術者の不足は深刻な社会課題となっており，国を挙げた情報セキュリティ人材の育成が強く望まれている．

情報セキュリティを取り巻く状況は国際的にも同様であり，情報セキュリティ人材の育成が積極的に実施されている．コンテストは人材育成イベントの代表例であり，国際的にはDEF CON [1]，日本ではSECCON [2]など，いわゆるCTF（Capture The Flag）と呼ばれる形式のコンテストが数多く実施されている．CTFでは，典型的にはサーバへの侵入速度を競うなど，主に技術力が問われる．一方で，実際の情報システム管理・運用業務においては技術力だけでなく，社会的に妥当な対応をするための法的・社会的知識や協調力なども必要であり，CTFで優秀な技術者が必ずしも情報システム管理・運用の現場業務でも優秀とは限らない[3], [4]．

我々は，情報システムの管理・運用現場で役立つ実践的な情報セキュリティ人材を育成するために，情報セキュリティ演習およびコンテストを実施してきた．教育的取組として実施してきたコンテストは，情報セキュリティ演習の拡張として捉えることができ，情報危機管理コンテスト[5]として2024年には第19回を迎える年一回の恒例イベントとして定着している．本コンテストは情報システムを管理・運用する情報セキュリティ技術者としての総合力が問われる稀有なコンテストであり，その独自性と教育効果の高さから，コンテスト勝者には経済産業大臣賞と文部科学大臣賞が与えられるなど，社会的にも高く評価されている．本稿は，これまでの情報危機管理コンテストの取組を俯瞰して紹介すると同時に，本情報セキュリティ演習の根底にある人材育成の考え方やコンテストの実施・運用方法を述べる．

本稿の構成を以下に示す．第2章では情報セキュリティ技術者の人材育成の背景として，基底となる考え方を述べたうえで，日本における人材教育の取組を紹介する．第3章では，情報危機管理コンテストの基礎となる情報セキュリティ演習における技術的環境について述べる．第4章では，情報セキュリティ演習の運営方法を述べ，第5章では演習のシナリオ設計について述べる．第6章では，本演習をコンテストとして実施する際の取組について述べる．第7章で課題と展望を述べたうえで，第8章で本稿をまとめる．

2.　情報セキュリティ技術者の教育

2.1　国内における情報セキュリティ技術者の教育の背景と要件（求められる人材像）

サイバーセキュリティ基本法第1条[6]によれば，「インターネットその他の高度情報通信ネットワークの整備および情報通信技術の活用の進展に伴って世界的規模で生じているサイバーセキュリティに対する脅威の深刻化その他の内外の諸情勢の変化に伴い，情報の自由な流通を確保しつつ，サイバーセキュリティの確保を図ることが喫緊の課題となっている」とされている．しかし，ISC2の調査[7]によると，日本国内のサイバーセキュリティ人材は2023年現在で約48万人おり，約11万人が不足している．人材不足を解消する情報セキュリティ人材の育成が急務である．

情報処理の促進に関する法律の第6条[8]では，その人材像を「サイバーセキュリティに関する相談に応じ，必要な情報の提供および助言を行うとともに，必要に応じその取組の実施の状況についての調査，分析および評価を行い，その結果に基づき指導および助言を行うことその他事業者その他の電子計算機を利用する者のサイバーセキュリティの確保を支援することを業とする」としている．また，経済産業省とIPAのデジタルスキル標準Ver.1.2 [9]では，デジタル人材を5つの人材類型の1つとして「サイバーセキュリティ」が示されており，その人材像は『デジタル技術を活用した製品・サービスの展開において，それらのセキュリティが確保されていることは必須の前提条件である．（中略）多様なキャリアの人材が「サイバーセキュリティ」で備えるべきスキルを習得し，インシデントの未然防止・被害抑制のために活躍することが想定される』としている．これらの記述から，日本において情報セキュリティ技術者に求められている人材像は，多様な組織の関係の中で状況に応じて効果的に情報セキュリティ業務を実践できる人材と考えられる．

2.2　情報セキュリティ技術者の育成方法

一般的な学習モデルには「学習転移モデル」「経験学習モデル」「批判的学習モデル」などがあり，中でも「経験学習モデル」は，情報セキュリティ業務を組織の中で，効果的に実践できる人材を育成するための効果的なモデルと考えられる．その中で特に良く知られているのは，デビッド・コルブが提示した「経験学習モデル（experiential learning model）」である[10]．経験学習モデルは，経験と学習に関する過程を「活動–内省」「経験–抽象」という二軸からなる論理空間に構成し直し，これら諸関係の間に循環型サイクルを仮定して学習モデルとして構築したものである（図1）．

「具体的経験」とは，学習者が環境（他者・人工物等）に働きかけることで起こる相互作用を指し，この経験は価値中立的とされる．「内省的観察」とは，「ある個人がいったん実践・事業・仕事現場を離れ，自らの行為・経験・出来事の意味を，俯瞰的な観点，多様な観点から振り返ること，意味づけること」を指す．（「内省」「省察」「リフレクション」「反省的思考」と呼ばれることも多い．）振り返る対象は「経験の結果」や，それを左右する「プロセス」である．「抽象的概念化」とは，経験を一般化，概念化，抽象化し，他の状況でも応用可能な知識・ルール・スキーマやルーチンを自ら作り上げることを指す．このモデルにおける学習とは，「経験–内省のプロセスを通じて，経験そのものを変換し，こうしたルール・スキーマ・知識を作り出すプロセス」とされる．最後の「能動的実験」は，経験を通して構築されたスキーマや理論が実践され，そこから後続する経験や内省を生み出すプロセスである．以上に示したように，経験学習モデルにおいては「能動的実験・具体的経験」と「内省的観察・抽象的概念化」という2つのモードが循環しながら，知識が創造され，学習が生起すると考えられている．

経験学習モデルに基づいた学習方法の一例としてアクションラーニングが挙げられる[11]．アクションラーニングの第一人者であるマイケル・K・マーコードによると，この方法は「個人や組織の実務能力を深めるために，現実の問題・課題を題材に質問を中心とした小グループによるディスカッションで策を考え・実施することで，実務上の問題解決や課題達成の中でリフレクション（内省）しながら，個人やグループ・組織が学習していくプロセスである」とし，一般的な4つのプロセスを示している（表1）．

このほかにゲーム性のあるグループ学習で教育の設計・評価に使われるものに「RETAINモデル」がある[12]．「RETAINモデル」は，シリアスゲームの評価指標としてGunterらによって2008年に提唱された．後述するとおり，実践的な情報セキュリティ教育では，イベントやコンテスト形式のものが多く，ゲームを課題に置き換えてこのモデルを利用することがある（表2）．

情報セキュリティ業務の多くはグループという体制で実施される．そのため，知識や技術だけでなく，コンプライアンス，チームワーク，様々なステークホルダとの円滑コミュニケーション，などの幅広いスキルが必要となる．このため，情報セキュリティ技術者の教育において，実践的知識や上述のようなスキルを身に着けさせるためには，実際の業務や体制，役割に基づく育成が効率的である．その実践として，幅広いスキルを，経験を通じて習得できる経験学習が有効に働く．さらには，経験学習の中で実際の業務を疑似体験できるように，業務の体制やプロセスに従い，ケースやインシデントシナリオに基づいてグループ学習を行うことが学習効果を向上すると考えられる．

特に本情報セキュリティ演習においては，RETAINモデルの各項目の実施を意識して経験学習プロセスを設計している．具体的には，現実のインシデントに基づいてシナリオを構築し，チームの役割分担の中で解決を目指すことで実現性（R）と埋め込み（E）を担保する．単に解法を覚えるだけでなく，メタな考え方やノウハウの形で経験させることによって，本演習の経験を幅広い事例に知識展開（T）でき，それらを自分なりに活用する経験により発展的な自己学習である知識取得促進（A）が可能になる．また，コンテスト運営チーム等の関係者やチームメンバとの相互関係の中の学習であることから，演習に集中し，積極的参加（I）する体制が整っている．コンテスト形式として競争を導入する場合にはこの効果がより強まると考えられる．最後に，本演習の参加者は他のコンテストや教育プログラムにも参加していることが多く，複数年にわたって本演習やコンテストに参加する学生も多いことから，継続した関連学習の中で得られた知識や経験をその後も活かせる場合が多く，知識定着（N）の効果もあると考えられる．このように，本演習は全体としてRETAINモデルを意識した構成になっている．

実際の学習スキルとの具体的な対応は，先述のデジタルスキル標準Ver.1.2 [9]に基づいて説明する．本標準の中のロール「サイバーセキュリティマネージャー」と「サイバーセキュリティエンジニア」が主たる育成対象になるが，この中で重要度が高い（重要度a）スキルとして挙げられているのは，セキュリティカテゴリの中では「セキュリティ体制構築・運営」「セキュリティマネジメント」「インシデント対応と事業継続」「プライバシー保護」「セキュア設計・開発・構築」「セキュリティ運用・保守・監視」の6項目である．これらの技術を現場活用できる水準で身につける必要があり，これらを意識したシナリオ設計や運営を行っている．なお，その他にも，ソフトウェア開発サブカテゴリを中心に重要度aやbの項目があり，これらも一定程度に意識している．

2.3　若年層を対象とした情報セキュリティ教育の取組み

本節では，若年層（25歳以下）を対象とした日本の主な情報セキュリティ教育事例を紹介する．若年層を対象とした教育の取組みでは，先述の「経験学習」「アクションラーニング」などのモデルを取り入れたイベントやコンテスト形式のものがほとんどである．参加者の動機付け効果の促進や経験学習の効果等を期待するためと考えられる．

（1）セキュリティ・キャンプ[13]：セキュリティ・キャンプは，若年層の情報セキュリティ意識の向上，並びに将来第一線で活躍できる高度な情報セキュリティ人材を発掘・育成する場として，一般社団法人セキュリティ・キャンプ協議会（以下，セキュリティ・キャンプ協議会）とIPAにより運営されている．セキュリティ・キャンプのメインイベントである「セキュリティ・キャンプ全国大会」は年1回，主に夏休み期間中に4泊5日の合宿形式の勉強会である．このほか，全国各地で1～2日間の勉強会「セキュリティ・ミニキャンプ」などが開催されている．

（2）SecHack365 [14]：SecHack365は，国立研究開発法人情報通信研究機構（NICT）のナショナルサイバートレーニングセンターにより，25歳以下を対象に，社会を脅かすサイバーセキュリティ上の課題を分析研究したうえで，解消アイデアを創出し解決策を実装する力を持った人材の育成を目的として，2017年度から実施されている．現在は5種類のコースが用意されており，年6回のイベントと通年（365日）のオンライン指導で参加者の研究・開発を支援する仕組みからなるプログラムである．

（3）SECCON [2]：SECCON（SECURITY CONTEST）は，情報セキュリティをテーマにした多様な競技を開催する「CTF」と呼ばれる情報セキュリティコンテストイベントである．CTF（Capture The Flag）は攻撃・防御両者の視点を含むセキュリティの総合力を競うハッキングコンテストである．特定非営利活動法人日本ネットワークセキュリティ協会（JNSA）内に設置されたSECCON実行委員会が運営する．SECCONは年間を通じて複数のプログラムを実施しており，技術の実践の提供，および実践的な情報セキュリティ人材の発掘・育成に貢献している．メインのSECCONのほか，未経験者や初心者を対象としたSECCON Beginners，女性を対象としたCTF for GIRLS，情報セキュリティ技術について学ぶワークショップSECCON Workshopなどが開催されている．

（4）情報危機管理コンテスト[5]：情報危機管理コンテストは，毎年5月に開催される「サイバー犯罪に関する白浜シンポジウム」の会場で並行して行われる，サイバーセキュリティ人材の育成を目的としたコンテストである．参加者は，主に大学や高専，専門学校の学生や生徒であり，2024年で19回目の開催になる．毎年，全国から多数のチームが参加しており，遠隔環境で実施される第1次，第2次の2段階の予選を経て，5チームが本会場での決勝進出となる．

3.　情報セキュリティ演習環境の構築

前章で述べてきたように，日本国内外では，情報セキュリティ人材を育成するために様々な取組みがなされてきた．我々も，和歌山大学内では，enPiT-Security学部向けBasic SecCap [15]で連携校として「インシデントレスポンス演習」を，社会人向けのenPiT-Pro Security [16]では同じく連携校として「インシデントレスポンス実践（ProSec-IR）」を実施している．和歌山大学外では，enPiT-Security大学院向けSecCap [17]では奈良先端科学技術大学院大学で「情報危機管理演習」を担当している（旧IT-KEYSより継続）．

上記の取組みでは，受講対象のそれぞれに対して内容に工夫を施しており，構成や内容に違いを持たせている．本稿では，上記の情報セキュリティ演習の中でも，これらすべての源流となった「情報危機管理コンテスト」[5]に基づいて述べる．本章からは，情報危機管理コンテストにおける概要，構成，運用と設計について述べる．情報危機管理コンテストは，学術である我々が企画することもあり，単なる知識やスキルを競うものではなく，教育的な効果や社会的な意義を意識して設計している．本章と次章で，本情報セキュリティ演習の教育面を支える基本的な仕組みや運用方法を述べ，5章ではシナリオ構築について述べる．6章では本演習をコンテストとして運用するための仕組みを述べる．

3.1概要

詳細は第6章で述べるが，情報危機管理コンテストは令和6年度で第19回を数えるコンテストである．我々は主担当として，本コンテストを企画，設計，構築，検証，および運用をしてきた．本コンテストは，一般的なCTFがレッドチームとブルーチームに分かれて競技することに相似して，運営側と参加者側に分かれて進行する．すなわち，運営側が脆弱性などを持たせたサーバやネットワークを提供し，インシデントをリアルタイムで発生させて，参加者側はこれに対応する．コンテストの母体である白浜シンポジウムは大学，自治体に加えて警察も主催に加わっており，クラッキングのスキルを競うコンテストにおいて，優秀者を表彰することが困難であることから本コンテストが企画された．

参加者側は，与えられた環境を運用している仮想企業に派遣された運用保守員として，コンテストに参加していただく．運営側は，当該環境に対して攻撃をするだけでなく，当該仮想企業における統括責任者（派遣先の上司役）や，当該環境上で提供されるサービスを享受するユーザ役を演じる．すなわち，運営側から参加者側に対してクレームが入り，参加者側は運営側に対して状況報告や作業実施の許可申請をするような，社会的な制約が発生する．実機を用いた，単なる技術的な知識をスキルを競うだけでなく，社会的な制約を伴う稀有なコンテストである．以下に，情報危機管理コンテストの構成について述べる．

3.2　ハードウェア構成

情報危機管理コンテストでは，参加者は複数のサーバやネットワーク機器を操作する必要がある．2次予選と決勝選において，参加チームが管理する構成はほぼ同じである．2次予選および決勝戦のシステム構成図を図2に示す．2次予選は各参加チームそれぞれの場所からIPsec-VPNを使い，リモート環境からのコンテスト環境にアクセスを実現している．

サーバはFreeBSDおよびRocky Linuxを使用している．FreeBSD上ではDNSサーバ，Apacheサーバ，mysqlサーバ，メール関連サーバなどが稼働している．それに対しRocky Linux上ではFreeBSDと同様にApacheサーバ，mysqlサーバ，メール関連サーバに加えてtomcatサーバやsyslogサーバなどが稼働している．ネットワーク機器は，YAMAHA製ルータ2台，Cisco製ASA1台，Cisco製L3スイッチ1台，アプレシア製L2スイッチ1台などがある．様々なベンターの機器が導入されており，各種ベンダによって操作方法が異なる機器を操作する必要がある．実際の社会においてもマルチベンダーでの環境構築はめずらしくなく，より現実的な環境でコンテストに参加することができる．

3.3　仮想化システムの導入

図2に示したサーバ2台（BravoとVictor）はBroadcom社のVMware ESXi上に仮想マシンとして構築している．仮想マシンの特性上，いつでも攻撃前の状態にスナップショットで切り戻すことが可能であり，各仮想サーバのクローンを作成することにより，参加チーム分のサーバ構築の手間と時間を省くことが可能である．

3.4　ツールの実装

3.4.1　コマンドヒストリ

初期の情報危機管理コンテストでは，運営スタッフから人員を割いてコンテスト参加者の進捗を確認に行っていた．どこまで復旧しているか，どこで行き詰まっているか，などである．これは非効率であり，遠隔からコンテスト参加者の挙動と進捗を把握するために，UNIXシェルヒストリを30秒ごとに運営スタッフ側に送信するシステムを開発した．コマンドヒストリの確認画面を図3に示す．コンテスト参加者が使用する管理アカウントを用いてサーバにSSHなどでログインした場合，そのセッションごとにコマンド実行履歴を取得している．このため，運営チームはセッションごとに実行したコマンドを確認し，シナリオの進捗具合を確認することが可能である．

3.4.2　正規アクセスによるログの蓄積

初期の情報危機管理コンテストでは，サーバ上に「攻撃のログしか残らなかった」ため，簡単にインシデントを発見，対応できていた．このため，ログを見る能力がインシデントに対応する速さと正確さにつながることから，正規アクセスを人的に実施してログを蓄積した．しかし人的労力が必要となり，全チームにこれを実施するのは困難となった．我々は特にHTTPおよびSSHにおいて，正規アクセスを実施するエージェントを開発し，それぞれに正規アクセスのログを蓄積させた．したがって，ログの中には正規もあれば不正もあるため，不正アクセスを見つけ出すためのスキルが求められる．ログの検索や脆弱性を使用した際に記録される特有のログを確認することにより，参加者の人材育成につながることが期待される．HTTPの場合は，サイトを閲覧するだけでなく，掲示板サイトに自動投稿（書き込みデータベースから文言を選択）して秒間10回投稿できる「祭り」モードを作成した．SSHにおいても，自動でログインするだけでなく，いくつかのコマンドを実施してセッションを長引かせるように工夫した．

3.4.3　攻撃プロシージャ

情報危機管理コンテストでは，コンテスト参加チームの環境に対して，リアルタイムに攻撃を実施する．しかも参加チームの進捗は同じではないため，個別に攻撃を実施する必要がある．初期のコンテストでは各参加チームに対して攻撃を実施していたが，全体の進捗を運営スタッフで共有することが困難であった．このため，攻撃サーバを用意し，専任の攻撃要員を配して，全参加チームへ個別に攻撃のためのプログラムをスクリプト化した．たとえば，正規ユーザのアカウントを奪取したのち，当該アカウントでログイン，権限昇格のためのプログラムを外部から取得，実行，サーバ内の設定ファイルなどの改ざん，ログアウトを自動実行するなどである．これらを称して攻撃プロシージャとしており，攻撃要員そのものはプロシージャを実行するだけで良い．シナリオの中には，再度インシデントを発生させる場合もある．上記の例では，奪取されたアカウントを処理しない限り，インシデントが繰り返され，参加者に再度対応を迫り，対策が不十分であることを知らせ，シナリオが完了されるまで誘導を実施する．

3.4.4　トラブルチケット

トラブルチケットとは，コンテスト参加者にインシデント対応の内容を記録してもらうWikiサイトである．これは参加者が記録しなければならないが，コンテストの審査対象になりうる．内容は正確か，役員会などに出しても問題ない品質か，読む側に分かりやすいか，などの視点で審査するための材料となる．

3.4.5　ホワイトボードログ

初期の情報危機管理コンテストでは，運営側でホワイトボードに参加チームの進捗を記録していた．これは，参加者がどのようなコマンドを使って何を調べているか，インシデント対応のどのステップにいるか，見ているファイルなどから何に気づいているか，などを推測して記録している．これは運営側が記録しているものであり，シナリオを設計している側でもあるため，正確な進捗を把握，記録した内容であると言える．前項のトラブルチケットは参加者側の記録であり，本項は運営側の記録である．これらの比較は，双方の齟齬を確認するうえで重要である．

3.4.6　フィードバックシステム

実践的な教育における重要な要素として，「振り返り」がある．自らの行動がどのように評価されるのか，何が良かったのか，何が悪かったのかを振り返ることは，高い教育効果を得られると考える．しかも演習などにおいて，これを実施することは，業務の積み増しとなるので簡単ではない．我々は，フィードバックシステムと称して，上記の支援システムの中で，攻撃プロシージャを除くすべての記録を閲覧できるフィードバックシステムを開発した．フィードバックシステムの画面を図4に示す．フィードバックシステムでは，コマンドヒストリ，株価チャート，トラブルチケット，およびホワイトボードログが表示される．フィードバックでは，インシデント対応の流れを時系列を追ってリプレイすることができる．たとえば，株価チャートは時間軸がスライダーで移動できるため，株価が上昇したり「イイね」がついているところに時刻をスライドすると，同時刻あたりのコマンドヒストリ，トラブルチケット，ホワイトボードログが表示される．これは，当該時刻にどのようなアクションがあったのか，その前後で，何に気づいていたのか，参加者側と運営側（シナリオ設計）でどのような齟齬があったのかを振り返ることができる．特に齟齬については，自分たちが何を調べないといけなかったのか，などを振り返ることができるため，高い教育効果を期待できる．

4.　情報セキュリティ演習の運営

4.1　運営チームの役割

運営側の主な役割は，シナリオ設計，環境構築，検証，事前練習，演習当日のシナリオ進行などである．シナリオ設計は，最新の攻撃手法，脆弱性以外にも，サーバの設定ミスやユーザの安易なパスワード，容易な権限奪取（PHPプログラムの不備によるwww権限の奪取，サニタイズの未処理など）が含まれる．基本的に，我々は現実にあった過去の事例に沿って，シナリオを設計している．既知の脆弱性，実際にあった攻撃を再現しているので，コンテスト参加者は今どのようなインシデントが起こっているのか，何を調べてどのように対応すればいいのかをインターネット上で調べることができる．重要なことは，自発的に調べる自由が参加者側にあって，これをシナリオの解決に導くよう，運営側が誘導することである．情報危機管理コンテストでは，運営側が参加者側に「情報セキュリティの教育コンテンツを提供（サービス）する」という観点から，参加者のインシデント対応において，これを陰からサポートする体制をとっている．

シナリオ設計は5章で後述する．シナリオ設計が完了すると，演習環境を構築する．仮想サーバの初期イメージから各種パッケージ，脆弱性を持たせ，ユーザ環境を施した攻直（攻撃直前）イメージを作成する．攻撃用のサーバも合わせてネットワーク上に配して，検証を実施する．脆弱性や設定の不備がきちんと機能する（違和感のある表現ではあるが）ことを確認する．ここで攻撃用のプログラムと手順を作成して攻撃プロシージャとする．攻撃プロシージャによってコンテスト参加者側のサーバに期待どおりのログが残るか確認し，インシデントを解決するための，複数の考えられる限りの対応方法を設計する．もちろん，これら複数の対処方法も，きちんと機能するかどうか，攻撃プロシージャでインシデントが再発しないかどうかを確認する．頭の中で「解決するだろう」と確認を疎かにすると，思わぬときにコンテストを破綻させることもあるので，以下の事前練習を通じて見落としがないか確認する．

検証の後で，運営スタッフが参加者チーム役と運営側に分かれて，それぞれの立場でシナリオが設計どおりに実行できるかどうかを確認する．さらに，参加者の立場でインシデントに対応し，シナリオ完了までに運営側に対する連絡内容や質疑応答について，可能な限り想定する．参加者側チーム役と運営側の立場を入れ替えつつ，複数回事前練習を重ねることにより，コンテスト参加者がシナリオの開始から終了までを把握できるように，どこで行き詰まったらどのように誘導するか設計する．行き詰まりには，一定時間コマンドヒストリなどで動きがないときや，同ヒストリから間違った行動が確認できたことなどで判定する．たとえば，コンテスト参加者の環境内でWebページが改ざんされると，DNSキャッシュポイズニングを想定する参加者が意外に多い．この場合，コンテスト参加者が自分たちの環境の中でDNSサーバを調べても，キャッシュデータではないのであまり意味がない．一定時間立ち往生すると，セオ（運営スタッフが演じる顧客（サーバ所有企業の責任者）であり，参加者の役割上の上司にあたる）を通じて，「改ざんされたページでは，本来のURLが変わっている」などのヒントを与える．ヒントによって，キャッシュポイズニングを思考から外し，別の要因であることに誘導する．このような，行き詰まるポイントを想定し，行き詰まるであろう内容を把握し，どのように誘導するかを含めて，想定問答集にまとめて運営側で共有しておく．さらには何度も練習することによって練度を高めておく．

情報危機管理コンテスト当日は，運営側は参加者チームの電話対応やヒストリログの監視，参加者側サーバへ「一般ユーザとして」ログインして同サーバ内の監視，攻撃要員に攻撃のキュー出し，シナリオの進捗をホワイトボードログにまとめる，などの役目に分かれて（重複することもある），コンテストが円滑に進むよう対応する．

4.2　運営チーム内の役割分担

運営側では，情報危機管理コンテストを実施するために，プロジェクトマネージャとして統括管理，各サーバやネットワークに機器の構築，シナリオ設計・検証などに分かれて演習を準備する．大学の研究室は毎年メンバーが少しずつ入れ替わるので，上記の役割を入れ替えながら，学部は卒業までに，大学院は修了までに，できるだけ多くの役割を経験するようローテーションする．通常，大学院1年生からプロジェクトマネージャを選出する．大学院2年生は，プロジェクトマネージャの経験から，そのフォローをする．シナリオ設計では，大学院生主体で実施する．各サーバやネットワーク機器の構築は，主として大学4年生が実施する．運営側の人材育成として，まずサーバやネットワーク機器の設定等を学習する．これを検証の失敗やログの消し忘れ，さらにはシナリオの変更など，これらに伴うイメージの作り直しが発生する．ネットワークも，DoS攻撃がサーバに影響を及ぼす前にルータに過負荷を与える場合などは，それを調べた上で機器を交換するか，DoS攻撃の分量を加減するなどをシナリオ設計に提案する．これらの反復作業によって，インシデントが発生する原理や，情報危機管理コンテスト参加者が実施するコマンド，設定などがどういったものか理解できるようになる．

上記において，大学院生の業務は指導と設計検証，学部生の業務は構築，そして双方で事前練習といった繰り返しになる．大学生，大学院生という人員のリソースは，役割を世代間で引き継ぎ，交代していけるように設計しなければならない．安定した学生数を確保することも重要だが，上記の業務を通じて自らの知識を深め，更なる知見とスキルを身につけられること，これが自らの進路の選択肢を広げられるというインセンティブを提供することが肝要である．

4.3　事前トレーニングの方法と意義

4.1節に述べたように，我々はコンテストを「情報セキュリティの教育コンテンツを提供（サービス）する」という観点で設計している．このため，運営側において情報危機管理コンテスト当日に向けた事前トレーニングの実施は重要である．すなわち，コンテスト参加者側にとってはすべてが「想定外」であり，運営側にとってはすべてが「想定内」であるように，すべてを準備しなければならない．しかも，運営側の「想定内」には，参加者側がどこで行き詰まるか，どのような間違いをするか，その場合はどのように誘導，修正するかも含まれる．参加者側のみならず，運営側にも教育効果が得られるよう，双方にインセンティブを与える仕組みが必要である．

特に参加者側においては，コンテストという性格上，優劣をつけなければならないが，教育コンテンツとして，次につながるヒントを与えられるよう，誘導と修正を施している．インシデントの原因や対応に気付いたところはそのまま進行させるが，そうでないところは一定の時間が経過すると誘導と修正のプロセスに入る．運営側は上記のための事前練習を実施する．

事前練習において，攻撃プロシージャの実行から，インシデントの発生確認，インシデント対応と解決策の進捗を確認する．情報危機管理のコンテストであるため，確実にインシデントを発生させる必要がある．「確実に」インシデントを発生させることは容易ではない．しかも研究室配属された学生が，いきなりこれを実施するためには，膨大な練習のうえに内容への深い理解を必要とする．攻撃プロシージャを単に実行するだけでなく，何度も反復することで，次年度以降，攻撃プロシージャを自ら設計できるように，そしてこの攻撃が，どのようにすれば対応できるのかを理解するステップになると言える．

5.　シナリオ設計

5.1　シナリオ準備の要件

あらためてシナリオとは，情報危機管理コンテストにおいて，発火（インシデントを発生）するための方法から，発火の確認方法，コンテスト参加者側に通報する様式，インシデント対応中にどこを監視すれば良いか，クレームや質問に関する問答集，シナリオ終了の条件と，未終了の場合の再発火条件など，これらが示された一連のドキュメントである．当該ドキュメントには，シナリオの発火から終了までのフローチャートが付加され，できるだけ容易に，かつ多面的に運営側スタッフ同士が共有できるようにWikiサイト上で作成している．

注意しなければならないのは，複数年にわたって同じシナリオの重複は許されないことである．情報危機管理コンテストは毎年開催されており，複数年連続で出場するチームには，複数年にわたり重複するメンバーが存在する場合もある．したがって，新作シナリオを書き下ろす必要がある．永遠に大学に在籍する学生はいないため，数年経てばシナリオを使いまわせる可能性はある．しかし参加機関の中で後輩への継続的な情報共有が実施されることを想定し，常にシナリオをアレンジして数年後に使うことも心がけている．我々は，参加機関における連綿とした情報共有のつながりを期待している．

5.2　構成要素：技術

効果的なシナリオとして，本節と次節で述べるような技術的・社会的要件を満たしていれば良いと考える．技術的には，主に攻撃のための脆弱性や，前提となる設定ミスとインシデントによる被害内容を考える．JPCERT/CCやJVNといった脆弱性データベースのサイトから，手持ちの環境で実現可能な，整備できる事項を選択する．設定ミスの場合は，これを設計する．被害内容が深刻なものとしては，DoS攻撃によりWebサイトが閲覧できないものや，管理者権限の奪取によって同権限の設定ファイルが改ざんされるものもある．攻撃手法とは技術的側面から考えることが多く，事前の走査活動も，ログに残してコンテスト参加者側が追いかけられるように実施する．Brute Forceや辞書攻撃などのアカウントを奪取するためのアクセス，ポートスキャンなどの提供サービス確認も，事前の走査活動である．

インシデント対応の内容について，事前に上記脆弱性レポートにおける対応を確認し，当該技術的要件が可能かどうか検証しておく．追加パッケージが変更されてないか確認し，同リンクが途切れていないかも確認する．我々はシナリオ設計において，一般的な技術水準で追いかけられる技術要件を心がけている．特定ベンダの製品やアプリを前提にしたインシデントでは，当該製品やアプリに関する技術的フォローができる環境と要員を配して，情報危機管理コンテストを実施するベンダシナリオに組み込んでいる．

5.3　構成要素：社会的制約

情報危機管理コンテストには，参加者側はあくまで派遣された運用管理者であり，派遣先である仮想企業の雇用主，すなわち運営側が演じる上司役，その背後に居る役員，そして当該仮想企業が抱えている顧客と社員（ユーザ）がいる．彼らのステークホルダーとしての権益をいかに保持するかも，コンテストの審査対象になってくる．これらをどのように保持していることを確認するかも，シナリオの中で規定しておく必要がある．サーバやサービスの停止や再起動に際して，上司の許可をとったか，長時間停止の場合は顧客にアナウンスしたか，クレームを入れたユーザに状況報告と，ユーザ自身に終了を確認させたかなど，権益保持の確認方法は多様であり，あらかじめこれらを規定する．

5.4　ベンダシナリオ

情報危機管理コンテストでは，2019年度より，ベンダシナリオを導入している．これは，役務協賛している特定の企業と，合同で作成しているシナリオである．ベンダが提供する機器，あるいはアプリを使って，当該機器などに含まれる脆弱性をトリガにする場合や，既存のシステム上の脆弱性をカバーするために当該企業の製品などを導入する場合などがある．このため，コンテスト会場内に当該企業のブースを設置し，コンテスト参加者側は，当該シナリオ実施中に企業ブースへ問い合わせに行く．我々運営側は，事前に当該企業とは十分に打ち合わせて，脆弱性の場合は確認要件（脆弱性データベースへの記載，技術的要件の確認など），機器導入の場合は正常な稼働確認要件を決めておく．これらは，コンテストにおける社会的な制約であり，他人との十分で円滑なコミュニケーションが求められる非常にユニークな試みである．これは，コンテストという場を借りて役務協賛企業にとって案件となりうる事象であり，シナリオを作成する側にとっても，ステークホルダーとしての企業に配慮したシナリオ作成が求められる．なお，ベンダシナリオにおける参加者側の対応は，当該企業のブースにおいて見学可能としており，見学者から毎年大変好評である．

5.5　シナリオ設計例

シナリオ設計の具体例として，Slow HTTP DoSシナリオを示す．本シナリオは，実際に和歌山大学が2016–17年に受けた事例に基づいたシナリオである．

本シナリオでは，Webサーバが外部からのSlow HTTP DoS攻撃を受けてサービス不能に陥ることでインシデントが発火する．電話とメールでWebページが見えない旨が通知され（顧客であるWebサーバオーナーからの苦情），参加者はその解決にあたる．まず，ログでIPアドレスが確認できるホストから攻撃し，参加者がIPアドレスのフィルタリング等の一時的対策を実施した場合には，DNSで正引きできないホスト，つまりHTTPログに記載されるドメイン名からIPアドレスが確認できないホストからの攻撃に切り替える（ただし，参加者の一時的対策が不十分であれば，IPアドレスが確認できるホストからの攻撃を再発火する）．このとき，参加者は現象を認識してフィルタ設定変更の許可を顧客から得たあと，実施後の解決を電話報告するが，その直後に，今度はフィルタできないホストからの攻撃で再度苦情が来る，という形でシナリオが進行する．

本シナリオの運用においては，攻撃方法，状況把握方法，参加チームへの対応方法が明確である必要があり，このことを意識してシナリオを作り込む．攻撃方法として，Slow HTTP DoS攻撃をPythonスクリプトで記述し，Webサーバがタイムアウトしない，できるだけ長い時間間隔でhttpリクエストを送信する．このようなセッションを大量に生成することでDoS攻撃を成立させる．担当者が攻撃ホストからスクリプトを実行することで攻撃を発火できる．

状況把握として，まず，参加チームの進捗把握が必要である．一時的な解決としてIPFWや．htaccess等を用いたフィルタリングがあるが，これらが実施された際の確認方法を運営チームの共有文書（Wikiページ）に記載しておく．本シナリオの根本解決方法として，同一IPアドレスからの同時接続HTTPセッション数の制限，HTTPセッションの維持時間の制限，あるいはDoS攻撃に耐性を持つようなHTTPサーバのProxy設定等があるが，それぞれの実施方法と，参加者が実施した場合の確認方法を共有しておく．ログファイルへの出力をIPアドレスに変更する設定変更方法も有効な対策として共有しておく．その他にも，参加チームが実施しそうな内容と確認方法を共有し，各チームの状況（攻撃を止められたか，何をしようとしており，どこで詰まっているのか等）を各チームの担当者が把握できるように，netstatコマンド等を用いた確認方法を共有しておく．

参加チームへの対応方法として，電話・メールによる対応方法を決めておく．シナリオ進行に直接的に関わる攻撃発火タイミングや解決報告に対する確認等の行動だけでなく，予想できる質問内容に対して対応（回答）方法を決めておく．具体的には，誰にどんな質問が来たらどう答えるか，をとりまとめて共有する．特に，顧客に対する状況確認等の質問に対しては，回答内容として，「知っている」「知らない」，知っているなら何を答えるか，等を決めておくことが重要である．この点が揺らぐと，コンテストの公平性に影響するからである．また，効果のない対策方法であっても，事前に想定される方法であれば申請を許可し（要事前検証），それ以外の妥当な実施理由がない方法は許可しないと決めておく．

5.6　シナリオ設計と教育的効果

情報危機管理コンテストのシナリオは，教育コンテンツとしてサービスすることを狙って設計している．このため，のちに続く様々な演習にも応用している．一般的にアクションラーニングとは，すべてにおいて受講生に自主的な活動を求めるのではなく，適切に干渉することが重要であると考える．ここで言う干渉とは，一方的に受講生の活動を否定するのではなく，何をしようとしているのは把握し，間違いに気づかせて，どのように修正させるか，を指している．シナリオは，これらの観点を意識して設計している．この効果を推し量ることは，コンテストという形態（サービスの有無で違いを出せない）のため直接的な比較対象が容易ではない．しかし，情報危機管理コンテストが19年にわたって実施されてきたこと，リピート参加する学術機関が増えていること，などで間接的に推し量ることができる．

6.　情報危機管理コンテスト

6.1　コンテスト実施概要

情報セキュリティ演習に競争的要素を持たせてコンテストとして運用することで，より高い水準の人材育成を進めている．長期にわたりコンテストを継続することで，1)他チームを意識することによる自習効果の強化，2)他チームの長所を吸収した進歩，3)各大学におけるノウハウ継承による人材層の拡大，4)現役技術者との対話を通じた経験値の向上，等の効果が期待できる．2006年5月に第1回情報危機管理コンテストを実施して以来，2024年まで19回のコンテストを実施してきた．この間，教育効果を増強すべく継続して改善しており，2024年現在では，そのメカニズムは一定の熟成を達成したと考えている．

先述のとおり，本コンテストは技術力を主に問うCTF型コンテストとは異なり，サーバやネットワークを「守る」能力を競うコンテストである．実際のサーバ・ネットワーク管理では，攻撃検出や原因究明のための技術力だけでなく，チーム内の役割分担や協調，適切な顧客対応，コンプライアンス対応等の社会的能力も求められる．本コンテストはこれらの情報セキュリティ人材に要求される全技能で競うことが特色である．このような総合力を問う情報セキュリティコンテストは，本コンテストが始まり19年が経過した現在でも類を見ない．その独自性と人材育成効果の高さから，勝者には経済産業大臣賞および文部科学大臣賞が与えられる，日本では広く知られるコンテストに成長した．

参加チーム数が多いため，本コンテストは一次予選と二次予選により選抜を行い，サイバー犯罪に関する白浜シンポジウム[4]の会場で5チームによる決勝戦を実施する．二次予選は，12チームに対して本番と同様のコンテストをオンラインで実施する．本番方式のコンテストは運営チームの負荷が必須であるため，12チームの実施が限界である．このため，一次予選では文面によるインシデントシナリオに対して解決方法のアドバイス文書を作成させ，その内容を競うことで12チームに絞る．なお，学校対抗コンテストであるため，各参加チームには各学校から監督者を登録してもらい，学校の名前を冠して競ってもらうことになる．

6.2　コンテストの歴史

情報危機管理コンテストは，1997年に始まったサイバー犯罪に関する白浜シンポジウムの併設イベントとして実施されてきた．2006年に第一回情報危機管理コンテストが実施された際には，5チームのみの参加であった．しかし，取り組みの効果が認められ，2009年の第四回には優勝チームに経済産業大臣賞が授与されるようになり，2010年には広く参加チームを募るために予選（現在の二次予選）が設けられ，2014年には一次予選が設けられた．2014年以降の参加チーム数と参加学校数を図5に示す．2015年に最も優秀であった個人を表彰する個人MVP賞が新設され，2016年にはJPCERT/CCの協力により，個人MVP賞がJPCERT/CC賞に改名された．2017年より文部科学大臣賞の授与が開始された．2019年より，コンテストシナリオ内の企業協賛の試みが開始され，2022年には協賛企業の名を冠した賞の授与が開始された．このように，現在では，決勝戦に参加したチームには多数の受賞可能性がある．

この期間中に，コンテストの運営形態も変化している．2008年には仮想環境を用いてサーバ構築することで物理的なサーバ数を低減し，2011年には大学に構築した環境に白浜シンポジウム会場からVPN接続する形に変更した．これらの工夫により，物理サーバの費用や現地環境構築に伴う手間や輸送費を削減し，コスト低減に努めてきた．人的には，2016年から運営チームに社会人を含め，学生と社会人の混成チームにすることで，学生と社会人が相互に刺激し合い学習効果を高める体制で実施している．

6.3　一次予選の設計・実施方法

コンテスト運営チームの負荷抑制のために，12チームに絞る一次予選を実施する．より多数の学生が気軽に参加できることを目標として，一次予選は文面として提示されたインシデントシナリオを分析し，今後の対応をアドバイスする文書を作成させる形式とした．

設計方針：先述の情報セキュリティ演習では実践的なインシデント対応技能の高い教育効果が期待できる一方で，時間内に解決可能な課題を課すという性質上，実施可能なインシデントシナリオの内容が制限される．そこで，一次予選は，たとえば情報漏洩シナリオであれば，内部犯行や部外者の虚偽通報による詐欺行為，複雑なサーバ・インフラ環境に依存するセキュリティホール等の，演習形式ではシナリオへの組み込みが難しいインシデントを含めた広範な可能性を検討する内容とした．一次予選では技術力を競うことが難しいため，インシデントの原因を推定・整理する「分析力」と，重要性や緊急性を考慮してインシデントを切り分けて解決手順を提案する「戦略立案力」を主に問うことを狙いとする．参加チームは，文面で与えられる限られた情報からインシデントの本質的な原因を考え，相談者の立場や利益を考慮して短期的，および長期的な解決目標を定め，その解決方法をアドバイスとして文章に落とし込む．さらに，他チームの提出物を競技終了後に参照し（全て公開される），分析や戦略に関して学習する．これは，アクションラーニングの4つのプロセスに相当するため，高い教育効果が期待できる．

実施方法：一次予選では，インシデントシナリオが「顧客からの相談」としてWeb上に掲載される．参加者は1～4名の学生で構成されるチームとして参加し，情報セキュリティコンサルタントとして当該顧客へのアドバイス文書を作成し，Web上で提出する．授業等のスケジュールの影響を低減するために，土休日を含めた2～3日の期間で回答する．提出されたアドバイス文書は，分析，戦略，表現等の観点から評価され，コンサルタントとして総合的に優れた，説得力のあるアドバイスを提示したチームが二次予選に進出する．

ここで，一次予選から二次予選に進むにあたり，チームメンバを追加することを許している．これは，決勝戦である白浜シンポジウムの日程から逆算した結果，一次予選は4月前半の実施となり，学生にとってチームメンバを集めにくい時期であるためである．一次予選は戦略や分析を主とするため，これらを担う者がいれば競技は成り立つこともあり，メンバ追加を認めて参加しやすくする方針としている．

6.4　二次予選・決勝戦の実施方法

本コンテストは，先述の情報セキュリティ演習と同様に，事前に作成したシナリオに沿ってインシデントを解決する技能を競う．参加者は最大4人のチームで参加し，顧客企業のサーバ・ネットワーク管理者として，サーバやネットワークに発生するインシデントに対応する．各チームに対して電話対応やインシデント発火等を行う運営チームを置き，コンテストの公平性を失わないように，運営チームはどの参加チームにも同等の，シナリオ設計で事前に決められた対応をする．（運営チームはこのための練習を積む必要がある．）参加チームの行動（サーバ内でのコマンド実行履歴や電話対応を含む）はログとして逐次記録される．コンテストの評価は，ログや競技の様子，競技の最後に作成するトラブルチケット等に基づいて，管理者として相応しい優れた対応かどうかを基準として，評価委員によって総合的に実施され，コンテストの表彰内容が決定する．

1チームの人数を4人とした理由として，グループ学習では一般に4～5人が，十分な発言機会が得られ，意見に多様性がみられる人数として適切であることが挙げられる[18]．また，全体を取りまとめるリーダー，電話対応等を担う渉外担当，サーバやネットワークの調査，インシデント切り分けや判断等の作業・戦略担当など，チーム内の役割分担に適した人数の考慮や，人数がある程度少ないほうがコンテストに出場しやすい等の事情も考慮した．なお，先述のとおり役割分担はチームによって異なり，役割分担の妥当性も評価対象に入る．競技時間は，二次予選は3時間程度，決勝戦は午前・午後に各3時間程度の時間を確保しているが，これは1件のシナリオを解くのに一定の長時間を必要とすることと，一日の単位で実施するにあたりスケジュールを立てやすいことがある．

本コンテストの決勝戦は白浜シンポジウムの会場で実施し，シンポジウムの来場者に公開される．二次予選は決勝戦と同様の競技を実施するが，VPNを用いて各学校から参加する．二次予選は観客がいないこともあり，12チームのそれぞれに対して日程調整を行い，非同期に実施する．

6.5　コンテストの可視化

決勝戦会場ではシンポジウム参加者が見学するため，コンテストの進行状況を可視化する．情報セキュリティ分野の関係者との接点を設けることで，コンテストの取組の業界への周知，コンテスト出場者のやる気の促進，新規コンテスト出場者の獲得，コンテスト出場者と企業のマッチング機会作り，フィードバック意見の収集，等の効果が期待される．

観客に対する可視化として，以下に述べる株価チャートと進行管理システムを用いる．なお，6.6節に述べるとおり評価は総合的に実施されるため，株価やチェックリストは参加チームの成績の一面でしかなく，これらによって直接的に勝者や表彰内容が決まるわけではない．これ以外に，当日は，シナリオの中身を関係者が見学者に説明する取組もしている．また，X（旧Twitter）にて，発生中のインシデント内容や各参加チームの進捗等を実況中継する．可視化によってコンテストの状況がリアルタイムに観客に伝わり，興味をもって観戦してもらうことが期待できる．

6.5.1　株価チャート

初期の情報危機管理コンテストでは，参加チームの進捗を運営スタッフや見学者で共有することが困難であった．運営スタッフである我々がホワイトボードに記録し，それを見学者が見る程度である．そのため，一見どの参加チームが優位なのか分かりにくい．そこで，進捗の度合い，および進捗の内容の良さを株価で表現することにした．株価チャートシステムの画面を図6に示す．参加チームの株価をチャートで表現し，インシデントが発生すると株価が一定量下がる．インシデントに対応していく中で，対応のステップを完了するたびに株価が少しずつ完了し，最後に対策ができれば元の株価を超えるように設定する．しかし，インシデントが発生すると時間経過とともに株価は少しずつ下がるため，インシデント対応が遅れると元の株価を割り込むことになる．このチャートを参加チームごとに見ることによって，運営スタッフおよび見学者は参加チームの現在の進捗の度合いと，および進捗の内容を，確認できる．加えて，インシデント対応の中でも，加点評価できる点がある場合は，運営側が「イイね」ボタンを押して株価を上げることもできる．クレームを入れたユーザ（運営スタッフ）に対して，定期的な状況報告で安心感を与えた場合や，フォレンジック（証拠保全）においてファイル属性（オーナ，パーミッション，日付など）をそのままに別途保存した場合などが相当する．逆に，上司であるセオ（運営スタッフ）に許可なくサーバを再起動してサービスを停止した場合などは，「ワルイね」ボタンで株価を下げることもできる．

6.5.2　進行管理

上記の株価チャートと同時期に，コンテスト参加者の進捗ステップの詳細を伝える補助システムとして，進行管理システムを作成した．進行管理システムの画面を図7に示す．「3.4.3攻撃プロシージャ」で示したインシデント例であれば，「設定ファイルの改ざん」「権限昇格コードの発見と隔離」「奪取されたアカウントの停止やパスワード変更」などが進捗ステップである．これを，「3.4.1コマンドヒストリ」で示したコマンドヒストリや，コンテスト参加者とのやり取りの中で状況確認したうえで，進行管理にチェックを入れていく．本システムは，前項の株価チャートと連動しており，進行管理にチェックが入ると，株価が上昇するなどの変化が起こる．

6.6　評価・表彰方法

コンテストの表彰は，審査委員が各チームの進捗や行動を，運営チームが記録したログやコンテストの終わりに各参加チームが作成するトラブルチケットに基づいて総合的に評価することで決定する．審査委員は本分野の実務を熟知した専門家によって構成される．評価の一側面は技術要素であり，各シナリオにおけるインシデントの原因究明や解決等の方法や速度が問われる．他方，サーバ設定変更時の顧客への確認義務や，Webページが改ざんされた際の社会への悪影響の低減など，法令遵守やモラルの観点からも評価される．そのほかにも，チーム内の役割分担やチームワークの良さ，電話応対の適切さ，顧客への配慮等，参加チームのすべての行動がシステム管理者としての行動として評価され，総合的見地からの判断によって表彰が決まる．判断は，可能な限り客観的に行われるように合議される．CTFであれば，目的を達成した早さ，という客観的な評価指標が存在するが，本コンテストでインシデント対応全体を評価するためには，多要素の考慮が必要であり，合議とならざるを得ない．

表彰内容も合議で決定される．経済産業大臣賞には，現場における実技に秀でており，情報セキュリティ技術者としての実践力が総合的に優れたチームが選ばれる．文部科学大臣賞には，チーム内の協力体制や各学校における知識・経験の継承等を含めて，教育・学習の効果が顕著であったチームが選ばれる．JPCERT/CC賞は，チーム内の役割分担や作業効率を見たうえで，最も優れた個人に授与される．コンテスト協賛企業の賞は，その企業が重視する価値基準において優れるチームが選ばれる．それ以外の参加チームには，コンテストにおけるそのチームの特徴を言い表した名称の賞が贈られる．すべてのチームに賞が贈られ，健闘が讃えられる．

6.7　教育効果への配慮

本コンテストは，教育効果を高める仕組みとして企画され，継続的に改善されてきた．第一に，人材育成の取組としてコンテストを実施する意義は競争効果にある．他の参加チームと競い合うことで，参加者はより高い水準に辿り着こうと努力する．これを促進するために，二次予選と決勝戦では，各チームのコンテスト内の行動に対する総評をフィードバックし，他チームの行動内容もログとして公開し，閲覧できる仕組みを提供している．一次予選においても，問題と参加チームの回答に関する講評だけでなく，全参加チームの提出文書をWeb上で公開し，予選通過するにはどのような回答を書けば良いのかを自主勉強できるようにしている．運営側や他チームのフィードバックを受けて，自分たちで努力することで実力を向上できるように配慮されている．

コンテスト本番では，シナリオによっては，参加チームの進捗が長時間にわたって止まることがある．進捗が止まると学習効果が望めないので，その場合にはコンテスト主催側から適宜ヒントを出して，進捗を誘導する．本番の限られた時間内で実施できるシナリオ要素は参加者の進捗に依存して流動的であるが，各参加チームが可能な限り多様なシナリオ要素に触れ，教育効果が高まるように進行させる．

運営チームは，和歌山大学の学生が主体となって組織しており，コンテスト運営も教育機会である．4.2節では準備時も含めた役割分担を述べたが，コンテスト本番では，プロジェクトマネージャ等のコンテスト全体に関する役割とは別に，各チームの対応に専念するチームを，参加チーム数と同数の5チーム組織する．そのチーム内では，電話応対役，コマンド履歴の監視役，攻撃役を分担して実施する．近年では，運営チームに社会人を含めて，相互に刺激し合うことで学習効果を高める試みを実施している．

運営側の工夫ではないが，コンテスト参加チームの間でも教育効果が発揮される．決勝戦への出場が常連となっている学校では，研究室あるいは同好会の中で，先輩から後輩に技術や経験を継承することで技術力を維持し，決勝戦への連続出場を実現している場合が多い．学校内で模擬的にインシデント対応の演習を実施する事例や，ノウハウを先輩から後輩に継続的に継承する例が確認されている．このように，コンテストの開催により，参加者が自主的に技能を向上する取組みを行い，学習効果が発揮されている．

6.8　育てるべき人材像のロールと情報危機管理コンテストの設計の対応付け

情報危機管理コンテストでは，第2章で述べたデジタルスキル標準を意識して学習スキルを設定，学習プロセスを提供するようなシナリオや環境を構築している．育てるべき人材像の具体的な形として，デジタルスキル標準[9]の人材類型の中でも，サイバーセキュリティを想定している．同人材像におけるロールには，サイバーセキュリティマネージャー，およびサイバーセキュリティエンジニアがある．前者はマネジメント系，後者はテクノロジー系のロールである．

情報危機管理コンテストのシナリオを設計する時点では，コンテスト参加者に上記のロールを意識させることに注力している．すなわち，サイバーセキュリティマネージャーはチームの体制と統制などのセキュリティマネジメント，インシデント対応のフローを提供する．全員が別個にインシデント対応していては，個人の能力にのみ依存してしまい，インシデントに対応できない．このため，シナリオにはできるだけ多岐にわたって調査させる設計をしている．「ページが閲覧できない」ことに対して，トラフィックが原因か，DNS（Domain Name System）か，コンテンツが変わっているか，ファイルやプロセスのオーナー，パーミッションは変わっていないか，あらゆる調査によって原因を切り分ける必要のあるシナリオを提供している．コンテスト参加者は，効率よく切り分け業務を差配しないと，インシデント対応が困難である．

一方で，サイバーセキュリティエンジニアには，セキュリティ運用や保守だけでなく，セキュアなシステム設計および構築術が求められる．近年の情報危機管理コンテストでは，AWS（Amazon Web Service）などクラウドベンダと組んでシナリオを提供する場合もある．したがって，ネットワークを含む幅広いインフラでインシデントが発生するシナリオを設計しており，コンテスト参加者はこれに対応する必要がある．具体的には，アプライアンスあるいはクラウド上のファイアウォールにおいて，ACL（Access Control List）を「遠隔で」設定する場合の留意点などがある．さらにログには攻撃のレコードだけでなく，通常のアクセスによるレコードも多く蓄積させる．すなわちログ解析は必須であり，コンテスト運営側では，通常のアクセスレコードを発生させるIPアドレス，および自動エージェントを装備している．

情報危機管理コンテストでは，第2章で述べたRETAINモデルも意識して経験学習プロセスを設計している．コンテストのシナリオでは，現実に発生したインシデントをできるだけ忠実に再現している．このため，脆弱性を持ったシステムも同様に再現している．しかも同シナリオでは，6.4節で述べたような各役割を必要とする．3.4.4項で述べたトラブルチケット，3.4.6項で述べたフィードバックシステム（運営側のフィードバックであるホワイトボードログを含む）との比較などで振り返り，現実に近い状況の中で知識を取得・展開させることで学習を促進している．

上記のように，情報危機管理コンテストでは，育てるべき人材像を想定して，必要なロールに沿った学習プロセスを提供するような，シナリオおよび環境を設計している．

7.　教育効果の検証

7.1　アンケート結果

第19回情報危機管理コンテストの参加者に対して，二次予選後に事後アンケートを実施し，32件の回答を得た．事後アンケートでは一次予選と二次予選の満足度について5段階評価を行い，その満足度を選んだ理由の自由記述欄を設けた．一次・二次予選への対策時間と具体的な対策内容に関する質問も実施し，予選全体への自由記述欄を設けた．

コンテスト予選の満足度と対策時間の結果を図8に示す．ただし，二次予選については，二次予選進出者21名の回答のみを集計した．一次予選の満足度は平均4.38（標準偏差：0.60），二次予選の満足度は平均4.43（標準偏差：0.66）であり，参加者はコンテスト予選に満足していることが確認された．予選への対策時間については，一次予選では約65%の参加者が何らかの対策を実施しており，24時間以上の対策時間を費やした参加者（3件）も確認された．二次予選では，参加者はより多くの対策時間を確保している傾向にあり，6時間未満と回答した参加者と6～24時間と回答した参加者がそれぞれ約40%ずつを占めた．これらの結果から，競争効果によって参加者の自学が促されていることが示唆された．

アンケートへの自由記述から，コンテスト予選が参加者に与えた影響を分析した．満足度の理由としては，一次予選では「内容として非常に現実味のあるものが取り上げられるため，それへの対応・対策を考えるのが楽しい」，二次予選では「インシデントレスポンスの具体的な業務イメージを掴むことができた」，「電話やメールでリアルタイムの連絡を求められるといった他にない体験で非常に良い経験になった」等，現実的な要素を含んだシナリオに沿った実践的な対応についての記述が一次予選，二次予選でそれぞれ7件と多くみられた．これにより，課題として現実的に近い要素を埋め込んだ仮想ケースを設定することは，学習意欲の向上に有効な可能性が示唆された．「他のチームの回答を見て学ぶことができた」，「自分の改善すべき点が明確に分かった」等，本コンテストを内省の機会として活用していることも確認できた．また，予選全体への自由記述においても，「とても楽しかった」，「本コンテストを通して非常に多くの学びが得られたことに感謝している」等の，学びへのポジティブなコメントが大勢を占めており，参加者が高い満足度を示した結果を支持している．

予選への対策内容としては，一次予選では「過去問および決勝進出チームの回答書の分析」，二次予選では「過年度の問題概要を過去にコンテストに出場した先輩方に確認した」等の，過去問や過去の解答の分析を行ったという回答が多くみられた．参加者は，具体的な演習問題を体験し，抽象化することで，問題を解決するための知識や手順としてまとめることができていると期待される．さらに，「昨年度の問題をチームで解き，講評と照らし合わせて分析した」，「予想されるインシデントに対して実戦形式で対策，役割分担も確認」等，実際に想定課題に取組み反省を行いながら学習を進めている例もみられた．上述のとおり，予選への対策段階においても経験学習モデルの学習サイクル，あるいはその一部が実行されており，参加者自らの手で学習内容の更なる定着が促されていることが示唆された．

自由記述には，2.2節に述べた習得すべきスキルセットに関連する記述もあった．デジタルスキル標準[9]のセキュリティカテゴリの各項目に対応する事前対策を実施したことや，本番に意識してコンテストに取り組んだことが記載されており，上位チームほど対策時間が長いことを考慮すると，これらの対策がコンテストの対策として有効であることが推察される．具体的内容をとりまとめて以下に示す．

セキュリティ体制構築・運営：チーム内の役割確認や先輩から後輩への技術継承に関する記述が各3件あり，電話対応を含めて実践形式で対策されていることが確認された．

セキュリティマネジメント：各組織が保有している調査権限の違いやクライアントへの誠実な対応に言及した，インシデント要因の特定と対策の難しさに関する記述が2件あり，法令や社会的制約の下で顧客の利益を守るマネジメントを意識していることが確認された．

セキュリティ運用・保守・監視：ログ解析やコマンドの習熟に関する記述が各5件あったほか，定番OSやソフトウェアの習熟，対策手順の確認等の記述があり，実践水準の対策がなされていることが確認された．

インシデント対応と事業継続：個別インシデントにおける対応優先度の検討の記述等があり，意識して対策されていることが確認された．

セキュア設計・開発・構築：仮想化技術を利用してコンテストの演習環境を模したシステムを構築したこと等，練習環境を用意して実際にセキュリティ対策を講じた記述が5件あった．また，一次予選においても，現実的なシステム構成のセキュリティの調査・検討に時間をかけた記述があり，セキュアなシステム構成に関する意識と対策作業が確認された．

プライバシー保護：プライバシーに特化した記述は見受けられなかったが，当然ながら一次・二次予選ともに実施内容に強く関連しており，上記セキュリティ運用・保守・監視の中で意識されていると想像される．

アンケートではスキルセットが習得されたかどうかの確認はできないものの，少なくとも事前対策や予選実施において参加者に意識され，実践されていることが分かる．

7.2　コンテスト参加者の進路

本情報セキュリティ演習の効果の一端を評価するために，コンテスト参加者や，運営側の和歌山大学学生の進路を調査した．参加者の追跡調査は実施されていないので筆者らが把握できる範囲内であるが，情報セキュリティ演習を通じて把握される人的交流の中で以下の実績が確認された．

彼らは，多くの場合にICT関連企業や情報セキュリティ関連企業等（例：IIJ，NEC，GMOグループ，ラックなど）に就職し，実業務で技術者や研究者として活動を続けている．セキュリティ・キャンプやSecHack365のチューター，SECONの運営委員など，情報セキュリティ人材育成に関わる活動を行っている者もいる．また，彼らは就職前にも，在学中にコンピュータセキュリティシンポジウム（CSS）における研究発表や，同シンポジウムの併設ワークショップ「マルウェアとサイバー攻撃対策研究人材育成ワークショップ（MWS）」等に参加し，優秀な成績を収めた実績がある．

また，本コンテストのシナリオ作成や運営には，過去のコンテスト参加者や運営参加者が，実践的人材のモデルとなる情報セキュリティ関連企業の現場の現役技術者や研究者として参画している．たとえば，直近の2024年の「第19回情報危機管理コンテスト」では，アマゾンウェブサービスジャパン合同会社，みずほリサーチ&テクノロジーズ株式会社，株式会社ラックから参画している．

これらは実績の一部に過ぎないが，コンテスト参加者や運営参加者の多くが情報セキュリティ関連企業に就職し，研究，管理・運用業務，人材育成等において活躍している．

8.　課題と展望

情報セキュリティ技術者教育には様々な課題があるが，ここではその中でも我々が特に重要と考えている3つの課題について述べることにする．

まず1つ目は，変化するサイバーセキュリティ脅威や技術動向への適応である．近年，サイバーセキュリティの業務の対象領域が急速に拡大している．クラウドコンピューティングやAI技術などが急速に発達し，様々な影響を与えている．コンピュータシステムやネットワークだけではなく，産業系システム，サイバーフィジカルシステム，IoTなど，広範囲にわたる．それに伴い，サイバーセキュリティ人材の業務と必要となる知識やスキルも変化している．それにも適応し続けなければならない．

次に，演習システムにおける最新のデジタル技術への適応である．デジタル化の波は，大学や高専など高専教育機関における教育現場にも大きな変化をもたらした．それに加え，2020年からの新型コロナウイルス感染拡大の際には，対面での授業やイベントが行えず，リモート会議ツールなどを利用したオンライン環境での実施を余儀なくされた．また対面とオンラインを組み合わせたハイブリッドやハイフレックスと呼ばれる形態での授業やイベントも一般的になっている．今後もこのような技術の進化等による環境変化にも適応していかなければならない．

最後に，教える側の人材の育成と維持である．これらの学習では，その業務の実務経験のある演習の進行役，つまりファシリテーターによって行われることが必要となる．ファシリテーターは，知識伝達学習（座学）の講師と比べ，経験と高いスキルが求められる．提供されるコンテンツもケースやシナリオを設定することが高いスキルと多くの手間や時間を必要とする．長期にわたり人材育成を継続するためには，情報セキュリティ演習の中で，教える側も技能を継承し，人材育成する仕組みを維持しなければならない．

これらの課題を解決するためには，最新の動向や情報を収集し，蓄積・共有する取り組みが必要となろう．それらを積極的に取り入れ，様々な変化にも適応できるよう試行とその検証を繰り返し，そのナレッジやノウハウも蓄積・共有していくことが重要と考える．その際には，産学官という敷居を超えた様々な連携やコミュニティの形成が必要かつ効果的と考える．また，これにより教える側，教わる側ともにその機会が拡大し，教育者（ケースやシナリオを作成できる者，ファシリテーター）や，主体的な自主学習や技術伝承ができる受講者の拡大が期待できるのではないだろうか．

本セキュリティ演習は，できる限り現実的なシナリオを実現するためにも，運営チーム内の役割分担と個人間の緊密な連携が必要であり，これが教育活動の基盤となる．この基盤チームに外部ベンダ等が参加することで，チーム内の調和を保ちつつ，チーム内外の学生への教育効果を拡張してきた．参加チームの学生は入れ替わるが，常連チームに関しては各大学で先輩から後輩に技術継承を行っており，そのようなコンテスト対策がコンテストの水準と教育効果を継続的に支えている．新規参加チームもこのような循環を理解し，その輪の中に加わることで恩恵を享受し，長期にわたり参加校が入れ替わりながら継続を支えている．本コンテストの長期にわたる継続は，このように，複数のステークホルダが教育目的や理念を理解し，それぞれの役割を果たしながら積極的に参加する姿勢に支えられていると感じられる．関係諸氏の献身に心より感謝する次第である．

9.　おわりに

本稿では，情報セキュリティ人材育成の取り組みの1つの事例として，我々が実施している情報セキュリティ演習と，それに基づいて継続実施している情報危機管理コンテストを紹介した．人材育成に対する基本的な考え方と情報セキュリティ演習・コンテストの設計と運用方法を述べた．

今後の課題と展望は7章で述べたとおりであるが，今後もこれらの課題と向き合いながら，情報システムを守る情報セキュリティ技術者の育成を続けていきたい．

謝辞　情報危機管理コンテストを併催していただいた「サイバー犯罪に関する白浜シンポジウム」実行委員会およびスタッフの皆さまに感謝します．情報危機管理コンテストの創設時からともに盛り上げてくださいました審査委員会メンバーの皆さまに感謝します．そして，最初に情報危機管理コンテストを実施するよう声がけをいただいた故井原たかし氏に感謝します．