マイクロソフトの Securing Windows 2000 Server ソリューション: 第 10 章 ‐ インシデントへの対応
第 10 章 ‐ インシデントへの対応
トピック
組織の情報技術 (IT) 部門ではセキュリティの問題に対処するためにどのような準備をしているでしょうか。多くの組織では、攻撃を受けた後で初めてセキュリティの問題への対応方法を学んでいます。このときには、問題に対応するためのコストは必要以上に高くなる可能性があります。この問題への適切な対応を、全体的なセキュリティ ポリシーおよびリスク緩和策の中心として考える必要があります。
セキュリティ問題に対応することに直接的な利益があることは明らかです。一方で、間接的な財務面での利益もあります。たとえば、常に組織がすばやく、費用効果の高い方法で攻撃を対処することができることを証明できれば、保険会社から保険料の割引を受けられる場合があります。また、サービス プロバイダが公式の問題対応プランを用意しておくことは、適切な情報セキュリティの処理を真剣に考えていることを示すことになり、ビジネス面でプラスになる可能性があります。
この章では、Microsoft Windows 2000 Server ベースの環境で侵入が検出された場合の対応のプロセスと手順について説明します。セキュリティ問題対応チームを作り、チームのメンバの役割を明確化することの意味、およびセキュリティ問題対応プランを定義する方法についても説明します。また、ケース スタディでは、このプロセスおよび関連する手順を、それぞれの組織に適用するための最適な方法を示すケースを紹介します。
セキュリティ問題の件数の削減と重大性の緩和
人生の多くの場面で、予防は治療に優りますが、セキュリティも例外ではありません。まず、できる限り、セキュリティ問題の発生を防止します。これについては、第 5 章から第 8 章で既に説明しました。ただし、すべてのセキュリティの問題を防止することは不可能なので、セキュリティ問題が発生した場合に、その影響を最小限に抑える必要があります。セキュリティ問題の件数および影響を最小限にするための賢明な対策があります。これには、予防的な対策と問題発生後の対策の両方が含まれます。
すべてのポリシーおよび手順を明確に確立して実施します。セキュリティ問題は、IT 担当者が変更管理手順に従っていないかまたは理解していないことや、ファイアウォールや認証システムなどのセキュリティ デバイスを正しく構成していないことが原因で発生する場合がほとんどです。ポリシーや手順は十分にテストして、実用的かつ明確であり、適切なレベルのセキュリティを提供することを確認する必要があります。
セキュリティ ポリシーおよび問題の処理に対して経営陣の支援を得ることです。
環境の脆弱性を定期的に調査します。この調査は、このアクションを実行する特別な許可を持ったセキュリティの専門家が実行する必要があります。
サーバーを定期的にチェックして、最新の修正プログラムがすべてインストールされていることを確認します。
IT 担当者とエンド ユーザーの両方に対するセキュリティ トレーニング プログラムを確立します。あらゆるシステムの最大の脆弱性は無知なユーザーです。ILOVEYOU ワームは、IT 担当者やエンド ユーザーの脆弱性を悪用していました。
ユーザーに責任と制限事項、および違反した場合の告訴の可能性を通知するセキュリティ バナーを表示します。このようなバナーがない場合、攻撃者を告訴することは困難または不可能になります。セキュリティ バナーの内容が適切であるかどうかについて、法律の専門家のアドバイスを受けてください。
複雑なパスワードを必要とするポリシーを開発、実装、および強制します。複雑なパスワードによるセキュリティ オプションやそのヒント集については、第 5 章「ドメイン インフラストラクチャをセキュリティで保護する」を参照してください。
ネットワーク トラフィックおよびシステム パフォーマンスを定期的に監視および分析します。
すべてのログおよびログ記録メカニズムを定期的にチェックします。これには、オペレーティング システムのイベント ログ、アプリケーション固有のログ、および侵入検出システムのログなどが含まれます。
バックアップおよび復元の手順を確認します。バックアップが保持されている場所、バックアップにアクセスできる人物、およびデータ復元とシステム回復の手順を知っている必要があります。データを選択的に復元して、定期的にバックアップとメディアを確認します。
コンピュータ セキュリティ問題対応チーム (CSIRT: Computer Security Incident Response Team) を編成します。これは、あらゆるセキュリティ問題を処理する責任者のグループです。CSIRT は、対応されない領域がないように職務が明確に定義されたメンバで構成されている必要があります。CSIRT の結成の詳細については、この章で説明します。
重要なセキュリティ ツールの適切な使用方法および保存場所について、CSIRT のメンバにトレーニングを実施します。これらのツールがあらかじめ構成されたポータブル コンピュータを配布して、問題に対応するためのツールのインストールや構成に時間を浪費しないようにすることも検討してください。このようなシステムや関連ツールは、使用しないときには適切に保護されている必要があります。
関連するすべての連絡先の情報をまとめます。組織内で通知する必要がある連絡先の担当者 (CSIRT メンバ、システムのサポート担当者、メディア関連の責任者) の名前と電話番号を入手しておく必要があります。また、インターネット サービス プロバイダ (ISP) および国や地方の司法当局についての詳細情報も必要です。問題が発生する前に、地方の司法当局と連絡をとっておいてください。これは、問題を連絡し、証拠を収集するときの適切な手順を理解するのに役立ちます。
緊急時のすべてのシステム情報を、ノートやオフラインのコンピュータなど、オフラインの保管場所に集中的に保存します。この緊急時の情報には、システムのパスワード、インターネット プロトコル (IP) アドレス、ルーターの構成情報、ファイアウォールの規則セットのリスト、証明機関のキーのコピー、担当者の名前と電話番号、エスカレーションの手順などがあります。この情報は、物理的に非常に安全に保管され、なおかつすぐに利用できる必要があります。この情報をセキュリティで保護し、すぐに利用できるようにするための方法の 1 つとして、安全な保管室に配置されたセキュリティ専用のポータブル コンピュータ上でこの情報を暗号化し、CSIRT のリーダーおよび CIO や CTO など、権限のある人物だけがこの保管室に出入りできるようにする方法があります。
コンピュータ セキュリティ問題対応チームの中核の編成
CSIRT は、使用環境のコンピュータ セキュリティ問題に中心となって対処します。CSIRT は次のような作業に責任を持っています。
システムのセキュリティ違反を監視します。
セキュリティ問題の報告を受けるとともに、問題に関する重要な情報を適切な当事者に伝える連絡の中心としての役割を果たします。
セキュリティ問題を文書化およびカタログ化します。
社内でセキュリティに対する関心を高めて、組織内での問題の発生を防止します。
脆弱性の調査や侵入のテストなどのプロセスによって、システムとネットワークの監査をサポートします。
最新の脆弱性や攻撃者の攻撃方法に対応します。
最新のソフトウェア修正プログラムを導入します。
セキュリティの脆弱性およびリスクを最小限にするための新しい技術を分析および開発します。
セキュリティ コンサルティング サービスを提供します。
現在のシステムおよび手順を継続的に増強および更新します。
理想的な CSIRT のメンバシップおよび構成は、組織の種類およびリスク管理戦略によって異なります。ただし、CSIRT は一般的に、組織のセキュリティ チームの一部分または全体を構成します。チームの中核には、すべての問題への対応を調整するセキュリティの専門家がいます。CSIRT のメンバの人数は、通常、組織の規模と複雑さによって異なります。ただし、常にチームのすべての任務を遂行するのに十分な数のメンバが必要です。
CSIRT チーム リーダー
CSIRT では、その活動に責任を持つ担当者が必要です。一般的に、CSIRT チーム リーダーが CSIRT の活動に責任を持ち、その活動の検討を行います。これは、将来の問題に対応するためのポリシーや手順の変更につながる場合もあります。
CSIRT インシデント担当リーダー
問題が発生したときに、その対応の調整を担当する担当者が必要です。CSIRT インシデント担当リーダーは、特定の問題または関連する複数のセキュリティ問題を担当します。この問題に関するすべての連絡は、インシデント担当リーダーを介して調整され、CSIRT の部外者に対しては、インシデント担当リーダーが CSIRT 全体の代表となります。インシデント担当リーダーは、問題の性質によって異なる場合があり、通常、CSIRT チーム リーダーとは別です。
CSIRT 準メンバ
CSIRT チームの中核以外に、特定の問題の処理や対応を行う担当者が数多く必要です。準メンバは組織内のさまざまな部門に所属し、CSIRT の中核が直接処理しない、セキュリティ問題の影響を受ける各分野の専門家である必要があります。準メンバは、直接問題に関与する場合と、部門内のより適切な担当者に責任を委譲するための窓口となる場合があります。次の表は、推奨される準メンバとその役割を示したものです。
表 10.1 CSIRT 準メンバ
| 準メンバ | 役割の説明 |
|---|---|
| IT 責任者 | 主に、CSIRT 問題担当リーダーと IT グループの他のメンバとのコミュニケーションの調整を担当します。IT 責任者は、問題に対応するための特定の技術的な知識を持っていない場合もありますが、IT グループ内で特定のセキュリティ問題を処理できる人物を見つけることに責任を持ちます。 |
| 法務担当者 | 通常、社内の法務部門のメンバで、確立された問題の対応ポリシーに詳しい人です。法務担当者は、問題の発生時に、法的責任を最小限にし、違反者を最大限に追及できるようにする処理方法を決定します。 問題が発生する前に法務担当者は監視および対応のポリシーに関する情報を入手し、クリーンアップやコンテインメントの操作によって、組織が法的責任を問われることがないようにしておく必要があります。システムをシャットダウンすることによって潜在的に顧客とのサービス レベル保証やメンバシップの契約に違反する場合や、攻撃されたシステムをシャットダウンしないことによってそのシステムから行われた攻撃による損害の責任を負う場合の法的な意味を検討しておくことは不可欠です。 外部の司法当局や社外の調査機関への連絡も、法務担当者が調整する必要があります。 |
| 広報責任者 | 一般的には、広報部門のメンバである広報責任者は、組織のイメージの保護と向上を担当します。 この担当者はメディアや顧客に直接対応するわけではありませんが、メッセージの作成を担当します。メッセージの内容と目的は、一般的に経営陣が決定します。メディアからのすべての問い合わせは、広報責任者が管理する必要があります。 |
| 経営陣 | 経営陣の関与は、特定の部門を対象とするものから組織全体に及ぶものまであります。適切な経営陣の責任者は、問題の影響、場所、重大性、および種類によって異なります。 経営陣の連絡先がある場合は、特定の状況に最適な責任者をすばやく見つけることができます。経営陣は、セキュリティ ポリシーの承認と指示を行います。 経営陣は、問題の組織に対する総合的な影響 (財務的およびその他の両方) の決定も行います。経営陣は、メディアに公開する情報を広報責任者に指示し、法務担当者と司法当局とのやり取りのレベルを決定します。 |
CSIRT によるインシデントの対応方法
問題が発生したときに、CSIRT は CSIRT の中核の対応を調整し、CSIRT の準メンバとの連絡を取ります。次の表は、問題対応プロセス時の各担当者の責任を示しています。
表 10.2 インシデント対応時の CSIRT の担当
| 活動 | 役割 | ||||
|---|---|---|---|---|---|
| CSIRT 問題担当リーダー | IT 責任者 | 法務担当者 | 広報責任者 | 経営陣 | |
| 初期調査 | 責任者 | アドバイス | なし | なし | なし |
| 初期の対応 | 責任者 | 実施 | 更新 | 更新 | 更新 |
| 法的証拠の収集 | 実施 | アドバイス | 責任者 | なし | なし |
| 一時的な解決策の実施 | 責任者 | 実施 | 更新 | 更新 | アドバイス |
| 連絡 | アドバイス | アドバイス | アドバイス | 実施 | 責任者 |
| 地方の司法当局との確認 | 更新 | 更新 | 実施 | 更新 | 責任者 |
| 永続的な解決策の実施 | 責任者 | 実施 | 更新 | 更新 | 更新 |
| ビジネスに対する財務的な影響の決定 | 更新 | 更新 | アドバイス | 更新 | 責任者 |
インシデントを連絡します。
被害の拡大を防止し、リスクを最小化します。
被害の種類および重大性を特定します。
証拠を保全します。
社外機関に通知します。
システムを回復します。
問題に関するドキュメントを収集して整理します。
問題の損害およびコストを調査します。
対応を再検討して、ポリシーを更新します。
注 ジョブエイド 4: 問題発生時に『Incident Response Quick Reference Card』をチェックリストとして使用することによって、すべてのフェーズを正しく実行することができます。
これらの手順は単純な一連の作業ではありません。問題が発生している間、継続される作業です。たとえば、ドキュメント化の作業は、問題の発生当初から始まり、問題が解決するまで続けられます。連絡作業も問題が解決されるまで行われます。
このプロセスのその他の面は、互いに関連して機能します。たとえば、初期調査の中では、攻撃の一般的な性質に関する情報を入手します。この情報を使用して、できるだけ早く、被害の拡大を防止し、リスクを最小限に抑えることが重要です。迅速に対処すれば、時間と費用を節約し、組織の信用を保つことができます。
ただし、被害の種類と重大性を詳細に理解するまで、被害の拡大を防止し、リスクを最小限に抑えるための効果的な対応をすることができません。過度の対応は、最初の攻撃よりも被害を大きくする可能性があります。上の手順を相互に関連させながら行うことによって、迅速で効果的な対応をすることができます。
注 問題が発生する前に、問題対応プロセスをすべてテストしておくことは非常に重要です。完全なテストを行っていない場合、実際の対処方法が問題に対応する際に効果的であるかどうかが確実ではありません。
初期調査の実施
さまざまな活動が組織に対する攻撃の可能性を示す場合があります。たとえば、システム管理者が正当なシステム保守作業を行ったときに、誰かが何らかの攻撃をしかけたように見える場合があります。また、正しく構成されていないシステムでは、侵入検出システムで誤検知が何度も検出され、本当の問題を見分けることを難しくしている場合があります。
初期調査では、次の作業を行います。
実際の問題と誤検知のどちらを処理しているかを判断するための初期作業を実行します。
攻撃の種類と重大性に関する一般的な情報を入手します。この情報は、少なくとも、さらに調査をするための連絡をするか、および被害の拡大を防止してリスクを最小限に抑える作業を開始するかを判断するために十分な情報でなければなりません。
作業の内容をすべて記録します。これらの記録は、後で問題 (実際の問題と誤検知を含む) をドキュメント化するときに使用します。
注 誤検知はできる限り排除したいものですが、実際の問題に対応し損なうよりは、誤検知にも対応することをお勧めします。したがって、初期調査はできる限り簡潔で、しかも明らかな誤検知を除去したものである必要があります。
問題の連絡
セキュリティ問題の発生が疑われる場合、CSIRT の中核以外のメンバに侵害についてすみやかに連絡します。問題担当リーダーは、チームの他のメンバとともに、中核となる CSIRT 以外で連絡する必要がある人物を迅速に確定しなければなりません。これによって、被害の範囲を最小限に留めながら、問題の適切な管理と調整を行うことができます。
損害にはさまざまな形態があり、セキュリティが侵害されたことを報じる新聞の見出しはシステムへの侵入よりも破壊力が大きいことに注意してください。このような理由と、攻撃者に情報が漏れるのを防ぐために、問題が適切に管理されるまでは、問題への対応に従事する者だけに連絡するようにします。状況によっては、後になった問題を通知する必要がある連絡先が判明する場合があります。これには、特定の個人から会社全体および外部の顧客までが含まれる場合があります。
被害の拡大防止とリスクの最小化
迅速に対応して攻撃の実際の結果や潜在的な影響を小さくすることによって、マイナな問題とメジャーな問題を区別できます。RFC 2196 では、環境内で被害の拡大を防止するための一連の優先順位を定義しています。実際の対応は、組織および発生した攻撃の性質によって異なります。ただし、まず、次のような優先順位が推奨されています。
人命および人々の安全を保護します これは、常に最も優先順位が高い項目です。
極秘データおよび機密データを保護します 問題の対応を計画する中で、極秘データや機密データを明確に定義する必要があります。これによって、データを保護する際の対応の優先順位を決定できます。
独自のデータ、科学的データ、および経営データなどのその他のデータを保護します 環境内のその他のデータにも大きな価値がある可能性があります。最も価値のあるデータをまず保護してから、他の価値の低いデータを保護します。
ハードウェアとソフトウェアを攻撃から保護します これには、システム ファイルの削除や変更、およびハードウェアへの物理的な損害などが含まれます。システムに対する損害は、停止時間につながりコストが増大する可能性があります。
コンピューティング リソース (プロセスを含む) の使用の中断を最小限に抑えます 多くの環境で稼動時間は非常に重要ですが、攻撃が行われているときにシステムの稼動を続けると、後でもっと大きい問題の原因となる場合があります。このような理由から、一般的に、コンピューティング リソースの使用の中断を最小限にすることの優先順位は、比較的に低くなります。
環境に対する被害の拡大を防止し、リスクを最小限に抑えるには、さまざまな方法があります。少なくとも、次のような作業をする必要があります。
こちらが攻撃者の活動に気付いていることを攻撃者に悟られないようにします。重要な対応の一部は攻撃者への警告になるため、これは困難な場合があります。たとえば、CSIRT の緊急会議が開かれた場合や、すべてのパスワードを直ちに変更することを要請した場合、社内の攻撃者は問題が発覚したことに気付く可能性があります。
被害にあったシステムや関連システムをオフラインにすることのコストを、稼動を継続する場合のリスクと比較します。ほとんどの場合、直ちにシステムをネットワークから切り離すことをお勧めします。ただし、サービス保証によって、被害がさらに拡大する可能性があっても、システムを利用できることが要求される場合があります。このような状況では、接続を制限してシステムをオンラインの状態に保ち、継続する攻撃においてさらに証拠を収集することもできます。
状況によっては、問題の被害と範囲が広範囲にわたるため、サービス レベル保証の違反条項に該当する処置をしなければならない場合もあります。いずれの場合も、問題の発生時の対応をあらかじめ協議し、対応プランに概要を示して、攻撃されたときにすみやかに対応できるようにしておく必要があります。
攻撃者が使用するアクセス ポイントを特定し、以降のアクセスを禁止する対策を実施します。対策としては、モデムの無効化、ルーターやファイアウォールへのアクセス制御エントリの追加、物理的なセキュリティ対策の増強などがあります。
新しいハードディスクを使って真新しいシステムを再構築することを検討します。既存のハードディスクは、攻撃者を告訴する場合に証拠として使用できる場合があるので、取り外して保管しておきます。すべてのローカル パスワードを変更したことを確認します。また、環境内の他の場所で使用されている管理者およびサービス アカウントのパスワードも変更する必要があります。
被害の重大性の特定
攻撃から効果的に回復できるようにするには、システムの被害の重大性を特定する必要があります。これによって、リスクの拡大の防止や最小化の方法、回復の方法、問題の迅速な連絡方法や連絡先、および法的な救済を要求するかどうかが決まります。
次のような作業を行う必要があります。
攻撃の性質を特定します。これは初期調査の結果とは異なる場合があります。
攻撃元を特定します。
攻撃の意図を特定します。特定の情報を入手するために自分の組織に対して仕掛けられた攻撃であるか、または無作為な攻撃であるかということです。
被害を受けたシステムを識別します。
アクセスされたファイルを識別し、それらのファイルの機密性を調べます。
このような作業を行うことによって、環境に合った適切な対応を決定できます。適切な問題対応プランでは、攻撃の詳細が明らかになるにつれて、従うべき特定の手順が示されます。一般的に、攻撃の兆候の性質は、プランで定義された手順に従う順序を決定します。時間が重要なので、通常、時間のかかる手順よりも先に時間のかからない手順を実行する必要があります。被害の重大性を特定するには、次の作業を行う必要があります。
対応チームの他のメンバに連絡し、発見した内容を知らせて、結果を確認してもらい、他のメンバが関連するまたはその他の潜在的な攻撃に気付いていたかどうかを調べて、その問題が誤検知であるかどうかを判断します。状況によっては、初期調査で実際の問題であると考えられていたことが誤検知であるとわかることもあります。
承認されていないハードウェアがネットワークに接続されているかどうかや、物理的なセキュリティ管理の欠陥から承認されていないアクセスの兆候があるかどうかを調べます。
主なグループ (Domain Administrators、Administrators など) に承認されていないエントリがないかどうかを調べます。
セキュリティ調査または悪用ソフトウェアを検索します。被害を受けたシステムでは、通常、証拠の収集中にクラッキング ユーティリティが見つかります。
承認されていないプロセスやアプリケーションが現在実行されていないか、またはスタートアップ フォルダやレジストリのエントリを使用して実行されるように設定されていないか調べます。
システム ログの途切れ、つまり欠落がないか調べます。
侵入検出システムのログで、侵入の兆候、影響を受けるシステム、攻撃の方法、攻撃の時刻と期間、および潜在的な被害の全体的な範囲を調べます。
他のログ ファイルで、異常な接続、セキュリティ監査の失敗、異常なセキュリティ監査の成功、失敗したログオンの試行、既定のアカウントへのログオンの試行、勤務時間外の活動、ファイル、ディレクトリ、および共有のアクセス許可の変更、およびユーザーのアクセス許可の昇格や変更が記録されていないか調べます。
システムを、以前に実行されたファイル/システムの整合性チェックと比較します。これによって、ファイル システムやレジストリに対する追加、削除、変更、およびアクセス許可や制御の変更を識別できます。正確に被害の対象と、回復の必要がある対象を識別すると、問題に対応するときの時間を大幅に短縮できます。
クレジット カード番号および従業員や顧客のデータなどの機密データが、後で検索または変更するために移動または隠匿されていないか調べます。システムにビジネス以外のデータ、ソフトウェアの違法コピー、および調査に役立つ電子メールその他のレコードがないか調べることも必要です。調査目的でシステムを検索した結果、プライバシーやその他の法律に違反している可能性がある場合は、作業を続行する前に法務部門に連絡を取ります。
疑わしいシステムのパフォーマンスを、そのシステムのベースライン パフォーマンス レベルと照合します。これは、当然、ベースラインが作成され、適切に更新されていることが前提となります。パフォーマンスのベースラインの作成の詳細については、『Windows 2000 Professional Resource Kit』(Microsoftｮ Pressｮ、ISBN: 1-57231-808-2) の第 27 章「Overview of Performance Monitoring」を参照してください。
被害を受けたシステムおよびどのような被害を受けたかを特定する場合、一般的には、被害を受ける前に記録された同じシステムのベースラインと比較します。最新のシステムのスナップショットが比較に使用できると想定することは、以前のスナップショットが既に攻撃されたシステムのスナップショットである場合、状況を困難にする場合があります。
注 EventCombMT、DumpEL、および Microsoft Operations Manager (MOM) などのツールを使用すると、システムがどの程度攻撃されたかを調べることができます。サード パーティの侵入検出システムは攻撃を事前に警告します。また、システムのファイルの変更を示すツールもあります。これらのツールの詳細については、第 9 章「監査と侵入検出」を参照してください。
証拠の保護
多くの場合、環境が意図的に攻撃された場合、加害者に対して法的措置も検討します。この場合、訴訟で使用できる証拠を収集する必要があります。元のメディアのデータの整合性に影響する処置を行う前に、できるだけ早く被害を受けたシステムをバックアップすることは非常に重要です。
コンピュータ法科学の専門家に、新しい未使用のメディアを使用して、システム全体のビット対ビットの完全なバックアップを少なくとも 2 つ作成させる必要があります。少なくとも 1 つのバックアップは、CD-R や DVD-R などの追記型メディアに保存する必要があります。このバックアップは、攻撃者を告訴する場合にのみ使用し、必要になるまで物理的に安全な場所に保管します。
もう 1 つのバックアップは、データの回復に使用することもできます。これらのバックアップは法的な目的以外でアクセスするべきではないので、物理的に安全な場所に保管する必要があります。また、システムをバックアップした人物、バックアップの日時、保管方法、アクセスできる人物など、バックアップに関する情報をドキュメント化する必要もあります。
バックアップを実行したら、元のハードディスクを取り外して、物理的に安全な場所に保管します。これらは、訴訟での法的な証拠として使用できます。システムを復元するには、新しいハードディスクを使用する必要があります。
状況によっては、データを保持することの利益が、対応やシステム回復の遅れによるコストに見合わない場合もあります。データを保持することのコストと利益を、各問題を迅速に解決することのコストや利益と比較しなければなりません。
非常に大規模なシステムでは、被害を受けたすべてのシステムの広範なバックアップを作成することが不可能な場合があります。このような場合は、代わりにすべてのログと、システムの侵害された部分を選択してバックアップします。
可能であれば、システムの状態データもバックアップします。訴訟が開始されるまでに数か月または数年かかる場合もあるので、将来使用するために問題をできるだけ詳細にアーカイブしておくことが重要です。
コンピュータ犯罪を告訴する場合に最も難しい法的な側面は、特定の管轄区域の証拠提出に関する法律によって許容された方法で証拠を収集することです。したがって、法科学的なプロセスで最も重要な構成要素は、信頼性の高い証拠を提示するために、いつ、誰によって、どのようにシステムが処理されたかを詳細かつ完全にドキュメント化しておくことです。ドキュメントの各ページに署名して日付を記しておきます。
機能する検証済みのバックアップを作成したら、感染したシステムを一掃し、再構築できます。これによって、迅速に稼動状態に戻すことができます。訴訟に必要な重要で欠陥のない証拠を提供するのはこのバックアップです。法科学的なバックアップとは別のバックアップを使用して、データを復元する必要があります。
外部機関への通知
問題の拡大を防止し、将来の訴訟に備えてデータを保管した後、適切な外部機関に通知する必要があります。この外部機関には、国および地方の司法当局、社外のセキュリティ会社、およびウイルスの専門家などが含まれます。外部機関は、迅速な解決方法を提供したり、同様の問題から得られた情報を提供するなどの技術的な支援を行い、問題から完全に回復したり、将来の問題の発生を防止する手助けをします。
特定の業界や侵害の種類によっては、顧客および一般大衆に具体的に通知することが必要になる場合があります。特に、顧客が問題の直接的な影響を受ける可能性があるような場合です。
発生した問題が財務面で膨大な影響を与える場合、問題を司法当局に報告することが必要になる場合があります。
有名な企業や問題の場合は、メディアが関与する可能性があります。セキュリティ問題に対するメディアの注目は好ましくありませんが、通常避けられないものであり、組織は問題の連絡に関して積極的なスタンスを取ることができます。最低でも、問題対応手順には、メディアの代表に対して発表を行う、承認された人物が明確に定義されている必要があります。
通常、これは組織内の広報グループの担当者です。メディアに対して問題が発生したことを否定しないでください。否定することは、積極的に問題について連絡し、目に見える対応をすることよりも、信用を大きく傷つけます。このことは、性質や重大性に関係なく、すべての問題をメディアに通知するという意味ではありません。状況に応じて、適切なメディアへの対応を調査する必要があります。
システムの回復
システムを回復する方法は、一般的にセキュリティの侵害の度合によって異なります。既存のシステムをできる限り原型を留めながら復元できるかどうか、システムを完全に再構築する必要があるかどうかを判断しなければなりません。
データの復元では、当然、クリーン バックアップが存在することが前提となります。クリーン バックアップとは、問題が発生する前に作成されたバックアップです。ファイルの整合性検査ソフトウェアを使用すると、被害の最初の発生を特定できます。このソフトウェアでファイルの変更が警告されている場合は、その警告の直前に作成されたバックアップが適切なものであることがわかります。このバックアップは、被害を受けたシステムを再構築するときに使用できるように保管しておく必要があります。
問題が発生した場合、その問題が発見されるまでの数か月にわたってデータが破壊されている可能性があります。したがって、問題対応プロセスの一部として、問題が発生していた期間を特定することが非常に重要です。ファイル/システムの整合性検査ソフトウェアおよび侵入検出システムは、この作業に役立ちます。状況によっては、最新のバックアップや数世代前のバックアップは正常な状態に戻すために十分ではない場合があるので、定期的にデータ バックアップをアーカイブし、安全な他の場所に保管しておくことをお勧めします。
問題の証拠の収集と整理
CSIRT は問題を処理する場合、すべてのプロセスを完全にドキュメント化する必要があります。これには、侵害の説明や各対処の詳細 (対処した人物、対処の時期、および対処の理由) を含めます。対応プロセスの実行中は、アクセスを行ったすべてのユーザーをメモしておく必要があります。
後で、ドキュメントを時系列的に整理し、漏れがないかをチェックし、経営陣や法務担当者による署名および見直しを行う必要があります。また、証拠の保全フェーズでは、収集した証拠を安全に保護する必要があります。すべてのフェーズにおいて、各手順を承認できる責任者が 2 名参加することも検討します。これによって、証拠として認められなくなる可能性や、問題の発生後に証拠が改竄される可能性を小さくすることができます。
攻撃者は、従業員、下請け業者、臨時従業員、またはその他の組織内の人物である可能性があることに注意してください。完全で詳細なドキュメントがない場合、内部の攻撃者と特定することは非常に困難です。適切なドキュメントは、攻撃者を告訴する場合にも役立ちます。
インシデントの損害とコストの調査
組織に対する損害を特定するときには、直接的なコストと間接的なコストの両方を考慮する必要があります。これには、次のようなコストが含まれます。
独自の情報や機密情報が開示されたことによる競争力の損失によるコスト。
訴訟費用。
侵害の分析、ソフトウェアの再インストール、およびデータの復元にかかる人件費。
システムの停止時間に関連するコスト。たとえば、従業員の生産性の損失、売上の損失、ハードウェア、ソフトウェア、その他の資産の交換など。
被害にあったり、効果のなくなった物理的なセキュリティ対策 (錠前、壁、鉄格子など) の修繕や更新に関連するコスト。
評判や顧客の信頼性の低下などのその他の間接的損害。
対応の再検討とポリシーの更新
ドキュメント化および回復のフェーズが終了したら、プロセス全体を再検討します。チームのメンバと、正しく実行された手順と誤りの内容を調べます。ほとんどの場合、将来の問題への対応を改善するために、プロセスを変更する必要があることが判明します。
問題対応プランの弱点を見つけることはこの事後分析の重要なポイントであり、改善の余地を探すことは、新しい問題対応プランニング プロセスの始まりです。
シナリオ — Contoso の問題処理
攻撃に対処するときに、問題への対応の各段階でどのような作業が行われるかを説明するために、次のようなケース スタディを示します。ここでは、Contoso の CSIRT チームによる Code Red II ウイルスへの対応を示します。このケース スタディは架空のものですが、その対応の方法は実際に攻撃を受けた組織で行われた対応ときわめて近いものです。
表 10.3 Contoso のケース スタディ
| 問題対応の手順 | 対処 |
|---|---|
| 初期調査の実施 | 当直の CSIRT メンバである Samantha Smith が呼び出され、Contoso の侵入検出システムのログに記録されたイベントの簡単な説明を受けました。この侵入検出システムは、Web サーバー WEB2 上で Code Red II の問題が発生している可能性を示しています。Samantha は WEB2 サーバーのインターネット インフォメーション サービス (IIS) のログ ファイルで署名の文字列を調べて、c:\inetpub\scripts に root.exe が存在するかどうかをチェックします。この調査の結果は、誤検知ではないことを強く示唆しています。 |
| 問題の連絡 | Samantha は、CSIRT の他のメンバに電話で問題の発見を伝え、わかりしだい、追加の詳細情報を伝えることに同意します。 |
| 被害の拡大防止とリスクの最小化 | Contoso の問題対応ポリシーでは、ワームの存在が確認されたら、そのシステムをネットワークから切り離すことになっています。Samantha はネットワーク ケーブルを取り外します。幸いなことに、WEB2 は負荷分散サーバーの一部なので、この切断によって顧客に対する停止時間は発生しません。 |
| 問題の連絡 | Samantha は、発見の内容を電子メールで CSIRT の他のメンバに連絡し、CSIRT リーダーには直接連絡します。CSIRT リーダーは、情報セキュリティ マネージャである Taylor Maxwell を問題担当リーダーに任命します。Taylor は、すべての活動を調整し、CSIRT の中核の連絡の窓口になります。 Taylor は、技術部門の役員と当直の情報技術チームの担当者に、Web サーバーがネットワークから切り離されたことと、サーバーは少なくともワームを除去した後に再接続されることを伝えます。 Taylor は、経営陣、広報責任者、法務担当者にも連絡します。法務担当者は、告訴は不可能かもしれないが、証拠収集の手順に従って欲しいことを Taylor に連絡します。 |
| 被害の重大性の特定 | Samantha は、他のサーバーのログ ファイルを調べて、ワームが感染していないかどうかを確認します。ワームの感染は拡大していないことが確認されました。 |
| 被害の拡大防止とリスクの最小化 | 別の CSIRT メンバである Robert Brown は、Microsoft Baseline Security Analyzer (MBSA) を実行して、他のサーバーに Code Red II に対応した修正プログラムが適用されているかどうかをリアルタイムに確認します。MBSA は、ネットワーク上の Microsoftｮ Windows NTｮ Version 4.0、Windows 2000、および Microsoftｮ Windowsｮ XP を実行するすべてのコンピュータの修正プログラムの状況を管理者が集中的にチェックできるようにする マイクロソフトのツールです。Robert は、他の 2 台のサーバーがアップデートされていないことを発見し、直ちに修正プログラムを適用します。 |
| 被害の重大性の特定 | Robert は、他のすべての IIS サーバーのログ ファイルを調べて、この時点で Code Red II のインスタンスが他に存在しないことを確認します。 |
| 証拠の保全 | あらゆる情報が、被害が WEB2 に留まっていることを示しています。損害の拡大が正しく防止されており、法務部門から証拠を収集するように指示があったので、Taylor は証拠の混乱や破棄の原因となる可能性がある、立ち入ったシステム分析を行う前に、証拠を収集することにしました。チームの他のメンバは、他の Web サーバーやログで疑わしい活動がないか監視を続けています。 法科学的な証拠収集の訓練を受けた CSIRT のメンバが、被害を受けたシステムのスナップショット (つまり、完全な物理的バックアップ) を 2 つ作成します。スナップショットの 1 つは、後で法科学的な調査を行うために注意して保管します。もう 1 つのスナップショットは、回復プロセスにおいて、問題が発生する前の、安全なクリーン バックアップと組み合わせて使用されます。法科学的なバックアップは、セキュリティ ポリシーに従って、未使用の追記型メディアに保存し、詳しいドキュメントを付け、サーバーのハードディスクとともに密封して安全な場所に保管します。 |
| 攻撃の種類と重大性の特定 | 組織のセキュリティ ツールキットであるポータブル コンピュータには、数多くの調査ツールが用意されており、このコンピュータを使って回復用のバックアップに他の被害がないかどうかを調べます。レジストリ エントリやフォルダで、起動時にソフトウェアを実行するような場所に項目が追加されていないか確認します。たとえば、profile/startup ディレクトリや Run および RunOnce レジストリ キーです。ユーザー アカウントやグループ アカウント、およびユーザー権利やセキュリティ ポリシーも変更されていないか確認します。セキュリティ ログで、他に疑わしい活動が記録されていないか調べます。 |
| 外部機関への通知 | Contoso は米国政府の大規模なプロジェクトにも数多く参加しているので、Taylor は米国連邦捜査局 (FBI) の National Infrastructure Protection Center に問題について報告します。 顧客情報もシステムへのアクセスも被害を受けていないと判断されるので、顧客には通知しません。 |
| システムの回復 | WEB2 から Code Red II を除去するツールもありますが、CSIRT と WEB2 サポート チームは、新しいメディアにオペレーティング システムを再インストールすることを選択しました。オリジナルの配布メディアから新しいディスク メディアにオペレーティング システムを再インストールするとともに、Microsoft Security Toolkit を使用することによって、ハッカーのバックドアが仕掛けられたり、ファイルが壊れたりしていないクリーンなシステムであることが保証されます。 Windows 2000 を再インストールした後、このガイドの第 5 章から第 7 章に示されているガイドラインに従って、セキュリティ ロックダウンをより厳格に適用します。 感染していないバックアップを探して、ドキュメント化されている手順に従って、データを復元します。データが被害を受けたバックアップにしか存在しない場合は、別のオフライン システムに復元し、他のオペレーティング システムに対して再感染の危険性がないことが明らかになった後で WEB2 に戻します。 CSIRT チームは、システム全体の脆弱性の調査を実施し、そのプロセスで判明した情報をすべてドキュメント化します。 WEB2 をネットワークに再接続し、新しい侵害や既知の侵害の兆候がないか綿密に監視します。 |
| 問題に関するドキュメントの収集と整理 | Taylor および CSIRT は脆弱性の根本的な原因を調査し、問題のあったシステムが最近再インストールされ、修正プログラムが適用されていなかったことが判明しました。これは、明らかに既に定義されているポリシーに反しています。 この問題を細分化すると 3 つの場所で発生しています。サポート チームのメンバが修正プログラムを再適用しなかったこと、情報セキュリティ部門が遅滞なく、適用された修正プログラムを監査しなかったこと、および構成管理グループが修正プログラムの適用の必要性を認識し、情報セキュリティ部門にシステムを稼動状態に戻す前に見直しを要請しなかったことです。これらのプロセスのいずれかが実施されていれば、この問題は回避できたはずです。 チームは、この問題の再発を回避するために新しい手順を実施することを決定します。情報セキュリティ部門が社内ネットワークへのシステムの再接続を承認する前に、変更管理、Web サーバー サポート、および情報セキュリティの各部門が実行しなければならないチェックリストを作成しました。チェックリストの手順は、情報セキュリティ部門が、外部からこのシステムへのアクセスおよびこのシステムから外部へのアクセスを許可するようにファイアウォールを再構成する前に実行する必要があります。また、監査部門は、チェックリストが正確かつ完全に実行されているかどうかを定期的に検討します。 Taylor および CSIRT は、問題に対応するために実行された作業、各作業が行われた時刻、および作業を行った人物を特定するすべてのドキュメントを収集します。この情報は、コンピュータの損害に関する一般に公正妥当と認められた会計原則に従ってコストを計算するために財務担当者に送られます。 CSIRT チーム リーダーは、経営陣が問題の総コスト、問題の発生原因、将来的な問題の回避方法を理解していることを確認します。経営陣が、手順が存在しない場合や手順に従わなかった場合、および CSIRT などのリソースがない場合の意味を理解していることは重要です。 該当するチームのメンバが全体的な問題のドキュメント、問題から学んだ教訓、および実施されたポリシーと実施されなかったポリシーを再検討します。 訴訟に関連するドキュメントおよび手順を、法務担当者、CSIRT チーム リーダー、問題担当リーダー、および経営陣で再検討します。 |
まとめ
この章の多くの部分では、攻撃された場合のリスクを最小限に抑えるための対策について説明してきました。ただし、組織がセキュリティの目標を最大限に達成するには、攻撃の可能性を最小化するためにできる限りのことをした上で、攻撃された場合の対応を計画しておくことが重要です。このプロセスには、攻撃に備えて入念に監査することも含まれます。これについては、第 9 章「監査と侵入検出」を参照してください。もう 1 つ同じくらい重要なことは、攻撃を受けた場合に実際に実行できる対応を定義し、繰り返し練習しておくことです。
関連情報
『Hacking Exposed Windows 2000』、Joel Scambray および Stuart McClure 著 (McGraw-Hill Professional Publishing、ISBN: 0072192623)。
Computer Security Institute では、『Computer Crime and Security Survey』 https://www.gocsi.com という年鑑を発行しています。
詳細情報
『Handbook for Computer Security Incident Response Teams』の詳細については、以下を参照してください。 https://www.sei.cmu.edu/publications/documents/98.reports/98hb001/98hb001abstract.html
Forum of Incident Response and Security Teams (FIRST) の詳細については、以下を参照してください。 https://www.first.org
『Incident Response: Investigating Computer Crime』、Chris Prosise および Kevin Mandia 著 (McGraw-Hill Professional Publishing、ISBN: 0072131829)
『The Internet Security Guidebook: From Planning to Deployment』 Juanita Ellis、Tim Speed、William P. Crowell 著 (Academic Pr、ISBN: 0122374711)
RFC 2196 の詳細については、以下を参照してください。 https://www.ietf.org/rfc/rfc2196.txt?number=2196
『Windows 2000 Professional Resource Kit』の第 27 章「Overview of Performance Planning」の詳細については、以下を参照してください。 https://technet.microsoft.com/library/bb878161.aspx
マイクロソフト セキュリティ ツールキットは、以下のサイトから入手可能です。 https://www.microsoft.com/japan/technet/security/tools/
Cert Coordination Center (CERT/CC) については、以下を参照してください。 https://www.cert.org/
目次
第 10 章 ‐ インシデントへの対応
付録 E ‐ セキュリティで保護された LDAP および SMTP 複製を行うためのドメイン コントローラでのデジタル証明書の構成