学びのまとめ
- セキュリティ体制が固まってきた組織にこそ、欠員を想定した訓練は有用。
- 欠員時にこそルールと実対応の齟齬が明確になる、日頃からルール更新が重要。
- インシデント時こそ日頃の経験が出る、安定した体制構築には層の厚さが必要。
はじめに
はじめまして、おくさんです。
このたび「主要メンバー不在時の対応」をテーマとしてインシデント訓練を実施しました。示唆に富んだ訓練となりましたので、皆様の参考になればと思い、お話しさせていただきます。
訓練の目的
今回の訓練では、「主要メンバー不在時の対応」をテーマとしました。シンジをはじめとする弊社の創業メンバーやセキュリティチームは精鋭揃いだと思っていますが、常に全員が対応できる状態であるとは限りません。
そこで今回は、主要メンバーが対応できない状態であっても。規程に沿って組織としてインシデント対応できるようにすることを目標と定めました。この条件下で訓練を行うことで、インシデント対応を属人化させず、情報セキュリティ管理責任者が安心して旅行に行ける環境を目指していきます。
具体的には、以下の条件のもとで、インシデント対応訓練を実施しました。
- 代表取締役・情報セキュリティ管理責任者の不在
- ISMS関連に詳しいセキュリティエンジニアを事故の発生者役として、インシデント調査・対応に関与できない状態にする
訓練の前提条件
弊社の構成は下図の通りです。
今回のインシデント訓練では、以下のSaaSを利用しました。
| インシデント対応で登場するSaaS | 略称 | 用途 |
|---|---|---|
| Microsoft Defender for Endpoint | MDE | EDR |
| Microsoft Defender for Cloud Apps | MCAS | SaaS監視 |
| Microsoft Sentinel | Sentinel | セキュリティ運用自動化 |
| Microsoft Azure AD | Azure AD | ID管理 |
| Okta Identity Engine | OIE | ID管理 |
| Netskope CASB/SWG | Netskope | Cloud Access Security Broker、Secure Web Gateway |
| Netskope Cloud Firewall | CFW | Cloud Firewall |
| Druva inSync | Druva | PCのバックアップ |
| Notion | – | ドキュメンテーション |
| Zoom Phone | – | クラウドPBX（電話） |
| Zoom | – | Web会議 |
弊社特有の想定としては、全社員がフルリモート勤務である点があります。
- 物理的なオフィスがほぼない。
- インシデント対応訓練も、全てリモート対応での完結が必要。
インシデント対応訓練の流れ
MDEでの自動対応に失敗したマルウェア検知アラートを起点に、インシデント対応訓練を実施しました。
インシデント対応は以下のステップで進行するため、ステップ毎に訓練で実施した内容をまとめました。
- セキュリティチームによるマルウェアアラート検知
- 情報セキュリティ委員への報告と初動
- インシデントリーダーによる起票と対応メンバーの参集
- 対応メンバーによる調査
- インシデントリーダーによる重要度確定と処置
なお、訓練には以下のメンバーが参加しました。
| 役割 | 説明 |
|---|---|
| 情報セキュリティ管理責任者 | 情報セキュリティ委員会内部での最終決定権を有する。 |
| 情報セキュリティ委員 | 情報セキュリティ委員会に所属し、ISMS等の対応を行う委員。 |
| セキュリティチーム | 主にセキュリティ製品を扱うエンジニアチーム。自社に導入しているセキュリティ製品を使った監視やセキュリティ運用を担当している。 |
| インシデントリーダー | インシデント対応のハンドリングをおこなう。 |
| 技術リーダー | インシデント対応の技術的指示を行う。 |
| 対応メンバー | インシデント対応を行う。インシデント対応に必要なメンバーが招集される。セキュリティチームと重複あり。 |
| 対象者 | インシデントの起点となったアラートが発生した事故端末の利用者。 |
セキュリティチームによるマルウェアアラートの検知
事故端末上で疑似マルウェアファイルを実行し、マルウェアとして検知させることでアラートを発生させました。発生したマルウェア検知のアラートを受けて、MDEを運用するセキュリティチームが初動調査を行いました。
対象者へヒアリングしたのち、MDEの自動調査結果を確認したところ、自動解決されておらず「不審」と判断されるため、問題は継続中として次のステップへ進みました。
情報セキュリティ委員への報告と初動
セキュリティチームは前ステップでの調査内容をまとめて、Slackワークフローを用いて情報セキュリティ委員へ報告（エスカレーション）を行います。
報告を受けた情報セキュリティ管理責任者が自身をインシデントリーダーに任ずるのが通常の流れですが、Slackで確認したところ代表取締役と情報セキュリティ管理責任者共に不在と発覚。急遽メンバーをZoomへ招集し、改めて情報セキュリティ管理責任者へZoom Phoneで連絡をとろうとするも、接続できませんでした。
そのため情報セキュリティ委員は代理のインシデントリーダーを選任し、インシデントリーダー主導で報告者（セキュリティチーム）へヒアリングを実施、ヒアリング結果と社内規程をもとに暫定的な重要度判断を行いました。
暫定的な重要度判断としては、MDEの自動応答で試験用の疑似マルウェアファイルへ対応できておらず、マルウェアファイルが他PCなどへ感染すると被害拡大につながる恐れがあるため、重大なインシデントと判断しました。
インシデントリーダーによる起票と対応メンバーの参集
インシデントリーダーは暫定的な重要度判断を行った後、アドバイザーとして技術リーダーを招集し、Zoomを繋いで相談を行いました。
技術リーダーとの相談内容は、以下の通りです。
- 初動対応として行う行動は何か
- 対応メンバーとして誰を参集するか
方針が定まり次第、本インシデント対応用のSlackチャンネルとNotionページを立ち上げを依頼し、対応メンバーをそのSlackチャンネルへ招待しました。
対応メンバーによる調査
インシデントリーダーは、招集した対応メンバーへ現状説明と実施して欲しい内容について案内しました。対応メンバーは、インシデントリーダーの指示のもと、以下の調査を順番に実施していきました。
- マルウェア侵入状況の調査
- 想定：社内へのマルウェアの拡散はありませんでした。
- 実際の結果：MDEのAdvanced Hunting およびDruva のFederated Searchにより調査したところ、被害端末以外の1台で同じファイルが発見されました。
- マルウェアの侵入経路の調査
- 想定：ネットからダウンロードしたZIP暗号化ファイルから侵入したことを確認しました。
- 実際の結果：想定通りでした。
- マルウェアの感染に伴う流出・被害の調査
- 想定：被害端末上にマイナンバーを含む個人情報（ダミー）が発見されましたが、社外への情報流出はありませんでした。
- 実際の結果：想定通り個人情報が発見されたが、被害端末よりZIP暗号化ファイルがアップロードされていることが発見されました。
インシデントリーダーによる重要度確定と処置
調査結果の報告を受けて、インシデントリーダーにより重要度の確定を行いました。
- 重要度の確定
- 想定：被害端末上には要配慮個人情報を含む個人情報ファイル（ダミー）が存在するものの、マルウェアの拡散や社外への流出等の被害はありませんでした。そのため「軽微インシデント」と判断しました。
- 実際の結果：被害端末からZIP暗号化ファイルのアップロードが発見されました。このZIP暗号化ファイルは、訓練後の調査で無害なファイルであると確認できましたが、訓練時間中には内容確認まで至りませんでした。そのため、要配慮個人情報を含む個人情報（ダミー）がZIP暗号化ファイルとして外部へアップロードされた可能性を踏まえ、「重大インシデント」として判断しました。
その後、インシデントリーダーは重要度に基づき処置の決定を行い、対応メンバーへ処置の実施を依頼し、訓練を終了しました。
- 処置の指示と訓練の終了
- 想定：軽微インシデントという重要度判断を踏まえた処置の指示を行う想定でした。具体的には、被害端末の初期化と、ネットワーク分離の解除、Druvaバックアップファイルからの復元（疑似マルウェアファイルを除く）の実施を行い、被害端末を業務利用できる状態にし、それを以て訓練の終了とします。
- 実際の結果：重大インシデントと判定されたため、想定と異なる対応が必要になりました。重大インシデントの対応時に必要となる顧客連絡など影響の大きい処置は代表取締役の承認を得ることになっています。ここで予定していた訓練の時間を使い切ってしまっていたことから、重大インシデント時の対応を踏まえた処理を今後の題材として、訓練を終了しました。
インシデント訓練による学び
ルール・手順のアップデートの必要性
今回のインシデント訓練では、普段主導しているメンバーが不参加であったこともあり、進め方に非効率な部分やミスが発生しました。
たとえば弊社では、インシデント発生時にNotion（記録SaaS）でセキュリティインシデント報告書を発行し、全員で同じファイルを確認・編集しながら調査を進めていくことで、報告や共有の遅延を最小限にしています。しかし今回の訓練では、作業者が複数いたにも関わらず、それぞれの調査や対応を並行して実施できませんでした。これはインシデントリーダーが事前想定された調査事項のカバーを意識しすぎており、調査事項を順番に指示していたことに起因します。
また、作り込まれたルールや手順であっても、バージョンや環境の更新などにより想定と異なる挙動をすることがあります。今回の訓練でも、そういった想定外が発生しました。
例として、情報セキュリティ管理責任者のスマートフォンに導入したZoom Phomeへ緊急連絡を実施した際、スマートフォンで電話の着信通知を受け取れませんでした。後の調査で、モバイル版Zoom Phoneの不具合により電話着信時に通知が受け取れない不具合があることをZoom社から確認しました。この不具合は、ブログ公開時点で既に修正済みです。
慌てやすいインシデント発生時において、考えることが増えるほどミスは発生しやすくなります。いつもと違うメンバーによる慣れない対応であればなおのことです。これまで運用出来ていた必要十分な記載で満足せず、欠員時のように慌てがちな状況でも必要な対応を行えるよう、ルールや手順を実態に沿った形へ定期的にアップデートしていくことが必要であると実感しました。
インシデント体制構築の重要性
今回の訓練の過程において、いくつもの想定外のトラブルに遭遇しました。しかし今回訓練に参加したメンバーは、代替手段を提示してトラブルを解決し、インシデント対応を進めました。これは、日頃から業務で関連するSaaSを扱い、深い知見を持つことによるものと考えています。
例えば、マルウェアファイルの侵入経路の特定にあたり、元々はMDEで検出することを想定していました。しかし訓練時、MDEのタイムラインからそれらしいログを発見できず、デバイスファイルイベントでもすぐに見つけられませんでした。
そこでNetskopeを確認し、Application Eventでダウンロードされていることを検出しました。
また別のトラブルの事例として、想定していたコマンドが動作しなかったものがあります。マルウェア拡散防止のために事故端末をネットワークから分離する作業を、MDEのLive Responseという機能を用いて実施する想定でした。しかし実際の訓練ではLive Responseの応答が遅くなり、ネットワークからの分離コマンドが実行困難な状況となりました。
そのため管理者側からの遠隔操作による制御へ固執せず、代替手段として手動でWi-FiをOffにすることを対象者へ指示し、ネットワークからの分離を実施しました。
訓練においても想定外が多数発生したように、本番のインシデント対応において、予想しないトラブルが発生することはむしろ当然と言えます。予想しないトラブルに対応してこそのインシデント対応ではありますが、緊急時にあっても冷静に対応するためには経験がものを言います。一方で、いつも対応しているメンバーだけが経験を積んでいった場合、欠員が発生した際に穴ができる懸念があります。
誰かが欠けても安定して対応できるインシデント対応組織であるためには、インシデント対応可能なメンバーの層が厚いことが重要であると考えます。
まとめ
訓練での教訓をまとめますと、「インシデントは欠員前提での備えが必要」という至極普通の結論となりました。
どんなにすごい人がいたとしても、災害時に必ずその人が対応できるとは限りません。すごい人の存在を前提にした事業継続計画は、いざ本番に機能しないリスクが残ります。
だからこそ訓練では欠員を意識して、規程の見直しや手順の定型化、幅広いメンバーへの訓練を実施していくことで、本番のインシデントで対応できなくなるリスクを下げることが重要と考えます。ある程度インシデント訓練を実施しており、対応がこなれてきた組織にこそ試して頂きたいです。
課題も多くありましたが、上手くいかなかった部分を含め、得るものの大きいインシデント訓練となりました。情報セキュリティ管理責任者が安心して旅行へ行けるよう、改善へ着手しています。
長い記事となってしまいましたが、お付き合い頂きありがとうございました。皆様の組織で行うインシデント対応の参考になれば幸いです。
