大規模検証環境でのインシデント対応演習について

こんにちは、NTT Comイノベーションセンターの小崎です。検証網を活用したセキュリティ技術の評価、運用などを担当しています。この記事では、イノベーションセンターで運用する検証網内でのインシデント発生を想定したインシデント対応演習についてご紹介します。

検証網について

イノベーションセンターでは、新技術の評価などを目的とした全社検証網を運用しています。この検証網は国内に約30の拠点を持ち、1000台以上のノードなどによって構成されています。

インシデント対応演習の目的

インシデント対応演習は、大きく2つの目的で検討、準備を進めました。

自組織でインシデント（恐れ）が発生した際の連絡体制を確認する、インシデント対応者からの指示などがインシデント発生時に迅速／効率的に機能するかどうかを評価する
自組織で運用する検証網のセキュリティ検知機能や封じ込め機能が、インシデント発生時に機能するかを評価する

演習検討の進め方

検討のステップ

演習の作成にあたっては、日本シーサート協議会（NCA）のインシデント対応演習訓練 WGにてまとめられているサイバー攻撃演習/訓練実施マニュアルを参考にしました。主な検討のステップは以下となります。

シナリオ検討、レビュー
開催準備
演習
演習後の対応、課題抽出

これらのステップを、以下のスケジュールに展開しました。

参加者について

演習には、組織のインシデント対応を担当する方達に参加してもらいました。参加者には次のいずれかの役割を割り当てました。

インシデント対応者：　情報収集・分析者からの情報をもとに、インシデントに対しての判断、指示する
情報収集・分析者：　セキュリティアラートをモニタリングし、インシデント担当者へのエスカレーションや指示に従った解析、封じ込め対処などを行う

シナリオ検討の前提条件

演習の作成にあたっては目的に合わせ、事前にいくつかの条件を設定しました。

演習シナリオ：過去に検証網内で発生した（恐れとして報告された）インシデントを模擬することにより、アラートの検出から対処までをシナリオ化しました。
演習範囲：自組織内のインシデント対応者までの報告、対応を演習範囲としました。実際のインシデント発生時に必要となる社内組織への報告や、被害の把握などのプロセスは対象外としました。
演習当日のスケジュール：演習参加者には演習の日時を事前に共有し、参加の稼働を確保してもらいました。
演習場所：現在は在宅からの勤務が主流であることから、関係者が集合して演習するのではなく、自宅から情報収集、指示などのハンドリングを行いました。
演習開始のトリガー：セキュリティ検知機能側のチューニングなどにより、演習実施時に生成する通信からアラート生成、被疑端末を作成しました。アラートを生成させるためだけに、実際に端末をマルウェアに感染させたり、悪性サイトへのアクセスを行ったりしないこととしました。

条件が多くあると限定的な演習のように感じられるかもしれませんが、目的や実施体制に合わせて事前に条件を決めておくことが重要になります。

演習の準備

作成したシナリオを週に1回レビューし、次週までに修正を繰り返し行うことで2つの演習シナリオを作成しました。レビューを繰り返すことにより、シナリオ上の矛盾や実際の運用上では起きえないことなどが修正されていきました。

セキュリティ機能の評価については、シナリオで想定したアラート生成や封じ込めができるかどうかを個々のパートに分けて機能検証を実施しました。個々のパートでは上手くいった機能検証も、シナリオを通したシミュレーションでは上手くつながらないことも発生し、複数回検証する必要もありました。

演習の時間配分については、事前に実施したシミュレーションなどからシナリオ単位でのタイムテーブルを作成しました。タイムテーブルに沿ったチェックポイントを作ることで、演習が予定した時間内に完結できるよう準備をしました。

演習全体のイメージは以下となります

演習

準備したシナリオに沿い、演習しました。シナリオの1つを紹介します。具体的にどのような装置で検知や隔離したかなどの情報は省略しています。

1: 以下のアラートの受信からスタートします。

セキュリティ検知装置から、外部に存在する悪性度の高いサイトへのアクセスが複数発生していることが情報収集・分析者にアラートとして通知される。情報収集・分析者は、アラートの初期調査をすることで悪性サイトへアクセスをしている端末が存在するセグメントを特定するが、外部への通信が暗号化されているため詳細を特定できない。情報収集・分析者はインシデントの恐れがあるとしてインシデント対応者に初報通知を行った。

2: インシデント対応者は、初報の段階ではインシデントであるかどうかの判定ができないため、情報収集・分析者に追加の調査を指示し、以下の情報を得ます。

調査指示内容	情報収集・分析者からの情報	具体的な調査方法
悪性通信を発生させているセグメントはどこか	ゲスト利用が可能なセグメント	トラフィック分析から特定
セグメント外への影響の可能性はあるか	他の内部セグメントへの通信は不可のため、可能性は低い	構成情報、セキュリティポリシーから回答
悪性通信を発生させている被疑端末は複数か	被疑の端末は1台	セグメントのトラフィック分析から特定
被疑端末は特定できるか	端末のIP、MACアドレスを特定できる	被疑端末が繋がっている物理機器から特定
被疑端末が接続している場所はどこか	オフィスの某フロアである	被疑端末が繋がっている物理機器から特定
被疑端末から外部へのアクセスは継続しているか	初報時点から継続している	トラフィック分析から特定
被疑端末からのトラフィックはあるか	ダウンロード方向のトラフィックを発生させている	トラフィック分析から特定
被疑端末の利用者は特定できるか	特定できない	インベントリ情報の調査から回答

3: インシデント対応者は、得られた情報から端末の封じ込め（ネットワークからの隔離）を行う判断をし、情報収集・分析者に作業指示をしました。

4: 情報収集・分析者は、該当端末のMACアドレスをフィルタリングすることでネットワークから隔離しました。被疑端末の隔離後、悪性サイトへのトラフィックが停止したことを確認しています。

5: インシデント対応者は、詳細を把握するためオフィスにいる社員へ被疑端末とその利用者の特定を依頼しました。被疑端末の利用者が発見され、ヒヤリングにより被疑端末が社内管理のインベントリに未登録の端末であること、悪性通信と判断される暗号通信は個人の検証目的で発生させていたことが判明しました。

6: インシデント対応者は全ての情報から、今回はマルウェア感染や情報漏洩などのインシデントは発生していないと判断し、未登録の端末を利用していたことに対しては厳重注意することでシナリオをクローズとしました。

以上が演習の大まかな流れになります。今回の被疑端末はシャドーIT的な利用を想定しました。シナリオの中では封じ込めの判断、対処方法などが判断ポイントとなるよう作成していましたが、適切な判断と対処指示がなされたと思います。

以下は、事前に作成した演習のタイムテーブルになります。

演習からの課題

演習終了後の参加者で意見交換を行い、いくつかの意見、課題が挙げられました。

演習の作成においては、シナリオのレビュー、事前準備の重要性があげられました。特に実環境での演習においては、想定したシナリオどおりにアラートが検出できないことなども発生したため、事前のシミュレーション、確認作業が重要になります。

また、オンラインを前提としたインシデントハンドリング、対応時のルールの不備が課題に挙げられました。複数の対応者がいる場合、オンライン上で誰がどの対応をしている状況かなどの状況も見えにくかったため、インシデント対応時のコミュニケーションツールの使い方、ルールなどの取り決めが必要になります。

改善すべき点として、セキュリティ検知、対策機能などのドキュメント不足があがりました。特に、インシデント担当者がスムーズに判断、指示できるよう、最新化したドキュメントを事前に共有しておく必要があります。

まとめ

今回、自作のシナリオによるインシデントハンドリング演習を企画、実施しました。インシデント（恐れ）発生時の連絡体制やインシデントハンドリング時の検知、対策機能の課題や改善点を洗い出すことができ、当初の目的は達せられたと思います。

今後は、今回の演習で課題となった点の改善をすすめます。次回の演習としては、インシデントを突発的に発生させることを実施したいと考えています。また、新たに発生したインシデント（恐れ）を擬似したシナリオを作成することにより、演習の最新化も行っていく予定です。

目次