インシデント対応手順
ここでは、インシデント発見・報告・対応時の手順を定めます。
まずここで定める方針以前に、インシデントを未然に防ぐ取り組みをセキュリティ対策基準に準じて実施します。一方で、問題が発生した際に、迅速かつ適切に対応できる準備をしておくことで、万が一の際に問題の拡大や長期化を防ぐ狙いがあります。
インシデント対応の流れ
インシデント報告
インシデント報告手順に準じた対応を行います。
初動判断と対応手順の決定
報告を受けた情報セキュリティ責任者は、以下の順に判断を行います。
- 詳細をヒアリングし、報告内容がインシデントに該当するか判断
- インシデントに該当しないと判断した場合、その理由を記載しNotionのインシデントDBに登録し終了する
- 事案の類型と深刻度を判断し、対応手順を決定し、担当者をアサイン
- 事案が改正個人情報保護法の報告通知義務に該当するか判断
- 該当すると判断した場合、漏えい等の対応とお役立ち資料を参考に、漏えい等報告フォームを利用する
NOTE
情報セキュリティ責任者は、以下の研修動画を視聴しインシデントに備えます。
個人データの漏えい等事案と発生時の対応について
情報セキュリティ責任者は以下の表を参考に、適切なインシデント対応フローを選択・進行します。
類型A-1 当社の 事故・過失 | 類型A-2 サービスの 事故・過失 | 類型B-1 当社への 侵害 | 類型B-2 サービスへの 侵害 | 類型C-1 その他 | |
---|---|---|---|---|---|
Lv1 未発 | 記録対応 または 予防対応 | 記録対応 または 予防対応 | 記録対応 または 予防対応 | 記録対応 または 予防対応 | 記録対応 または 予防対応 |
Lv2 軽度 | 予防対応 | 記録対応 または 予防対応 | 予防対応 | 予防対応 または 対処対応 | 記録対応 または 予防対応 |
Lv3 中度 | 対処対応 | 対処対応 または 公表対応 | 対処対応 | 対処対応 または 公表対応 | 予防対応 または 対処対応 |
Lv4 重度I | 対処対応 または 公表対応 | 対処対応 または 公表対応 | 公表対応 | 公表対応 | 対処対応 または 公表対応 |
Lv5 重度II | 公表対応 | 公表対応 | 外部協力要請 | 外部協力要請 | 公表対応 または 外部協力要請 |
NOTE
この表は事案の類型と深刻度の組み合わせに対して、対応フローを割り当てたものですが、この割り当ては目安であり、個別の問題の性質に応じて適切と判断されるフローが選択できるものとします。
厳密さを重視する場合、細かければ細かいほど正確な分類や対応基準を設定できますが、初動対応時の判断のしやすさを重視し、分類の選択肢が多くなりすぎないようにしています。
対応フローの実行
インシデントへの対応は以下の5つの手フローら適切なものを選択し、その手順に従い行われるものとします。
- フロー1. 記録対応
- フロー2. 予防対応
- フロー3. 対処対応
- フロー4. 公表対応
- フロー5. 外部協力要請
フロー1. 記録対応
記録対応フローは、比較的軽度の問題に対して選択されます。ただしインシデントの記録は、傾向分析、再発時の問題解決での利用、教訓などとして活用されるため、全てのフローにおいて共通して実施される活動です。
インシデントの記録は、以下の順で記載します。明瞭かつ正確に、簡潔かつ網羅的に記述されるよう心がけます。
- 不利益の内容と程度
- 不利益を受けた対象と期間
- 根本原因とその原因への対処状況
- 分析・見解
また記録する際はセキュリティやプライバシーに注意を払います。これは例え保存先・共有先がプライベートな環境であっても同様に注意がされるべきです。
NOTE
特にスクリーンショットは機密情報や個人情報が不適切に露出する形で取得してしまい、それに気がつかず共有されてしまうことが多いようです。マスキング要否を判断することが習慣的になるよう、インシデント発生時でない普段から、相互的に注意喚起がされることが望ましいです。
フロー2. 予防対応
予防対応フローは、将来発生するかもしれない同様またはより深刻な問題を、未然に防ぐための取り組みです。危険察知や問題認知したものの、対処すべき損害が既に存在しない場合にこのフローを選択します。
根本原因の分析の結果、実施と検証に時間がかかる予防策が決定されることも少なくありません。この場合、予防策の実施と検証が十分に計画されていることを以って、インシデント自体は収束を宣言することを可能とします。
フロー3. 対処対応
対処対応フローでは、まず進行する危機・不利益状態の解消を第一とし、これ以上問題が深刻化や拡大しないことを優先します。深刻度が高い場合は、オーナー(お客様や当社事業部)への報告と相談も同時に行います。
問題の深刻化や拡大の脅威が除去されたら、不利益の発生した期間や規模、内容などを調査し、損害を確定させます。この時、復元・復旧・被害軽減などが可能な場合は実施しますが、焦って対応することで二次被害を起こしてしまうことに十分な注意が払われる必要があります。
最終的に回復不能な損害が残る場合、その損害の求償方針についてお客様とご相談します。求償先が当社となり当社が合意する場合、加入する保険の保障範囲で補償が可能か確認します。
これらの対応に並行して不利益を受けた方への謝罪とご説明を行います。一連の対処対応を終え次第、記録対応と予防対応に移ります。
NOTE
当事者の心の動きとして、深刻な問題ほどお客様への報告を渋り遅くなったり、広大な損害に気づかなかったフリをして過小に報告してしまうことがあります。対処対応当事者は、いち個人へのペナルティは課されないことをきちんと理解し、損害は公平・中立に明らかにするよう努めます。
フロー4. 公表対応
公表対応フローは、対処対応フローに並行して外部公表を行うものです。
公表先は以下を候補とし、オーナー(お客様や当社事業部)と相談の上、発表時期や内容を決定します。
- 当該サービスのお知らせ機能
- コーポレートサイトのお知らせ機能
- プレスリリース配信サービス
- IPAへの脆弱性関連情報の届出
NOTE
公表活動を先に行い、個々人への直接の説明やご連絡を省く・後回しにする場合は、それが適切であるか、十分に注意が払われる必要があります。信義誠実に優先する危険回避である場合などを除き、通常は
公表内容は以下の順にそれぞれが簡潔にわかるように記述します。
- 不利益の内容と程度
- 不利益を受ける対象と期間
- 現在の状況と経緯
- 今後の対応
NOTE
未確定の原因や損害範囲への言及には、注意が払われる必要があります。全貌が不明な段階で、自分に影響が無い(または小さい)と誤判断させたり、逆に不安を煽り不要な行動を誘発することも避けられるべきです。
目安として「推測は避け、可能性は積極的に言及」するようにしてください。
- 推測の例: もしかして〇〇の問題が起きている
- 可能性の例: 最大で〇〇名に、最悪で〇〇の問題が起きている
フロー5. 外部協力要請
外部協力要請フローは、インシデント対応において内部のリソースや知識だけでは不十分な場合に選択します。高度に専門的、または対応過程に客観性を要する問題の場合に検討します。
協力要請は以下を候補とします。
- サイバーインシデント緊急対応企業
- フォレンジック調査会社
- 警察などの公的機関
協力の取り付け後は、協力者より特段の指示・提案が無い限り、公表対応フローに準じた進行をします。
NOTE
最悪の状況下で最善の手段をとるための備えとして、平時より以下の取り組みが行われることが望ましいです。
- 協力要請を決定するより具体的な基準・シナリオの検討
- 協力要請候補への相談・見積もり
- シナリオベースの演習、抜き打ち演習などの訓練
対応フローの完了後
各対応フローの完了後、利害関係者にインシデント収束を宣言します。この時、以下が完了・計画されていることを十分に確認の上、収束を宣言します。
- ポストモーテムの実施と記録
- 再発防止策の計画と、有効性確認試験の期日設定
- 利害関係者への報告書面作成、提出、公表
- 求償への対応、損保の補償申請
- 本基準及びWEBサービス開発基本方針の見直し要否の検討
参考1. 類型
インシデントは以下の5つに類型化します。
- A-1. 当社における事故・過失
- A-2. サービスにおける事故・過失
- B-1. 当社に対する侵害
- B-2. サービスに対する侵害
- C-1. その他
NOTE
"インシデント"は、直接的な情報セキュリティ事案に限りません。利害関係者への影響が懸念される問題であれば積極的に当てはめを行い問題解決に役立てるものとします。
A-1. 当社における事故・過失
当社および協力社の担当者による、過失や不足の事態が該当します。
該当例
- 物理デバイスの紛失・不適切な廃棄に伴う情報漏洩
- メール誤送信・共有ディレクトリの誤公開設定
- 担当者の突然離脱などによる業務遂行困難
A-2. サービスにおける事故・過失
当社が関わるプロジェクトやシステムにおいて発生した、過失や不足の事態が該当します。
該当例
- 運用対応時のミスによるデータ破壊、消失、過大請求
- 不具合によるデータ誤送信・誤公開
- プログラムの意図せぬ挙動による誤決済・誤報酬計算
B-1. 当社に対する侵害
当社および協力社の担当者に対して、加害意図が明らかな事案が該当します。
該当例
- 端末上での不正プログラムの実行
- 業務上利用するサービスに対する不正アクセス被害
- 当社職員による内部不正、不正情報公開
B-2. サービスに対する侵害
当社が関わるプロジェクトやシステムに対して、加害意図が明らかな事案が該当します。
該当例
- Webへのスキャンや、不正アクセスに伴う情報漏洩
- システムの一部DBにおけるランサムウェア被害
- 完全性・可用性侵害(改ざん、破壊、DDoS攻撃など)
C-1. その他
上記に分類が難しい事案の場合この類型を選択します。
該当例
- SNS上での不当な風評被害
- お客様の法令違反
参考2. 深刻度
インシデントを以下の5つの深刻度に分類します。
- Lv1. 未発
- Lv2. 軽度
- Lv3. 中度
- Lv4. 重度I
- Lv5. 重度II
NOTE
調査の過程で、大きく状況認識を改めるべき事実などが明らかになった場合、深刻度の判断を改めることが可能です。
Lv1. 未発
実害が発生していない、または高い確率で発生していないと判断される事案が該当します。
該当例
- 顧客宛のメールを、誤って社内宛に送ってしまった
- デバッグ情報が表示される状態で、リリースされることをデプロイ前に気がついた
- 標的型攻撃メールを受信したが、スパムであると気がついた
- Webへのスキャンを検知したものの、WAFをすり抜けたリクエストで問題のあるレスポンスはなかった
- 共有スペースのホワイトボードに、機密性の低い情報ではあるが消し忘れがあった
Lv2. 軽度
実害が発生しているものの、利害関係者への影響が小さい事案が該当します。
該当例
- ノートパソコンを紛失したものの、適切な対策が施されており情報流出が考えにくい場合
- SQLの直接実行によるデータ修正で、誤ったデータを更新・削除したものの復旧できた
- 取引先からメールと思い、フィッシング詐欺メールのリンクを開いてしまった
- Webへのスキャン攻撃に対して一部のURLで2xx系のレスポンスをしていることがわかった
- Twitterで評判を毀損する書き込み見つけたが、著しく不当とも言えない内容だった
Lv3. 中度
実害が発生しており、直接金銭的な不利益や法令違反のある事案や、攻撃が部分的に成立してしまった事案が該当します。
該当例
- 1年以上前に問題解決のため一時的に立てたVMを停止し忘れ、数十万円以上不要なコストが発生していた
- 20名前後のユーザーに、過大に請求または過小に報酬計算していることがわかった
- 心当たりのないログインが成功した通知を受けるも、MFAで完全なログインを防ぐことができた
- XSSを起こすデータが保存されたものの、表示時のエスケープ処理が効き実害は発生しなかった
- 法令や社会通念上、適切と説明を受け行った施策に問題があった
Lv4. 重度I
利害関係者の利益を著しく害する事案や、攻撃が完全に成立し影響が広範な事案が該当します。
該当例
- Google Workspacesの共有ディレクトリ内の機密情報が、URLを知っていれば閲覧できる状態で1年以上公開されていた
- 実装の不備により権限が無くても個人情報を閲覧できる状態となっており、実際にその形跡があった
- 端末のデータがランサムウェア被害により利用不能となったが、ファイルはクラウド同期されており復旧できた
- SQLインジェクションにより、データ破壊が発生した
- 天災により執務困難となった
Lv5. 重度II
利害関係者に深刻な被害を与え、社会的にも責任が追求されるべき事案が該当します。
該当例
- GitHubのパブリック・リポジトリで、個人情報を含むデータを公開してしまった
- データ消失とバックアップ不備が重なり、サービスが復旧不能となった
- 内部不正により当社の関わるWebサービスのユーザー情報が、名簿業者に流出していた
- バックドアによりプライベート・サブネットに侵入され、数十万件の個人情報が不正取得された
- 当社の職員が業務外で、加害者・被害者として犯罪に関わった