インシデント管理とは？ 

システム障害のコスト

ITIC社による2020年のダウンタイム1時間あたりのコスト調査によると、調査対象企業の40%が、ダウンタイム1時間あたりのコスト(裁判費用、罰金、コンプライアンス違反金を除く)は100万ドル～5,000万ドル強に上ると回答しています。

このデータから、業務の中断はダウンタイムを含めどのような形であっても大きな損失をもたらすことがわかります。カリフォルニア大学アーバイン校の調査によると、従業員が業務を中断されてから再度集中できるようになるまでに約23分かかることもわかっています。障害の実際のコストは組織によってさまざまですが、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以外の部門(財務、運用、法務など)の代表者も必ず含めます。これにより、セキュリティインシデント発生時に関係者とコミュニケーションを取りやすくなります。 
• 注意すべき事象を洗い出す。組織にどのようなセキュリティインシデントが起こり得るかを想定して、注意すべき事象を洗い出します。その後、それぞれの検出および報告方法に関するポリシーを策定します。 
• セキュリティインシデントのアクションプランを作成する。脅威への対応に関するすべてのタスクをリストアップし、各タスクの実行責任者を決めます。その後、プランをテストして効果を評価し、必要に応じて改良します。 
• チームの対応を評価する。サービス提供の観点で対応の成否を分析して、次回のセキュリティインシデントに向けてプランを改善します。

大規模インシデントの管理体制

攻撃に対する計画をしっかりと立てておくことは、大規模なインシデントが発生したときの重圧や不確実さを乗り越えるための最善の方法です。ITILの『Major Incident Management Guide』でも説明されている以下のステップは、どのようなインシデント対応にも適用できるフレームワークとして役立ちます。

• 必要なすべての情報を集める。対応に取り掛かる前に、問題の性質と範囲を見極めることが大切です。少なくとも、影響を受けているサービスとユーザー、ビジネスに与え得る影響、問題の調査担当者と報告先、コンプライアンス違反や法律違反の可能性はすみやかに確認する必要があります。
• 適切な関係者に通知する。インシデントの発生に備えて、適切な連絡先と連絡方法をリストにまとめておきます。対応チームのメンバー以外に、組織内の関係者や影響を受けるサービスのユーザー、場合によっては規制当局への通知も必要になります。
• アクションプランを策定する。集めた情報に基づいて、主要なチームの間で最適なインシデント対応手順を検討、整備します。インシデントマネージャーは、すべてのチームの作業に目を配り、対応計画が効率的かつ順調に進むように調整を行います。
• 最新情報を共有する。チームが問題に対応している間、インシデントマネージャーはタスクの期限が守られていることを定期的にチェックすると同時に、最新の進捗状況を他の関係者に早めに共有します。
• 緊急の変更承認をリクエストする。インシデントの解決方法を特定したら、テストを行って、その方法で問題が解決することを確認します。必要に応じて、インシデントマネージャーは緊急の変更管理プロセスを立ち上げて、対応チームがただちに修正を行えるようにします。
• 修正が完了したことを知らせる。修正のデプロイとチェックが完了したら、小規模なユーザー代表グループにサービスが正しく機能することを確認してもらいます。問題がなければ、インシデント対応チームはインシデントが解決したことを関係者全員に知らせます。
• 簡単なレビューを行う。インシデント対応の記憶が新しいうちに、簡単なミーティングを開いて、実行した対応を振り返り、そこから学んだ教訓をまとめます。その後、より詳細な評価を実行するために、誰も責めることのない事後分析をスケジュールします。

誰も責めることのない事後分析とは

誰も責めることのない事後分析は、インシデントライフサイクルの重要なプロセスです。DevOpsチームは、実行したインシデント対応プロセスをオープンに分析し、運用効率を継続的に改善していく必要があります。誰も責めることのない事後分析を行えば、インシデント対応において技術と人の両方の面で何が足りなかったかを振り返り、分析に活かすことができます。

誰も責めることのない事後分析では、インシデント対応チームのメンバーと、インシデント対応の関係者やインシデント被害者が集まり、どのようなインシデントであったかを深く理解し、再発防止策を考えます。レビューの目的は、責任を押しつけ合うことではなく、ツールとプロセスの改善点を見つけ出すことです。これにより、オンコール担当者がインシデントに躊躇なく対応できるようになるだけでなく、関係者がアプリケーションの改善策や革新的なアイデアをより積極的に提案できるようになります。

IT環境が複雑化し、脅威の件数と巧妙さが増す中、組織はかつてないレベルのリスクに直面しています。適切なインシデント管理を実践すれば、インシデントをよりすばやく検出、解決して、そのリスクを緩和できます。どの組織でも障害やその他のインシデントは避けられませんが、その中でインシデント管理は、問題に迅速に対応して、コストのかかるダウンタイムを削減し、組織の評判低下や収益損失を防ぐために非常に有効な手段です。