インシデント管理とは、ビジネスサービスを脅かしたり妨害したりする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. 各インシデントについて要点や教訓をまとめ、文書化する。
具体的な計画は組織によって多少異なりますが、セキュリティインシデント対応を組織のニーズに合わせて計画する際に役立つベストプラクティスがいくつかあります。
脅威のトリアージと対応方法は組織によって異なりますが、分類と優先順位付けを効果的かつ効率的に行うためのフレームワークとなるベストプラクティスがいくつかあります。
サイバーセキュリティツールを使用すれば、トリアージプロセスを効率化し、効果を高めることができます。また、自動化とオーケストレーション機能があればデータの収集と分析の負担が軽減されるため、セキュリティチームは重大なインシデントの調査と解決に注力できます。
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は「平均検出時間(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環境が複雑化し、脅威の件数と巧妙さが増す中、組織はかつてないレベルのリスクに直面しています。適切なインシデント管理を実践すれば、インシデントをよりすばやく検出、解決して、そのリスクを緩和できます。どの組織でも障害やその他のインシデントは避けられませんが、その中でインシデント管理は、問題に迅速に対応して、コストのかかるダウンタイムを削減し、組織の評判低下や収益損失を防ぐために非常に有効な手段です。