インシデント対応訓練をおこないましたよー

はじめに

けーすけです。今回はmxHERO以外のお話です。先日弊社でインシデント対応訓練を行いました。そこで一定の成果があり、問題点の洗い出しもできたのですが、結果として細かい技術上の問題に留まらず、様々な課題が浮かび上がってきました。これをどうやって解決していこうとしているかということも含めお話していきたいと思います。インシデント対応訓練を行なっている、またはこれから行おうとしている方のご参考になれば幸いです。

なお、今回は非常に規模が大きい検証のため、技術的な箇所については、主担当二人にインタビューを行う形式で記載していきます。主担当はそれぞれ、弊社の吉永(kakeru)・辻(tsuji)で、吉永はNetskope等のCASBまわり、辻はWindowsのデバイスまわりを得意としています。

それでは、以下進めていきます。

なお、今回は製品紹介の記事ではありませんが、記事の最後のほうで、Oomnitzaという製品に少し言及しています。

この記事の概要

非常に長い記事になりますので、全体の概要を先にお知らせしておきます。この記事は以下のことを解説しています。

• 訓練で想定した状況と意図
• 弊社のシステム構成
• 各種対応とツールの対応関係(なにを導入するとどういう対応ができるのか)
• ツール以外に必要なもの
• 各主担当者の意図や注力ポイント
• 訓練内容と発生した問題、原因、ロジック設定などの技術的なディテール
• 今回得られた教訓と課題、対応策
• 主担当者の感想

各システム・ツールの使い方や設定方法には本文中では言及していませんのでご注意ください。（一部の検知・アラートのロジックの設定方法などについては、別記事へのリンクがあります）

訓練で想定した状況と想定の意図

それではまず、訓練で想定した状況です。以下を設定しました。

従業員Aのアカウントによるboxからの大量の文書のダウンロードが検出された。従業員Aは、山陰地方の自宅で在宅勤務しており、システム管理者は直接的な物理的抑止を行うことができない。

従業員Aの意図は現時点では不明であるが、大量の文書のダウンロードはいまだに継続している。

注記
1. 従業員Aの意図や、アカウントの乗っ取りか否かは状況開始時点で不明であるものとする。
2. Boxでの大量ダウンロードの検出がされたことは、従業員Aは状況開始時点では認知していないものとする。
3. 従業員Aは社内のいかなるシステムについても管理権限を持たないが、社給端末については、ローカル管理権限を持っている。
5. 従業員Aは社給の端末として、
- Macbook Pro
- Windows 10 端末(検証用)
- Macbook Air(検証用）
- iPhone
各1台を保有する。
また、これら以外に、記憶媒体を内包する端末（私物）を所有している可能性があるものとする。

ご覧のとおり、典型的な内部犯行が”疑われる”例です。なお、場所が”山陰地方の自宅”として設定されているのは、リモートワーク環境下かつ、システム管理者も他の社員も現場に急行できないという状況下とするためです。

また、”意図は現時点では不明”としているのは、あえて”悪意で行っている”と定義せずに、ただのミスである可能性を残し、”どこまでの対応が一般的に許容されるか”を常に考慮しながら対応を進めていくことを狙っています。

難易度は上がりますが、現実の問題では、”悪意があるかないか”は通常、監査ログなどの証跡との照らし合わせによって初めて判明するものです。

技術的な部分だけでなく、そういった意味でも現実的な訓練となるように状況想定を行いました。

ほか、BYODそのものではありませんが、”会社管理外の端末にデータが出ていくとどうなるか”を確認するため、私物のなんらかの端末を持っていて、意図的なデータの窃取であれば、すぐにそこにデータを格納して逃亡できる、ということを意図的に前提に含めました。

訓練の目的

上記状況で、情報の持ち出し（漏洩）を防止するために、必要な対策を、事前・事後の大きく二つに分けて想定し、整備が必要な環境・施策とその効果、実施手順について詳細なシミュレートを行うものとする。

これが訓練の目的として設定したものです。もう少し詳細に、かつ噛み砕いて書くと以下になります。

• 事前対策の導入・整備状況の確認（環境・施策の整備ほか事前準備全般）
  • 対応のためにどういうシステム・設備が必要か（対応が成立するための構成要素は何か）が洗い出されているか
    • 異常を検知・通知できるシステム・設備か
    • 情報資産が格納されているシステムなど、証跡を取得しなければいけないシステムに、監査ログなどの機能は備わっているか
    • アクセスの遮断など、不正な操作や攻撃の遮断や被害の拡大の防止が可能な機能が備わっているか
  • 素早く停滞なく対応可能な手順が事前定義されているか
    • 対応全般の手順があるか
    • 不正の疑いがある場合など対応に注意を要する場合の例外処理の手順は定義されているか
    • 判断に迷う場合のための対応ポリシーはあるか
    • 機能の実行の詳細についての手順（プレイブック）があり、実現可能な状態になっているか
  • 手順を実行するための妥当性が社内規定などによって担保されているか
    • 権限は担保明記されているか
    • 従業員の義務は周知されているか
    • 会社側がしないこと（してはいけないこと）は明確になっているか
    • 同意を要するものについて同意を得ているか
• 事後対策（対応の実施）
  • 手順の想定通りに実施可能か
  • 手順の想定漏れにより対応が停滞することはないか
  • 有効な対応が取れたと判断できるか
  • システム・設備の動作はプレイブックの想定通りか

これらの項目について、対策の成否ではなく、問題点を洗い出して改善材料を得るため、という観点で確認していきました。

なお、弊社の場合はこれら全ての前提に、

”ゼロトラストアーキテクチャを採用したフルリモート環境下において、”が設定されています。

また、内部不正を視野に入れた訓練のため、この記事はアクセス権管理が適切に行われている環境下である前提で記載しています。

想定環境

今回は、本番環境をそのまま利用して、業務時間内に訓練を行いました。

ただし、訓練で想定した状況により、今回の訓練で関係するシステムはこれらのうちの以下になります。

• Okta（※メインのIdP）
• Azure Active Directory（Azure AD）
• Microsoft Sentinel/Azure Logic Apps
• Intune
• Jamf Pro
• Netskope
• Microsoft Defender for Cloud Apps（旧略称：MCAS）
• Box
• Slack （※Enterprise Grid）
• Zoom

※Microsoft Defender for Cloud Appsについては、通知名などに旧称の時点で設定されたものがあることから、スクリーンショットなどとの整合性のため、この記事ではMCASという旧略称で記述しています。

図に表したものが以下になります。
なお、補足ですが、管理外SaaS（右上）からNetskopeに矢印が伸びているのは、管理外のSaaSに対しても、端末にNetskopeエージェントが入っていれば、つまり適切に設定された社給端末であれば、検知できるものもある、ということを表しています。

今回の各種対応についての各ツールの期待機能（なにを導入するとどういう対応ができるのか）

二つ前の項の図にも期待する機能は図示されていますが、各ツールに期待する機能の概要を文字に起こすと以下になります。

IdP

Okta
Okta で SSO 構成済みのクラウドサービスにて異常を検知した対象アカウントを無効化し、新たな認証をブロックする

Azure Active Directory
Azure Active Directory で SSO 構成済みのクラウドサービスにて異常を検知した対象アカウントを無効化し、新たな認証をブロックする

SIEMほか通知・コミュニケーション

Microsoft Sentinel/Azure Logic Apps
アラート類を集約・処理し、Slackに通知する

Slack
通知の受信のほか、プライベートチャンネルを作成し、HQ的な役割を担う

Zoom
映像・音声ベースのコミュニケーションを行い、必要に応じて録画・保存し、証跡とする

クラウドストレージサービス

Box
本サービス上の対象アカウントを無効化することで即時ファイル等のダウンロードや閲覧をブロックする。また、アクティビティログ等の各種機能により、操作自体の取得のほか、証跡の信頼性全般も担保する

CASB

Microsoft Defender for Cloud Apps(※旧略称：MCAS)
API接続した自社管理のBox上のアクティビティを監視し、Box上にてファイルの大量ダウンロードを検知した場合に異常検知のアラートを通知する

※Microsoft Defender for Cloud Appsについては、通知名などに旧称の時点で設定されたものがあることから、スクリーンショットなどとの整合性のため、この記事ではMCASという旧略称で記述しています。

Netskope
Netskopeエージェントを導入している端末でのTCP80/443を利用した通信を記録/制御する

MDM

Intune
Windows 端末にてリモートワイプを実行することで端末上のすべてのデータを削除し、Boxへのアクセスおよびローカルデータの流出を防止する

Jamf Pro
Mac端末および iPhone 端末に対してリモートロックを実行することで端末上の画面をロックし、Boxへのアクセスおよびローカルデータの流出を防止する

ツールの各機能の有効性評価

訓練自体の有効性確認項目以外に、上記の各ツールで機能が有効に動作したかを確認するために以下を設定しています。

• アラート発生
  • 大量ダウンロードのアラートを発生させられたか
• アラートの通知と検知
  • アラートの検知が行えたか
• 調査の実施
  • アラートの調査に必要な情報の収集が行えたか
• 端末制御
  • 端末のリモートワイプ/ロックが行えたか
• アカウント制御
  • SaaSアカウントの停止が行えたか
  • SaaSアカウント停止によるセッションの切断が行えたか

ツールや技術以外に必要なものについて

対応するためのツールとそれを操作する技能を備えた技術者以外にも、その技術を有効かつ適正に行使するために、最低限以下が必要になります。

訓練の目的の項と重複しますが、以下の2点です。

• 素早く停滞なく対応可能な手順
• 手順を実行するための妥当性の社内規定による担保

弊社では、素早く停滞なく対応可能な手順とするために、以下を作成しています。

• セキュリティインシデント対応ポリシー
• セキュリティインシデント対応手順書
• 秘匿を要するインシデント対応手順の特例

このうち、セキュリティインシデント対応ポリシーについてはNIST 800-61を参照しつつ、セキュリティインシデントの定義や、対応要員の人選基準など、考え方について、当社独自の要素を加味して定義しています。
（※以下はその一部の抜粋です）

セキュリティ対応手順書については、網羅的になるように意識した上で、技術的な要素は最低限に抑えつつ、対応が無事完了した場合のほか、長期化した場合や、どういったケースではだれに判断を仰ぐか、証跡をどのレベルで何を確保するか、というところまで記載しています。

また、項目によっては、代理承認者や、承認権限者が無応答な場合にどのくらいの時間経過で現場判断で対応を実施するかというところまで記載しています。

ほか、秘匿を要するインシデント対応手順の特例についても、不審な操作をしている者が自分の意思で行なっているケース以外に、脅迫を受けてやむなく実行している場合、そしてそれを監視されているようなケースも想定に含めて記述しています。

折り返し

以上、ここまでが想定や構成など、道具立てについての記述になります。以降は、役割分担と吉永と辻それぞれの訓練実施についての意図と事前準備を挟んだうえで、実際の訓練当日のディテールに記述内容を移していきます。

なお、吉永と辻の個人名が記載されている項は、受け持つ箇所や、それぞれの個性による受け止め方や課題感の違いがでているため、各自が記載したそのままの形でお伝えします。

今回訓練実施の役割分担

訓練の役割分担は以下になります。

• プレイブック作成や、検証環境等の決定などの主担当者（吉永・辻）
• 各関連するSaaSの管理権限を持っている者それぞれ1名
• ほか関係者
• インシデントハンドリングを担当する”インシデントリーダー”（三上）※私です。
• 技術的な判断を統括する”技術リーダー”
• エスカレーション先としての役員1名
• 同じくエスカレーション先として情報セキュリティ管理責任者（三上）

兼任はありますが、以上のように関わった人数としても大規模な訓練となっています。

各主担当者の注力ポイント

各主担当者の事前準備や想定

訓練内容と発生した問題、原因

ここからは訓練当日の流れと技術的なディテールになります。なお、弊社の対応手順書上は報告書の作成や対応完了後の処理まで定義されていますが、ここではそれは割愛します。

ほか結論としては、結果的にはIntuneによるリモートワイプ以外は、いくつかの気づきを得るポイントはあったものの、概ね成功に終わりました。以下がそのディテールになります。

1. 異常の検知とアラートの発報

ロジック

訓練時に利用した通知ロジックの概要は以下となります。

• BoxとMCASをAPI連携し、MCASのアラートをSentinelに流すように設定 （MCASのポリシーにて、一定時間以内に大量のダウンロードが発生した際に通知するテンプレートを利用）
• MCASにて発生したアラートがSentinelに通知
• Logic Apps にてSentinelに集約したAlertをSlackに通知 （設定方法は別途ブログ記事にしております）

以下は実際の通知の画像です。

発生した問題と担当者の感想

アラートが通知されるまで想定より時間がかかった（吉永）

BoxのログをMCASに繋ぎ込んでMCASでのアラート発生の準備も実施し、実際に動作確認まで行っていたのですが、実際にアラートが発生したのは、開始からおよそ3時間後でした。

SaaS同士を連携する場合、APIの実行間隔やインターネットの通信状況に左右されるため、訓練の場合はアラートを発生させる作業の実行からシミュレーション開始までのリードタイムは長めにとり、待機時間が発生しないようにすることが必要だと思いました。

今回のケースでは、想定が遠隔地であることに加え、

• 大量ダウンロードはそもそもの性質上、一定の数に達してはじめて”異常事態”となる（大量ダウンロードの意図があるかないかは、操作が開始された時点ではわからない）
• 分析という作業自体がリアルタイム性を追求できる性質のものではない（分析＝ある程度の時間枠内での挙動を見て異常か正常かの判定を行う）

ということで、通知が上がるかどうかは重要ですが、そのリアルタイム性自体は問題にはならないようなケースが訓練時の状況として想定されていました。

しかし、それを踏まえた上でも、SaaS同士を連携する場合はAPIの実行間隔やインターネットの通信状況に左右されるため、MCAS側でのログ収集から設定したアラート発生までに時間がかかるものであるということは大原則として意識する必要があると感じました。

また、アラートが上がるまでに時間がかかる前提のもとに効果的に運用するためには、

• 不正操作について十分な証跡を取得できる環境が整っている
• 該当操作を行なった者の居所・連絡先、緊急連絡先（本人と連絡が取れる人）などが把握できている

ということが非常に重要だと考えます。

2. Slackのプライベートチャネルの作成と証跡保管用Boxフォルダの作成から、対応要員の参集、状況説明と対応開始まで

こちらについては特に技術上の問題は生じませんでしたが、Slackなどのテキストコミュニケーションのプラットフォームがない場合は、スムーズな進行は難しいだろうと感じました。

前半に記載の通り、Zoomも併用し、録画も必要に応じて取得できるようになっていますが、対応内容としてなにが話し合われたか、などは文字でまとめてSlack上に明示的に再記入したほうが認識の齟齬を防ぐことができ、かつ対応の記録としても大した労力なしに二重化されます。

ほか、各対応の完了報告なども、Slackで行うほうが、スムーズかつそのまま時刻付きの記録として残りますので、非常に重要なポイントであるように思いました。
加えて、当社はSlack Enterprise Gridですので、削除したコメントも監査可能であり、ログの改ざんの観点からも有効性が高いと言えます。

また、Boxを証跡の保存場所とすることで、共同作業が可能なほか、証跡としての有効性について疑問が生じる余地を低減することが可能となります。

この辺りが疎かになっていると、技術的な対応が終わった後の、報告のとりまとめや訴訟対応などに支障をきたしますし、それ以前に本人の否認に対抗できなくなるケースや、逆に冤罪が生じるケースを防ぐことができます。

また、前項と重複しますが、証跡の保管にとどまらず、”誰がいつなにを行ったかが十分な情報量をもって記録されている”ということは全ての前提になります。

ですので、問題は発生しなかったものの、私個人としてはBoxがデータガバナンスを重視したオンラインストレージであることの重要性を改めて実感しました。

3. IdP/SaaSアカウントの停止

今回の訓練では、IdP/SaaSの3つのアカウント停止を行なっています。それぞれの操作の目的は以下のとおりです。

• Box
  • 持ち出し対象のデータが格納されているSaaSであり、持ち出し被害の継続や範囲の拡大を防ぐため
• Okta
  • SSO 構成済みのクラウドサービスにて、新たな認証をブロックし、他のSaaSへの被害の拡大を抑止するため
• Azure Active Directory
  • Azure Active Directory 側で SSO 構成済み (Office 365 など) のクラウドサービスでの新たな認証をブロックし、他のSaaSへの被害の拡大を抑止するため

こちらについても、問題は生じずスムーズに実施できました。ただし、スムーズに進みすぎたことによる待ち時間の発生や、営業日に行ったことによる作業担当者の一時的な離脱があったことによって、後述する”対応の属人化”の問題を、課題として強く意識するきっかけとなりました。

4.端末のリモートロック/ワイプ

• Mac
• Windows
• iPhone

発生した問題と担当者の感想

会社支給のiPhone端末のロックがかからない（吉永）

事前の動作確認の際には、リモートロックの実施・解除までの作業は問題なく実施できていました。しかし、本番ではリモートロックがかけられず、本作業を断念し、要原因確認事項となりました。

原因は、Jamfへの登録を手動にしたことにより、管理モードでの登録ができていないことでした。会社支給でMDMに登録されている端末であってもリモートロックがかけられなかったケースが発生したことで、端末の管理規定を見直す機会となったと思います。

Windows端末のリモートワイプは時間がかかる（吉永）

訓練中、Windows端末は常に電源をOnにしており、Wifiに接続されている状態でしたが、インシデント訓練中にはワイプは実行されず、実際にワイプが実行されたのは、翌週でした。

リモートワイプの成功率はそれほど高くない、とよく聞きますし、自分のこれまでの実感としてもそれはあったのですが、翌週というのは正直予想外で、この動作の遅さからもリモートワイプに頼らない環境の構築が必要であると感じました

訓練を終えて（主担当者それぞれの感想）

訓練当日の対応の感想

教訓と感じたこと

今後どういう方向に整備していきたいか

三上（けーすけ）個人が感じた課題・感想

吉永と辻が感じたこと以外、または、同じポイントでも感じ方が違ったものについて以下に記載していきます。なお、この箇所の記述は訓練直後の感想と現時点の考えが混在していることをあらかじめお伝えしておきます。

訓練全体について

今回の訓練は、細かい想定外はありましたが、そういった問題点の洗い出し自体が目的だったこともあり、全体としては成功したと考えています。

しかし、細かい改善ポイントのほか、特に以下のような課題があると認識しました。

個人スキルに依存している

今回の対応については、”十分なスキルを備えた人員を参集した”結果成立しています。それ自体は非常に喜ばしいことなのですが、訓練ではなく実際のインシデントの発生は必ずしも要員の確保ができるタイミングで起こるとは限らず、また、偶然の事故ではない場合は”意図的に対応できないタイミングが狙われる”ことのほうが自然と考えます。

弊社はまだ、集団から組織への移行期にあり、人的な互換性が十分とは言えません。また、人的な互換性については、必ずしも人員数だけで測れるものではありません。

ここをどうするか。

規定類の周知などが不十分

吉永の感想に、

会社としてBYODを認めるのかどうかという点について議論する必要があると感じました。

という箇所があります。実はBYODについては訓練時点でも、どういう用途でどういうものなら使用できるかという定義自体は存在していました。

しかし、これは単純な吉永の見落としということではなく、この時点の規程について、以下のような問題があるということだと捉えました。

• 規程自体への導線が悪い（単純な周知の問題）
• 規程そのものを解釈しなければ意図がわからないような記述になっている（可読性・解像度設定の問題）
• なぜそのような規程があるのかの説明や背景、議論の記録とその周知も不足している（コミュニケーション・ナレッジ集積の問題）

もし、これらの問題がなければ、”新しく問題点として認識できたこと”として議論の必要性が記述されることはありません。逆に社内で行われてきた議論自体は、概要に次項で言及いたしますが、比較的全方位的なものです。

つまりこれは説明の不足以前に、議論自体の存在が認識されていない・記録がない、または記録に再利用性がないということです。これはもちろん吉永の問題ではなく、規定などのほうに問題があるということです。また、BYODについての議論の記述に限らず、全社的な課題の氷山の一角と考えました。

ここをどうするか。

管理外端末やBYODについて

ほか、これは課題というより、個人的な感想になりますが、今回の訓練では、”私物の端末（管理外端末）があり、それにデータを移動させることが容易である”という状況を設定して、管理外の端末、ひいてはBYOD端末にデータがある場合に有効な抑止が働くかということも確認しましたが、事前の予想通り、検知は可能なものもあるが、会社管理外の端末にデータが移動してしまった後に行えることはほぼないと言ってよい、という結果になりました。

つまり、BYODの利用に当たっては、このリスクを踏まえた上で、さらに以下の基本的な事項を考慮に入れ、やむを得ない場合にのみ行うということが妥当であるというように再確認しました。

• BYOD端末から行なってよい業務（アクセスできるアプリケーション・プラットフォーム）を明確に定義・制限する
• BYOD端末から行なってよい業務を定義した上で、その業務についての総所有コストとして社給の管理下の端末を配布するより安くなるか高くなるかということをあらかじめ検討・認識しておく
• その他、端末にインストールされたソフトウェアの使用許諾違反の可能性など、可視化できないリスクを複数抱えることになることをあらかじめ認識しておく
• 事後対策および、BYOD端末を利用している従業員などに予見可能性を提供するため、処罰および根拠規程を含めた有効な同意書面を取得する

※BYODの利用についてはこれら以外にも無数の論点がございますので、上記はあくまで代表的なものとしてご理解いただき、詳細な論点については、弊社と経産省様とで実施した実証実験のドキュメントをご参照ください。
なお、BYODについての記述はPDF全体の中の93枚目から始まる、”BYODポリシー雛形”に詳述されています。

https://github.com/meti-dx-team/METI-Digital-Tools

また、例えば所有者の了解のもとにMDMをその私物端末に導入するなどの折衷案をとった場合であっても、それが私物端末である以上は従業員が業務外で使用して蓄積しているデータの所有権や、プライバシー権の問題が新たに発生するため、それで問題が解決するとは言い難いと考えます。

※現時点では、”データの所有権”についての統一的な法的定義はありません。そのため、想定しているものを具体的にしておきます。
緊急事態が発生して、従業員の私物端末がリモートワイプされた場合に、事前同意を得ていたとしても、例えばバックアップ前の家族の
写真などのデータが消えてなくなったときに、”同意したので当たり前”と考える従業員は一般的に多数派か？恨みにつながらないか？
ということです。

ただし、社給端末であったり、上記すべてを満たした管理外端末であっても、悪意をもって情報資産を窃取する場合で、特に恨みに基づくものなど、最初から”うまく逃げ切るということを考慮していないケース”については、対応が後手に回らざるを得ません。

そのため、技術的、法的な対策を事前事後に行うことは当然ながら、そもそも動機などを持たせないということも非常に重要であるということについても、訓練を通じて再確認できました。

なお、不正を誘引する要素としては、動機以外にも様々な定義（不正のトライアングルなど）が考案されていますが、そのいくつかについて、日本システム監査人協会から公開されています。

https://www.saaj.or.jp/kenkyu/pdf/238Shiryo.pdf

課題への対応

ここまで記載してきた訓練については、今から約4ヶ月前に行われたものです。そのため、これまで記載した問題・課題については対策済みであったり、対策が進行中です。

対策全てを公開することは性質上適切ではありませんので、限定的なものにはなりますが、例えば以下のようなものが進捗中または完了済みとなります。

個人スキルへの依存についての対応

この問題については、現在Oomnitzaという製品を対策のためのツールとして検証を進めています。OomnitzaはITAM（IT Asset Management）としての側面をもった製品ですが、大きな特徴として、情報の入力ソースとして接続された各SaaSについて、ワークフローを通じたオーケストレーションが提供されます。

このワークフローは事前定義可能で、Oomnitzaをハブとして、製品を跨いで構成することが可能です。

これを利用して極力各SaaSで行う処理を抽象化し、判断と対応を分離できないか模索中です。

規定類の周知などが不十分であることについての対応

上記にくらべこちらは非常に地味な対応になりますが、課題を単純化した以下の3点が起こらないことを念頭において規定や手順、文書の再整備をしています。

• 読んでもわからない
• どこにあるのかわからない
• なんのためにあるのかわからない

そのため、例えばインシデント対応の手順については、訓練完了後に、”エンジニアでなくても読めるかどうか・解釈の問題が容易に生じないか”を重要な基準として、全体のフローや全てのステップを見直し、内容を改訂するとともに、従来は文字ベースの手順書だったものをスライド化しています。

その他、事業継続計画であったり、個人情報保護などについても同様に、スライド等を社内で作成し、社内全体を対象とした研修を定期的にまたは随時行い、周知・集積も継続的に強化しています。

補助資料などの社内コンテンツ作成においても”エンジニアでなくても読めるかどうか・解釈の問題が容易に生じないか”という視点はそのままに、研修資料や理解度テストなどは社内で作成するなどしていますが、この社内コンテンツ作成においては前提3点のほかに、以下に留意しています。

• （網羅性を重視しすぎて）担当者が理解していないことを中途半端に他人に教える内容になっていないか
• ”こなす”という発想に対して脆弱な構造になっていないか（理解度が確認できるようになっているか）
• （職種や人によって理解度に差があっても、）最低限なんのためにやるのかはわかる内容になっているか
• 後から入社した人が、キャッチアップしやすいか（暗黙知に頼っていないか）

正直なところ、これらを完璧に押さえるということは非常に難しいことではありますし、読む側も違う意味で楽ではないのですが、我々がお客様に提供する品質を向上させ、そこに持続性を持たせたいとの思いから、簡単に投げ出さずに、着実に進めていきたいと考えています。

おわりに

以上だいぶ長い記事になりましたが、弊社で行なったインシデント対応訓練の概要と、それを通して得た気づきについて記載してみました。ぜひ通してお読みいただければ幸いです。有効な訓練を実施できたときは今後もこういった形でフィードバックができればと思います。以上、けーすけでした。