インシデント管理とは、ビジネスサービスを脅かしたり妨害したりするITインシデントを検出して修正するプロセスを指します。インシデント管理はITサービス管理(ITSM)の一部で、その目的は、サービスの可用性を維持し、サービスが停止した場合はビジネスへの影響を最小限に抑えながらすみやかに復旧させることです。
「インシデント」とは、ITIL (Information Technology Infrastructure Library)の定義によると、ITサービスの予定外の中断、または中断につながる事象を指します。この定義に従うと、ネットワーク品質の低下から、ディスク領域の不足、サイバー攻撃まで、幅広い問題がインシデントに該当します。その中で特に、セキュリティ関連のインシデントを検出して対応するプロセスを「セキュリティインシデント管理」と呼びます。
インシデント管理にはさまざまなアプローチがあり、そのポリシー、ツール、SLA (サービスレベル契約)は組織によって異なります。一般的には、定期的なソフトウェア更新やイベント監視などのインシデント防止策を講じるとともに、インシデントの発生時に問題をすばやく解決し、根本原因を究明して再発を防止するためのインシデント対応計画を策定します。
サービスの中断は大きなコストを生み、場合によっては1時間あたり数十万ドルもの損失につながることがあります。さらに、規制違反による罰金が科されたり、顧客離れが起きたりする可能性もあります。こうしたリスクを軽減するために、インシデント管理は非常に重要です。
以下のセクションでは、インシデント管理の各フェーズとベストプラクティスを紹介し、コストにつながるダウンタイムの回避策について説明します。
インシデント管理とは：目次
セキュリティインシデント対応とは
セキュリティインシデント対応とは、セキュリティ関連の脅威やインシデントをリアルタイムで検出し、分析、解決するプロセスを指します。システムと人手で調査と分析を行い、ビジネスへの悪影響を最小限にとどめることを目指します。このプロセスは通常、セキュリティシステムからインシデント対応チームにインシデント発生のアラートが届くことで開始されます。インシデント対応チームは、インシデントを調査、分析して、その真偽と範囲を確認し、影響を評価して、緩和策を検討します。
セキュリティインシデントは、現在発生中の脅威から、すでに起きてしまったデータ漏えいまで幅広く、その発生元は外部だけでなく組織内部の場合もあります。マルウェア攻撃以外に、従業員が職場のコンピューターからギャンブルサイトにアクセスすることや、ベンダーが閲覧不許可のデータをダウンロードすることも、セキュリティインシデントに該当します。
セキュリティインシデント対応には、トラブルシューティングだけでなく、プロアクティブな問題対応や、将来の攻撃を回避するための防御策の実装も含まれます。たとえば、大きな被害をもたらしたHeartbleed攻撃やEternalBlue攻撃が起きた後、その影響を受けた組織の管理者は、悪質な攻撃者が再びシステムにアクセスして害を及ぼすことがないよう、システムとITインフラのセキュリティ対策と監査をただちに実行しました。
セキュリティインシデント対応とインシデント管理の関係
セキュリティインシデント対応は、幅広い役割を持つインシデント管理のプロセスの一部です。ITILが定義するように、インシデント管理では、ITサービスの予定外の中断やITサービスの品質低下を引き起こすあらゆる事象が対象になります。これには、人的ミス、技術的な障害、セキュリティ違反など、さまざまな問題が含まれます。インシデント管理の目的は、インシデントの原因を究明し、影響と緊急度を評価して、適切な対策を取ることにより、サービスをすみやかに正常な状態に戻すことです。
セキュリティインシデント対応もプロセスはほぼ同じですが、対象がセキュリティインシデントに限られます。セキュリティインシデントには、侵入の試み、ポリシー違反、マルウェア感染など、コンピューターセキュリティを脅かすあらゆる事象が含まれます。セキュリティインシデントが検出されると、インシデント対応チーム(組織によってはCSIRTとも呼ばれます)が影響範囲を評価し、解決に必要な対策を検討、実行します。セキュリティインシデントによる損害や負担を防止または緩和するには、強力なセキュリティインシデント対策を構築することが不可欠です。
インシデント対応ライフサイクルのフェーズ
インシデント対応のライフサイクルについて、NIST (米国国立標準技術研究所)は以下のフェーズを定義しています。
1. 準備：最初のフェーズでは、システムやデータに関するリスクを洗い出し、問題管理戦略の骨格を固めて、セキュリティインシデント対応の仕組みを整備します。このフェーズの作業には、正式なリスク評価の実行、インシデントを分析および緩和するためのツールとプロセスの導入、脅威の優先順位付け、インシデント対応チームの編成とトレーニング、NISTのライフサイクルガイドラインに沿ったインシデント対応計画(IRP)の策定などが含まれます。
2. 検出と分析：このフェーズでは、まず、サービス運用チームが優先度の高いインシデントをプロアクティブに監視、検出、トリアージ、分析できるようにシステムを設定して、ネットワーク環境内で、ビジネスに悪影響を及ぼす可能性のある脅威や不審または異常なアクティビティを検出できる体制を整えます。検出と分析は、通常、人手による調査とセキュリティツールによる自動処理を組み合わせて行います。自動化を取り入れてプロセスを効果的に実行すれば、このフェーズでインシデントの拡散と影響を最小限に抑えることができます。
3. 封じ込め、除去、復旧：第3フェーズは、セキュリティインシデントの解決です。封じ込めの目的は、インシデントの被害が広がらないようにすることです。たとえば、侵入を受けたサーバーをネットワークから切り離したり、攻撃をブロックするファイアウォールルールを適用したりして、マルウェア攻撃の拡散を阻止します。次に、セキュリティ管理者またはサポートスタッフが迅速に、感染したサーバーからマルウェアを除去し、他のどこにも残っていないことを確認して、脅威を取り除きます。最後に、サポートスタッフが、システムをマルウェア感染前の状態に戻してから、アプリケーションを再起動し、バックアップからデータを復元して、サービスの品質を回復させます。
4. インシデント後の作業：第4フェーズでは、類似のインシデントの再発を防止するための対策を実施します。インシデント対応中やポストモーテムミーティングで集めた情報に基づいて、インシデント発生の経緯を検証し、防止策の強化または追加、監視とアラート生成プロセスの改善、ヘルプデスクとサービスリクエスト、修復、リカバリプロセスの効率化を検討します。このフェーズでは、法規制コンプライアンスに関する問題にも対処する必要があります。
4つのフェーズは全体として、包括的なナレッジベースを基盤に構築することが想定されています。第3フェーズの効果は、第1、第2フェーズの成果に大きく左右されます。最適な防御策を講じてサービスをすばやく復旧させるには、4つすべてのフェーズを連携させる必要があります。
最新のセキュリティインシデント対応計画の策定方法
セキュリティインシデントに効果的に対応するには、インシデントの発生前に適切な戦略を立てておくことが重要です。ISO/IEC標準27035では、インシデント対応管理について5つのプロセスを定義しています。
1. インシデント対応の準備をする。
2. 潜在的なセキュリティインシデントを検出、報告する。
3. インシデントを評価し、対応方法を決める。
4. インシデントを封じ込め、調査、解決する。
5. 各インシデントについて要点や教訓をまとめ、文書化する。
具体的な計画は組織によって多少異なりますが、セキュリティインシデント対応を組織のニーズに合わせて計画する際に役立つベストプラクティスがいくつかあります。
- 資産のインベントリを作成する。ビジネス活動に特に重要なシステムとデータを洗い出し、チケットの対応とセキュリティインシデント解決後の復旧の優先順位を決めます。
- セキュリティインシデント対応チームを編成する。チームメンバーに役割と責任を割り当てます。チームには、IT以外の部門(財務、運用、法務など)の代表者も必ず含めます。これにより、セキュリティインシデント発生時に関係者とコミュニケーションを取りやすくなります。
- 注意すべき事象を洗い出す。組織にどのようなセキュリティインシデントが起こり得るかを想定して、注意すべき事象を洗い出します。その後、それぞれの検出および報告方法に関するポリシーを策定します。
- セキュリティインシデントのアクションプランを作成する。脅威への対応に関するすべてのタスクをリストアップし、各タスクの実行責任者を決めます。その後、プランをテストして効果を評価し、必要に応じて改良します。
- チームの対応を評価する。サービス提供の観点で対応の成否を分析して、次回のセキュリティインシデントに向けてプランを改善します。
脅威のトリアージと対応レベルの判断
脅威のトリアージと対応方法は組織によって異なりますが、分類と優先順位付けを効果的かつ効率的に行うためのフレームワークとなるベストプラクティスがいくつかあります。
- 痕跡確認：インシデントを確認したら、そのインシデントの痕跡を集めます。たとえば、ログファイルなどのデータソースを分析して、侵入を受けたエンドポイントや感染したエンドポイントを探します。
- 調査：インシデントの痕跡をすべて集めたら、それらを基に攻撃経路を特定します。経路をたどれば、攻撃者が何を標的にしているかもわかります。
- 解決：特定した攻撃経路に基づいて、標的の中でビジネス上特に重要なシステムを判別し、対応の優先順位を決めます。優先順位付けの際に集めた情報に基づいてマルウェアを除去し、ビジネスでの重要度の高い順に、感染したシステムを復旧させます。
サイバーセキュリティツールを使用すれば、トリアージプロセスを効率化し、効果を高めることができます。また、自動化とオーケストレーション機能があればデータの収集と分析の負担が軽減されるため、セキュリティチームは重大なインシデントの調査と解決に注力できます。
DevOpsでのインシデント管理の役割
DevOpsでは、ソフトウェアアプリケーションや開発環境のセキュリティ監視をサポートするプロセスとしてインシデント管理を使用します。ITSMでのインシデント管理の役割についてはITILで言及されていますが、DevOpsチームにとってのインシデント管理に関する公式なガイドはありません。とはいえ、DevOpsにおけるインシデント管理も、組織内のサイロ化の解消、コラボレーションの強化、透明性の向上、プロセスの軽量化といったDevOpsの基本原則を中心に定義することができます。以下に、DevOpsでのインシデント管理の各ステップを簡単に説明します。
検出：DevOpsインシデント対応チームが協力して、システムの脆弱性を特定し、想定されるインシデントの対応計画を立てます。また、監視ツールを導入し、アラートシステムを構築して、インシデント検出時の対応の概要をまとめたランブックを整備します。
対応：通常、DevOpsインシデント管理チームが、監視ツールからアラートを受け取り、インシデントの重大度と影響を評価して、ランブックに従い適切なコミュニケーションチャネルを通じて適切な担当者に問題をエスカレーションします。
解決：インシデントマネージャーが、関連チームと連携して問題を修復し、システムとデータを復旧させて、アプリケーションを正常な運用状態に戻します。
分析：この「振り返り」の段階では、インシデント管理チームが協力して、「誰も責めることのない事後分析」(後述)でまとめた教訓を、システムの改善と類似インシデントの再発防止のために他のチームと共有します。
今後に向けた準備：インシデント管理チームが、将来のインシデントへの準備状況を評価し、誰も責めることのない事後分析でまとめた教訓に基づいて、監視ツールやアラートツールの設定調整、ランブックのプロセスやチームメンバーの責任の更新、新たな回避策の検討を行い、解決した問題についての根本的な修正を開発パイプライン内で実行します。
誰も責めることのない事後分析とは
誰も責めることのない事後分析は、インシデントライフサイクルの重要なプロセスです。DevOpsチームは、実行したインシデント対応プロセスをオープンに分析し、運用効率を継続的に改善していく必要があります。誰も責めることのない事後分析を行えば、インシデント対応において技術と人の両方の面で何が足りなかったかを振り返り、分析に活かすことができます。
誰も責めることのない事後分析では、インシデント対応チームのメンバーと、インシデント対応の関係者やインシデント被害者が集まり、どのようなインシデントであったかを深く理解し、再発防止策を考えます。レビューの目的は、責任を押しつけ合うことではなく、ツールとプロセスの改善点を見つけ出すことです。これにより、オンコール担当者がインシデントに躊躇なく対応できるようになるだけでなく、関係者がアプリケーションの改善策や革新的なアイデアをより積極的に提案できるようになります。
大規模インシデントの管理体制
攻撃に対する計画をしっかりと立てておくことは、大規模なインシデントが発生したときの重圧や不確実さを乗り越えるための最善の方法です。ITILの『Major Incident Management Guide』でも説明されている以下のステップは、どのようなインシデント対応にも適用できるフレームワークとして役立ちます。
- 必要なすべての情報を集める。対応に取り掛かる前に、問題の性質と範囲を見極めることが大切です。少なくとも、影響を受けているサービスとユーザー、ビジネスに与え得る影響、問題の調査担当者と報告先、コンプライアンス違反や法律違反の可能性はすみやかに確認する必要があります。
- 適切な関係者に通知する。インシデントの発生に備えて、適切な連絡先と連絡方法をリストにまとめておきます。対応チームのメンバー以外に、組織内の関係者や影響を受けるサービスのユーザー、場合によっては規制当局への通知も必要になります。
- アクションプランを策定する。集めた情報に基づいて、主要なチームの間で最適なインシデント対応手順を検討、整備します。インシデントマネージャーは、すべてのチームの作業に目を配り、対応計画が効率的かつ順調に進むように調整を行います。
- 最新情報を共有する。チームが問題に対応している間、インシデントマネージャーはタスクの期限が守られていることを定期的にチェックすると同時に、最新の進捗状況を他の関係者に早めに共有します。
- 緊急の変更承認をリクエストする。インシデントの解決方法を特定したら、テストを行って、その方法で問題が解決することを確認します。必要に応じて、インシデントマネージャーは緊急の変更管理プロセスを立ち上げて、対応チームがただちに修正を行えるようにします。
- 修正が完了したことを知らせる。修正のデプロイとチェックが完了したら、小規模なユーザー代表グループにサービスが正しく機能することを確認してもらいます。問題がなければ、インシデント対応チームはインシデントが解決したことを関係者全員に知らせます。
- 簡単なレビューを行う。インシデント対応の記憶が新しいうちに、簡単なミーティングを開いて、実行した対応を振り返り、そこから学んだ教訓をまとめます。その後、より詳細な評価を実行するために、誰も責めることのない事後分析をスケジュールします。
システム障害のコスト
ITIC社による2020年のダウンタイム1時間あたりのコスト調査によると、調査対象企業の40%が、ダウンタイム1時間あたりのコスト(裁判費用、罰金、コンプライアンス違反金を除く)は100万ドル～5,000万ドル強に上ると回答しています。
このデータから、業務の中断はダウンタイムを含めどのような形であっても大きな損失をもたらすことがわかります。カリフォルニア大学アーバイン校の調査によると、従業員が業務を中断されてから再度集中できるようになるまでに約23分かかることもわかっています。障害の実際のコストは組織によってさまざまですが、1つのシステムの障害によって数百万ドルのコストが発生する可能性があることは確かです。しかもそこに、ビジネス機会の損失、生産性の低下、評判の低下といった副次的なコストが加わります。
どの組織でもシステム障害は避けられないことですが、インシデント管理のアプローチをリアクティブなものからプロアクティブなものに転換すれば、発生頻度や影響範囲を抑えることができます。
MTTD/MTTRとは
MTTDは「平均検出時間(Mean Time To Detect)」または「平均発見時間(Mean Time To Discover)」の略で、MTTRは「平均対応時間(Mean Time To Respond)」の略です。いずれも、チームのインシデント管理プロセスの効果を定量化するために使われる指標です。
MTTDは、インシデント管理の重要なパフォーマンス指標の1つであり、問題が発生してから組織または妥当な第三者がそれに気づくまでの時間を指します。MTTDが短いほど、組織が障害やその他の混乱にさらされる時間が短くなります。また、MTTDが短くなれば、ダウンタイムによって生じるコストがその分減ることにもなります。通常、システムの問題は、エンドユーザーがサービスデスクに障害を報告するか、監視ツールや管理ツールからアラートが送られることで発覚します。
MTTRは、問題が修正され、影響を受けたコンポーネントやシステムが正常な状態に戻るまでの平均時間を指します。システムのメンテナンスレベルとチームのITインシデント解決の効率を示す指標として使われます。MTTRの計測は、障害が検出された時点から開始され、診断、修正、テストなどの対応を経て、サービスが正常な状態に戻った時点で終了します。MTTRとMTTDを合わせた時間が、サイバーインシデント全体の継続時間となります。
MTTRは、ITインシデントのコストを見積もるうえで非常に重要な役割を果たします。MTTRが長いほど、ITインシデントの発生時にダウンタイムが長引くリスクが高まり、ビジネスの中断、顧客満足度の低下、収益の損失につながりやすくなります。
防御を強化するためのインシデント管理ツールの選び方
インシデント管理プラットフォームは、インシデント対応の第一線を担います。インシデントの検出、ログの収集、問題の診断、調査、エスカレーション、解決などの機能を提供し、インシデント管理プロセスの各フェーズで重要な役割を果たします。さまざまなインシデント管理プラットフォームが提供されていますが、製品を選ぶときは特に、組織の規模と範囲、コンプライアンス要件、予算に合っているかどうかを重視しましょう。
効果的なインシデント管理計画の作成と実践方法
効果的なインシデント管理計画を作成するには、まず、組織内外の適切な人員で構成されるインシデント対応チームを立ち上げます。次に、組織にとって何がインシデントであるかを定義し、インシデント脅威分析を行って、潜在的な脅威、リスク、インフラ障害を評価します。その後、さまざまなシナリオに沿った対応計画を策定し、スタッフをトレーニングしてから、インシデントのシミュレーションを通じてインシデント対応を実践し、継続的に改善します。
IT環境が複雑化し、脅威の件数と巧妙さが増す中、組織はかつてないレベルのリスクに直面しています。適切なインシデント管理を実践すれば、インシデントをよりすばやく検出、解決して、そのリスクを緩和できます。どの組織でも障害やその他のインシデントは避けられませんが、その中でインシデント管理は、問題に迅速に対応して、コストのかかるダウンタイムを削減し、組織の評判低下や収益損失を防ぐために非常に有効な手段です。
