公開日: 2006年12月25日
ダウンロード
『Security Monitoring and Attack Detection』(英語) をダウンロードする
トピック
はじめに
この文書は、中規模ビジネス セキュリティ ガイダンスの一部として提供されています。 Microsoft は、次の情報を得ることでさらにセキュリティが強化され、より生産性の高いコンピュータ環境が皆様の組織で実現されることを望んでいます。
要点
悪意のあるソフトウェアの脅威や事件の報道がここ何年もメディアを独占し注目を集めるケースが増えたため、セキュリティの問題への認識が高まり、企業はこの問題の広がりを防ぐために時間とリソースを投じるようになりました。 しかし、ビジネス インフラストラクチャにとっての最大の脅威は、ウイルスなど外側からの攻撃といった形をとるのではなく、内部ネットワーク自体に潜んでいる可能性があります。
ビジネス ネットワークの内部から開始された攻撃は、損害をもたらす可能性が非常に高くなります。特に、信頼ある地位につき、社内のすべてのネットワーク リソースにアクセスできる人物によって行われた場合は深刻です。 外部と内部の両方の脅威によるリスクを慎重に検証する場合、多くのビジネスでは、ネットワークを監視して発生源がどこであろうと攻撃を検出することができるシステムに関心が向かいます。
セキュリティの監視手段は、規制の制約を受けるビジネスにとってオプションの考慮事項ではなく、必須事項です。 この同じ規制によって、セキュリティの監視記録の保存およびアーカイブの期間と方法も制御される場合があります。 規制環境は常に変化し、ネットワークの保護、リソースにアクセスするユーザーの ID の追跡、個人情報の保護といった、規制対象のビジネスに対する要求は増える一方であるため、世界中のビジネスは効果的なセキュリティの監視ソリューションを確立するというさらに大きな要求を突きつけられています。
法規制に準拠する必要のない中規模ビジネスにとってもセキュリティの監視と攻撃検出が重要な問題となる理由はいくつかあります。 その理由の 1 つは、ビジネス インフラストラクチャに対する攻撃が成功した場合、どのような結果を招くかということです。 業務が中断するだけでなく、生産性の損失や金銭的な損失にもつながる可能性があります。 企業の評判も低下します。多くの場合、評判の回復には、攻撃によってもたらされたその他の損失の回復よりも時間を要します。
Microsoft® Windows® のセキュリティ ログ機能は、セキュリティの監視ソリューションの開始点として使用できます。 ただし、セキュリティ ログだけでは、インシデント対応の計画に十分な情報が得られません。 セキュリティ ログと、ログ情報を収集して照会する他のテクノロジとを組み合わせ、包括的なセキュリティの監視および攻撃検出ソリューションの中心部分を構成することができます。
セキュリティの監視および攻撃検出システムの主な目的は、悪意のある活動や操作上のエラーを示している可能性のあるネットワーク上の疑わしいイベントを特定することです。 ここでは、Windows ベースのネットワークにおけるこのようなシステムの必要性に対応するための計画を作成する方法について説明します。 また、このようなシステムを実装、管理、検証する方法についても説明します。
概要
この文書では、効果的なセキュリティの監視と攻撃検出ソリューションの設計と実装に必要となる重要な概念と問題を 4 つの主なセクションに分けて詳細に説明しています。 最初のセクションは、現在お読みになっている「はじめに」です。 残りのセクションは次のとおりです。
定義
このセクションには、この文書に示されているソリューションの生成および適用に関連するプロセスの理解に役立つ情報が記載されています。
中規模ビジネスの課題
このセクションでは、中規模ビジネスが直面する一般的な課題について、セキュリティの監視および攻撃検出システムと関連付けながら幅広く説明します。
ソリューション
このセクションでは、この文書に示されているソリューションを開発、実装、管理、および検証する方法について詳細に説明します。このセクションはさらに 2 つのサブセクションに分かれています。 「ソリューションを開発する」では、事前に必要な作業について説明し、計画手順を作成します。 「ソリューションを展開および管理する」では、セキュリティの監視および攻撃検出システムの展開、管理、および検証作業に役立つ情報を提供します。
対象読者
この文書では、中規模ビジネス、特に規制の制約により身元情報の保護とデータ アクセス制御を必要とする企業を対象に、プライバシーおよびセキュリティに関する問題について説明しています。 したがってこの文書は、技術部門の責任者や意思決定者から、会社のネットワークの計画、展開、運用、また特にセキュリティを担当する IT プロフェッショナルやテクノロジの実装担当者まで幅広い読者を対象とします。
この文書の一部は、ほとんどの技術部門の意思決定者にとって有用ですが、読者は特に、自社のネットワーク環境におけるセキュリティおよびリスクに関する問題に詳しく、Windows イベント ログ サービスの概念を理解している必要があります。この概念は、ここで説明する内容のすべてに応用されています。
定義
ここでは、MOF セキュリティ管理およびインシデント管理サービス管理機能 (SMF) に加え、Microsoft Operations Framework (MOF) プロセス モデルを使用しています。
特に、この文書に示されているソリューションでは、セキュリティの監視と攻撃検出の実現に、線形の展開アプローチではなく、継続プロセス アプローチを推奨しています。 具体的には、このソリューションには次の図のような手順が含まれている必要があります。
.gif)
図 1. MOF の適用
セキュリティの監視ソリューションは、実際には計画、実装、管理、テストが繰り返されるプロセスです。それがセキュリティの監視の本質だからです。 ビジネス ネットワークにとっての脅威は常に変化しているため、ビジネス ネットワークでセキュリティを監視するシステムも変化する必要があります。
セキュリティの監視にこのプロセスを適用することは、次のことを目的とするセキュリティ管理 SMF に適しています。
ビジネスの危険度を評価し、セキュリティ保護する必要がある資産を特定する
リスクを許容レベルにまで低減する方法を特定する
セキュリティ リスクを軽減するための計画を作成する
セキュリティ メカニズムの効率を監視する
効果とセキュリティ要件を定期的に再評価する
MOF の詳細については、「MOF (Microsoft Operations Framework)」を参照してください。 セキュリティ管理 SMF の詳細については、「Service Management Functions」(英語) を参照してください。
リスク管理とは、組織のリスク許容レベルを決定し、現在のリスクを評価して、リスクの許容レベルに到達する方法を見つけ、リスクを管理するプロセスです。 この文書では、リスク管理の概念とリスク評価に役立つ手順の一部を説明していますが、リスク管理の詳細な説明は、それ自体、単独で扱われるべき主題です。 リスク分析および評価の詳細については、「セキュリティ リスク管理ガイド」を参照してください。
中規模ビジネスの課題
中規模ビジネスは、効果的なセキュリティの監視システムを構築し、その作業をサポートするポリシーを確立しようとする際に、多くの課題に取り組みます。 このような課題には、次のものがあります。
ネットワーク環境全体を内部および外部の脅威から保護することの必要性と利点を理解する
確立されたポリシーの回避の試行を検出して阻止する方法が組み込まれた、効果的なセキュリティの監視および攻撃検出システムを設計する
攻撃を検出するだけでなく、改善作業に必要な環境のセキュリティ レベルの全体像を提供する、包括的で効果的な監視ポリシーを実装する
セキュリティ レポートを確立されたポリシーに効率的に関連付け、疑わしい活動を検出する管理作業を容易にするポリシーとプロセスを維持する
セキュリティの監視作業をサポートする効率的なビジネス プラクティスおよびポリシーを実装および実施し、ビジネス ニーズとのバランスをとる
利便性とリスク緩和のバランスをとるために、許容可能なリスクのしきい値を決定する
ソリューション
既に説明したように、包括的なセキュリティの監視プロセスは、フォレンシック分析を実行する必要性を促進するだけでなく、攻撃の発生前、発生時、発生後に情報を提供することができる予防的なセキュリティ手段にもなり得ます。 セキュリティ レポート用の中央リポジトリを用意することにより、攻撃が潜在的である段階、攻撃の発生時、または攻撃の発生直後に攻撃を検出することができ、効果的に攻撃に対応するために必要な情報が担当者に提供されるため、侵入の試行による影響を軽減することができます。
セキュリティの監視を実装することによって得られるさまざまな利点を開発の概念化段階で理解することが重要です。そうすれば、設計およびポリシーにこれらの利点をすべて活用することができます。 セキュリティの監視によってもたらされる利点には、次のようなものがあります。
セキュリティ ポリシーまたは更新ポリシーに準拠していないシステムを特定して改善し、中規模ビジネスの脆弱性プロファイルを改善する。
異常な活動を特定することによって、実際に攻撃が発生する前に、侵入の試行をスタッフに警告することが可能な情報を作成する。
セキュリティ監査情報を作成して保護することにより、フォレンシック分析を改善する。これにより、法規制を満たすだけでなく、発生する可能性のある攻撃の影響を軽減することができます。
セキュリティ レベルの分析作業を支援し、全体的なセキュリティを向上させる。
確立されているビジネス プロセス外で発生する活動は、意図的か偶発的かにかかわらず検出する。
ネットワーク上の管理されていないシステムの特定や、脆弱なデバイスの改善を支援する。
ソリューションを開発する
セキュリティは、多くのビジネスにとって重要な問題です。 ほとんどの企業では、物理的なセキュリティに関しては、ドアに鍵をかけるといった一般的なことからカードを使った出入り制限のような入念なものまで、さまざまな方法で妥当なレベルのリソースを投じていますが、依然として多くの企業では、データへの依存度がますます高まってきているにもかかわらずデータのセキュリティには十分に対処していません。
データのセキュリティおよび監視に関する問題が注目を集めると、企業は一般的に、ファイアウォールを使用した境界でのデータ セキュリティ措置に重点を置きます。 しかし、このアプローチだけに依存すると、この他の攻撃に対しては脆弱なままになります。 米国シークレット サービス (United States Secret Service) およびコンピュータ緊急対応センター (CERT Coordination Center) によって公開されている「2004 E-Crime Watch Survey」(英語) によると、特定された攻撃者の 29% は実際に、現在の従業員、契約社員、元従業員など内部の人間です。 このことを考慮すると、外部が発生源となる脅威だけでなく内部の脅威にも対応するには、多層セキュリティ アプローチが必要であることが明らかになります。
事後対応的セキュリティのスタンスから内部と外部の両方の脅威に対処するための方法の 1 つは、セキュリティ監査ログ プロセスを実装することです。 Microsoft Windows NT® 3.1 から現在のバージョンまで Microsoft Windows の全バージョンで、ビルトインのセキュリティ イベント ログ ファイルを使用してセキュリティ イベントが記録されます。 ただし、既に発生した侵入に対応してフォレンシック調査を実行する場合はこのビルトイン機能だけでも役に立ちますが、この機能を単独で予防的に使用して、攻撃活動の前兆を特定したり、侵入の試行されている最中にそれを適切な担当者に警告することは困難です。
前述のとおり、セキュリティ ログは多くの場合、セキュリティ インシデント発生後のフォレンシック分析の際に事後対応的に使用されます。 しかし、米国シークレット サービスおよび CERT によって公開されている「2005 Insider Threat Study」(英語) では、重要な結果の分析から、セキュリティのログおよび監視を事後対応的なフォレンシックだけでなく予防的な検出に使用できることがわかりました。 また、内部と外部にかかわらずほとんどの攻撃者は、ログを改ざんすることによって痕跡を隠そうとします。したがって、システム ログを保護するための対策を講じる必要があります。 セキュリティ ログ、および監視と攻撃検出に使用されるその他の方法を実装し、適切に保護すれば、ネットワーク セキュリティ対策に不可欠なツールとなることがわかっています。
システム セキュリティ ログはこの文書の中心的なトピックですが、システム セキュリティ ログはセキュリティの監視および攻撃検出方法の中核部分を構成しているというだけです。 考慮する必要があるその他の問題には、確立されたセキュリティ ポリシーに準拠していないシステムや、現在推奨されている脆弱性に対する更新プログラムが実装されていないシステムを特定して改善する方法があります。 また、内部ネットワーク インフラストラクチャの監視も必要です。これにはスイッチ ポートのセキュリティ レポート (管理されていないシステムによるネットワーク アクセスを阻止する) や、ワイヤレス セキュリティの監視 (不正な接続やパケット スニッフィングを阻止する) などがあります。 監視に関するこれらのトピックの多くはこの文書の対象外ですが、いずれも包括的なセキュリティの監視ソリューションでは注目に値するものです。
セキュリティの監視を実装する
次のサブセクションからは、セキュリティの監視システムの実装に関するさまざまな考慮事項について説明します。
Windows セキュリティ イベント ログ
Microsoft Windows NT 3.1 以降の Microsoft Windows の全バージョンで、ビルトインのログ ファイル機能を使用してセキュリティ イベントを記録することができます。 Microsoft Windows ベースの環境では、この機能がセキュリティの監視の基礎となります。 ただし、この情報を関連付ける追加のユーティリティまたはツールがなければ、情報は分散し、この機能を予防的に使用することは難しくなります。
.gif)
図 2. イベント ビューアのセキュリティ ログ
.gif){kind=link}
セキュリティ イベント ログ (上図) は、カスタム ファイル形式を使用してセキュリティ監視データを記録します。 これらの記録の一部はテキスト エディタで読み取ることができますが、これらのログに記録された情報をすべて表示するには、イベント ビューアなどの適切なプログラムが必要です。 セキュリティ イベント ログ ファイル (SecEvent.evt) は、%systemroot%\System32\config ディレクトリにあります。 イベント ログへのアクセスは常にイベント ログ サービスを介して管理され、イベント ログ サービスによって、各ログに対するアクセスが制御されます。 セキュリティ ログの既定のアクセス許可は、システム上の他のログと比較して非常に厳しくなっています。既定では、管理者のみがセキュリティ ログにアクセスすることができます。
セキュリティ イベント ログに記録されるイベントには、 成功の監査と失敗の監査の 2 種類があります。 成功の監査イベントは、ユーザー、サービス、またはプログラムが実行した操作が正常に完了したことを示します。 失敗の監査イベントは、正常に完了しなかった操作の詳細を示します。 失敗の監査イベントの例としてはユーザーのログオン失敗があり、ログオン監査が有効になっている場合は、セキュリティ イベント ログに記録されます。
コンピュータの構成\Windows の設定\ローカル ポリシーの下にある [監査ポリシー] グループ ポリシー設定で、セキュリティ ログにエントリを作成するイベントの種類を制御します。 監査ポリシーの設定は、[ローカル セキュリティ設定] コンソールから、またはサイト、ドメイン、組織単位 (OU) レベルで Active Directory のグループ ポリシーを介して構成することができます。
監査イベントを解釈する
監査イベントについては、この文書を通じてかなり詳細に説明します。したがって、監査イベントの構造と監査イベントに含まれる情報について基本的に理解することが重要です。
.gif)
図 3. [イベントのプロパティ] ウィンドウ
イベントは、 イベント ヘッダー、イベントの説明、およびバイナリ データ セクションの 3 つの基本部分で構成されています。
イベント ヘッダーは、次の各フィールドで構成されています。
表 1. イベント ヘッダー
| フィールド | 定義 |
|---|---|
| 日付 | イベントが発生した日付 |
| 時刻 | イベントが発生した現地時刻 |
| 種類 | イベントの深刻度または種類の分類。 セキュリティ監査イベントの場合、成功の監査または失敗の監査のいずれかです。 |
| ソース | イベントを記録したアプリケーション。 これは、SQL Server などの実際のプログラム、ドライバ名、または「セキュリティ」などのシステム コンポーネントのいずれかになります。 |
| 分類 | イベントのイベント ソースの分類。 これは、グループ ポリシーで構成できるイベントの種類に対応しているため、セキュリティ監査ログで使用されます。 |
| イベント ID | このコードで、特定のイベントの種類を識別します。 上の図では、イベント ID が 680 となっています。このイベント ID は、ローカル プロセス、リモート プロセス、またはユーザーによって一連の資格情報が認証システムに渡されたことを示します。 |
| ユーザー | イベント発生の原因となったユーザーのユーザー名。 この名前は、プロセスによってイベントが発生した場合はクライアント ID、偽装が行われていない場合はプライマリ ID となります。 セキュリティ イベントでは、可能な場合および該当する場合、プライマリと偽装情報の両方が表示されます。 |
| コンピュータ | イベントが発生したコンピュータの名前。 |
中央リポジトリへのイベント情報の保存とその管理。 監視システムの構成によっては、イベント情報の保存で TB (テラバイト) 単位のデータを処理する可能性があります。 このことは、フォレンシック分析の必要性を検討する場合に最も重要です。詳細については、フォレンシック分析のセクションで説明します。
攻撃パターンの特定とそれへの対応。 攻撃の前兆の可能性がある活動パターンを特定するには、そのような活動とそれに関連付けられたイベントを情報として提供し、それによってレビュー担当者または構成済みのクエリが疑わしいイベントを識別できなければなりません。 疑わしい活動が特定されたら、タイムリーで適切な対策を促すメカニズムが働くようにする必要があります。
セキュリティ監査制御を行うスタッフの制限。 監査情報へのアクセスを制限するには、ネットワーク上で上位の特権を持つユーザー (特に管理者) を区画化し、セキュリティの専門家のみが監査システムの管理を担当するようにする必要があります。
ソリューションの計画
セキュリティの監査および攻撃検出システムを実装する前に、次の作業を実行する必要があります。
現在のセキュリティ監査設定を確認する
管理者の役割と通常のユーザーのタスクを評価する
ビジネス ポリシーと手順を確認する
脆弱なシステムを特定する
高価値資産のリストを作成する
機密性の高いアカウントや不審なアカウントを特定する
認証されたプログラムのリストを作成する
ストレージ要件に関する詳細については、後述の「フォレンシック分析を実装する」セクションを参照してください。
現在のセキュリティ監査設定を確認する
企業は、現在のセキュリティ監査とセキュリティ ログ ファイルの設定を確認し、この文書で推奨されている変更の基準にする必要があります。 このような見直しをソリューションの実装後も定期的に行い、次のような情報を入手する必要があります。
現在有効なセキュリティ監査設定
これらの設定を適用するレベル (ローカル コンピュータ、サイト、ドメイン、または組織単位)
現在のログ ファイル設定 (サイズ制限と最大サイズに達した場合の動作)
適用できる追加のセキュリティ監査設定 (たとえば、バックアップと復元の特権の使用の監査など)
この文書の最後にある「付録 B: グループ ポリシー設定の実装」 を参考に、どの設定を記録する必要があるかを判断してください。 セキュリティ監査設定の詳細については、「Windows Server 2003 セキュリティ ガイド」を参照してください。
管理者の役割と通常のユーザーのタスクを評価する
効果的なセキュリティの監視ソリューションを実装するための重要な要素の 1 つは、管理者アカウントの所有者、およびその役割と責任を周知徹底することです。 たとえば、ほとんどのビジネスでは、管理者が Domain Admins グループに属し、新しいユーザー アカウントをドメイン内に作成できるようになっています。 ただし、インストールされているプロビジョニング システムのみが新しいアカウントを作成できることがビジネス ポリシーで指定されている場合があります。 このような場合、管理者アカウントがアカウント作成イベントを開始すると、すぐに調査するように警告されることがあり得ます。
ユーザー アカウント タスクの評価は通常、もっと簡単です。このようなアカウントがネットワーク リソースにアクセスすることは、管理者アカウントに比べて通常はるかに少ないからです。 たとえば、一般ユーザーは通常、ネットワークの境界にあるコンピュータのファイル システムにアクセスする必要はないため、このようなサーバーで一般ユーザーの活動を監視する必要はほとんどありません。
ビジネス ポリシーと手順を確認する
ビジネス プロセスと手順の確認は、管理者の役割と責任の評価に限定されるというわけではありませんが、かなり密接に対応しています。 この確認作業を構成する重要な要素には、たとえばユーザーの作成プロセスや変更管理プロセスの検証があります。 承認プロセスを行ったり、ネットワーク上で発生するすべてのイベントの監査記録を作成するメカニズムの検証は、何が認証された監査イベントとなり、何が侵入の試行であるとされるかの関係を定義するために不可欠です。
脆弱なシステムを特定する
脆弱なシステムとは、ネットワーク上で、外部の攻撃者が最初に探りを入れ、アクセスしようとするコンピュータおよびデバイスのことで、そこを突破口にその他の方法を試そうとします。 通常このようなコンピュータはネットワークの境界にありますが、内部のデバイスも攻撃に対して脆弱である場合があるため、完全に無視することはできません。
脆弱なシステムの包括的な見直しでは、次のことを確認する必要があります。
関連するすべてのセキュリティ更新プログラムとサービス パックが適用されている
不要なサービスおよびユーザー アカウントが無効になっている
ローカル サービス アカウントまたはネットワーク サービス アカウントで実行されるようにサービスが構成されている (可能な場合)
ユーザー アカウントの資格情報を要求するサービスがチェックされ、このアクセス レベルの要求が確実に行われている (特に管理者権限を持つアカウントの場合)
高セキュリティ ポリシーのテンプレートが適用されている
注 この確認プロセスは、境界にある脆弱なコンピュータに限らず行う必要があります。 セキュリティの点で望ましいのは、ネットワーク上のすべてのコンピュータにこれらのチェックを適用することです。
サービスが安全に実行されるように構成する方法については、「サービスおよびサービス アカウントのセキュリティ計画ガイド」を参照してください。
高価値資産のリストを作成する
ほとんどのビジネスでは、ネットワーク内にある高価値資産が既に特定されていると考えられますが、この情報が組織のポリシーの中で、各資産に適用する保護対策を詳細に文書化するという一定の形になっていない場合があります。 たとえば、ある企業はアクセス制御リスト (ACL) と暗号化を使用して、機密性の高い財務記録を安全に NTFS ファイル システムのパーティションに保存しているかもしれません。 しかし、このような記録は権限のないユーザーや管理者がアクセスしてはいけない保護対象のファイルとして組織のポリシーで明確に特定し、管理者とユーザーにこの制限を認識させる必要があります。
このようなファイルの保護に使用される ACL に変更が加えられる場合、特に所有権の変更が関係する場合はすべて調査する必要があります。このようなイベントは、正式な許可のない不正なファイル アクセスを示す可能性があるからです。 この種の所有権の変更は非常にまれであるため、高価値資産を特定し文書化した後は、このような変更の検出が簡単になるはずです。
機密性の高いアカウントや不審なアカウントを特定する
機密性の高いアカウントをすべて見直して、より高い監査レベルが必要なアカウントを特定する必要があります。 そのようなアカウントには、既定の管理者アカウント、Enterprise、Schema、または Domain Admins グループのすべてのメンバ、およびサービスによって使用されるすべてのアカウントが含まれます。
機密性の高いアカウントとは別に、リスクとして特定されている個人、または不審な活動への関与が疑われる個人が持つアカウントのセキュリティ監査レベルを調整することも重要です。 個人のユーザー アカウントの監査レベルを調整する方法については、後述の「ポリシー違反としきい値」セクションを参照してください。
認証されたプログラムのリストを作成する
ネットワークに関する情報を検出するために、攻撃者はそのネットワーク内にあるシステムでプログラムを実行する必要があります。 ネットワーク上で実行が許可されるプログラムを制限することによって、外部からの攻撃の脅威を大幅に軽減できます。 認証されたプログラムのリストを作成するには、現在ネットワーク環境で認証されているか、必要と特定されたすべてのプログラムについて監査を実行する必要があります。 このような監査で検出された不明なプログラムはすべて不審とみなし、直ちに調査する必要があります。 Microsoft Systems Management Server 2003 はソフトウェアの監査に役立ちますが、この製品がなくても可能です。
注 特定のコンピュータについては一部例外が必要な場合があります。たとえば開発者のワークステーションに存在する開発中の実行可能ファイルが、承認済みプログラムのリストに載っていない場合などです。 ただしより安全なアプローチとしては、開発およびテストを必ず仮想コンピュータ環境または分離された開発ネットワーク ドメインでのみ行うようにすることです。
ポリシー違反としきい値を検出する
ポリシー違反は、セキュリティ問題の中で最大のカテゴリを形成しているため、それに合った計画を作成する必要があります。 この種のインシデントには次のものがあります。
確立されているプロセス外でのユーザー アカウントの作成
管理者特権の不適切または不正な使用
サービス アカウントを使用した対話型ログオン
許可されていないユーザー アカウントによるファイルへのアクセス試行
ユーザー アカウントがアクセス許可を持つファイルの削除
許可されていないソフトウェアのインストールおよび実行
ポリシー違反の最も一般的な種類は、制限されたディレクトリの参照など、故意でないユーザー アクセス試行です。このような違反は通常、アクセス制限および適切に設計された権利ポリシーで対処できるため、重要度が最も低くなります。 管理ポリシーの違反は、管理者権限の性質上、故意か偶然かにかかわらず最も重大な種類のイベントです。
管理者アカウントの特権により、業務にその種の権限を必要とする個人に対して大幅なシステム アクセス権が与えられます。 ただしこの権限は、許可された範囲またはプロセス以外でも同様のシステム権限を使用することを認めるものではありません。 管理者アカウントでは、ユーザー アカウントの作成の有効化、ユーザー アカウントの変更、制限されたデータの表示、データ アクセス権の変更ができるため、そのような強力な権限に伴うリスクを軽減する方法を慎重に検討する必要があります。
脅威モデルを作成する
以上のように、脅威には監査によって軽減することができるものとできないものがあり、監査によって軽減できてもそれがコストに見合わない場合もあります。 理解すべき主な点は、すべての脆弱性がネットワークにとって脅威となるわけではないということです。 どの部分の脆弱性を軽減することが可能であるか、またはそれが必要であるかを判断するには、脅威モデル作成の原則を適用することが役立つ場合があります。
脅威モデルの作成は、脅威と脆弱性を特定することにより、特定の環境についてより効率的に対策を立てるためのエンジニアリング技術です。 このプロセスには通常、次の 3 つの基本手順があります。
攻撃者からの見方を理解する
システムのセキュリティ プロファイルを特定する
関連する脅威を把握し、ランク付けする
より端的に言えば、攻撃者の観点からネットワーク環境を検証すると、ネットワークにアクセスしようとする人物にとって最も魅力的なターゲットは何か、そのようなターゲットへの攻撃が成功するにはどのような条件を満たす必要があるのかが把握されます。 格好の脆弱なターゲットを特定したら、環境を検証して、既存の保護手段が攻撃の条件にどう影響するかを判断することができます。 このプロセスにより、関連する脅威が明らかになり、それらの脅威が示すリスクのレベルに基づいて脅威をランク付けすることができます。また、その脅威に対して最も有効な解決策をもたらす改善活動は何か、リスクの軽減が他の領域にプラスに影響するのかマイナスに影響するのか (これがその改善活動の価値に影響します) も明らかになります。
したがって、これらの要件に基づいて、ネットワークの脅威モデルの作成プロセスを成功させる具体的な手順が実際にいくつかあります。
重要な資産を特定する。 最も適切なセキュリティ リソースの投入先を判断する作業には、業務に不可欠な資産のリスト作成が含まれます。 このプロセスには、テクノロジの所有者だけでなく、ビジネス プロセスの所有者もかかわる必要があります。漏えいした場合ビジネスへの被害が大きいのはどの資産であるかについて、それぞれが重要な観点を持っているからです。
考えられる攻撃ポイントを特定する。 この特定段階にも、実際に 2 種類の観点が含まれます。 まず、ネットワーク上のデータを囲む境界の種類を分類する必要があります。 これらの境界は、境界内のデータが流出した場合に受ける可能性のある損害に基づいて、重要領域、機密領域、公開領域のいずれかの内側に配置されます。 次にテクノロジの観点で攻撃ポイントを検証します。ここでは、攻撃の経路と、考えられる脆弱なポイントのうちのどれが、重要な資産および機密性の高い資産を流出させる危険性があるかを考慮します。 この情報を組み合わせることにより、重要な情報にアクセスされる可能性のあるポイントの脆弱性に的を絞ってセキュリティ措置を講じることができます。
実際の脅威を特定する。 重要な資産、および考えられるアクセス ポイントが明らかになったら、攻撃者が損害を与えるために行う可能性のある行為のリストを作成できます。 このリストを使用すれば、実際の具体的な脅威に重点を置いて取り組むことができます。
実際の脅威を特定するために使用できる方法はさまざまです。 STRIDE は、使用される攻撃の種類に基づいて脅威を検証する方法の 1 つです。STRIDE とは、Spoofing (なりすまし、ID 偽装)、Tampering (改ざん)、Repudiation (否認)、Information disclosure (情報の漏えい)、Denial of service (サービス拒否)、Elevation of privilege (特権の昇格) の略語です。 (ネットワーク、ホスト、アプリケーションなどの) 論理層別に脅威を分類するなど、その他の反復的な方法もあります。 アプローチは組織ごとに、自社の環境に最も合ったものを選択します。
脅威を分類してランク付けする。 この手順では、一般的なリスク評価およびリスク管理の原則を活用します。ここでは、脅威が実際に起こる確率と、それらの脅威がビジネスに及ぼす可能性のある影響に基づいて脅威をランク付けします。 使用する標準的な公式は次のとおりです。
リスク = 悪用の確率 x 潜在的なビジネスへの影響
このようなプロセスでは実際にさまざまな方法や、リスク評価を支援するさまざまなツールが使用されますが、これらについてはこの文書では扱っていません。 リスク管理とこれらの方法の詳細については、「セキュリティ リスク管理ガイド」を参照してください。
改善して再評価する。 ここまでの手順の成果として、ビジネスに影響しかねない実際の脅威のリストが得られます。このリスト内の脅威は、そのビジネスに対して示されるリスクの順にランク付けされています。 このリストにより、的を絞った改善作業が可能になります。この改善作業の費用対効果もまた、評価する必要があります。 結局、特定のリスクを軽減するのにいくつか異なる方法がある場合があり、中には他の脆弱性にも対処できるものがあるため、そのようなセキュリティ措置はさらに効果的です。
改善計画が実施された後であっても、脅威モデルの作成手法は反復的なプロセスであるため、常に再評価しながら定期的に実行し、セキュリティ措置が可能な限り効果的で包括的なものになるようにする必要があります。
経歴調査および再調査
ほとんどのビジネスでは、雇用の条件として、内定者に関する何らかの経歴調査を既に実行していますが、雇用後は調査しません。 企業は、制限された情報にアクセスできる重要な地位の場合は特に、従業員の雇用期間中も定期的に経歴調査を実行することを検討する必要があります。
コンピュータの使用ポリシーに関する合意
コンピュータまたはネットワークの使用に関する合意は、会社の資産の使用方法を従業員に知らせるためだけでなく、ネットワーク活動およびコンピュータの使用を監視するためのポリシーと、これらのポリシーに違反しようとした場合に起こりうる結果を知らせるためにも重要です。
使用ポリシー ステートメントは、これらの事項を明確に定義し、合意の印として従業員の署名を必要としている場合、法律文書としても機能します。 内部セキュリティの監視ポリシーと、会社の資産を使用する際に許容される範囲について従業員が十分に認識していたという証拠がなければ、従業員に不正な行為があった場合その従業員を起訴することはますます難しくなっています。
また、会社のネットワーク上のすべてのアクセス ポイントで、アクセスおよび不正使用の警告を発行し、アクセスしようとするすべてのユーザーに、それがプライベート ネットワークであることと、不正なアクセスは禁止されており、行った場合は起訴されることを通知することも重要です。 たとえば、Windows オペレーティング システムには、ログオン試行イベント時に警告メッセージを表示する機能があり、これを使用すると、保護された企業のリソースにアクセスしようとしていること、不正なアクセスは禁止されていることをユーザーに通知することができます。
この種の文書の正確な文言や使用に関する法的な問題はここでは説明の対象外ですが、こういった文書やポリシーの必要性に言及することは重要です。 こういった使用やアクセスに関するステートメントの例はインターネット上に多数存在しますが、これらの資料を準備する際は必ず、資格を持つ法律顧問に相談してください。地域に固有の法律問題や国際法にかかわる問題が多くあるため、慎重に検討する必要があります。
職務の分離
システムのさまざまな機能がネットワーク全体でセキュリティ、パフォーマンス、および可用性といった目的別にセグメント化されているように、IT セキュリティ部門の配属要件を作成する場合は、職務の重複と分離を規定することが重要です。
機密性の高いデータおよびシステムに対するアクセスまたは制御を伴う重要な役割は、可能かつ妥当である限り、複数のスタッフに割り当てる必要があります。これは、スタッフが欠けた場合の知識の喪失に伴う問題を防止するためだけでなく、社内で妨害活動があった場合のセキュリティ機能という意味でもあります。 たとえば、管理パスワードを知っているスタッフが 1 人だけで、そのスタッフが管理パスワードを誰にも教えずにいなくなった場合、事態の回復は困難です。
役割を重複させることに加えて、重要な役割については役割を分離することも重要です (特にセキュリティの監視)。 ネットワーク管理者がセキュリティ監査情報の確認も担当することがないようにします。また、セキュリティ スタッフが管理者と同等の管理者権限を持つべきではありません。 場合によっては、職務の分離をさらに適用するために、部門の情報を管理スタッフから隔離する必要もあります。 たとえば、財務や人事など機密性の高い情報を保護するために、組織単位が独自のシステムまたは管理者アカウントを持つ例もあります。
注 このように職務を分離しても、管理者アカウントの所有者が抜け道を見つけ出すことを阻止できないかもしれませんが、少なくとも、職務の分離の原則を使用する管理権限について、正しい使用を規定するガイドラインを確立することが重要です。
セキュリティの監視機能を検証する
セキュリティの監視ソリューションを実装する前に、そのようなプログラムの定期的なテストを入念に計画する必要があります。 初期テストは、セキュリティの監視ソリューションを検証するために重要ですが、セキュリティ環境は常に変化するため、テストのスケジュールを作成して定期的に実行することが重要です。
侵入の試行や管理者特権のテスト使用をテストに盛り込んで、そのような活動の検出にソリューションが有効かどうかを判断することができます。 ただし、セキュリティ技術や攻撃プロファイルにおける最新の変更内容を調査して、テストを変更する必要があるかどうかを判断することも重要です。 攻撃者はセキュリティの実装に適応するため、ビジネス ネットワークにとっての脅威は常に変化しています。したがって、防御および監視技術は常に進化して有効性を維持する必要があります。
プロセスを確立する
認証されたイベントと不正なセキュリティ イベントを区別するには、変更管理プロセスと問題管理プロセスの確立と義務付けを計画する必要があります。 このような計画により、セキュリティ ログ情報と相互に関連付けることができる詳細な紙面記録が得られます。 ほとんどの企業では、問題の追跡はヘルプ デスク チケットやその他の問題追跡プロセスという形で行うのが一般的ですが、変更管理はしばしば軽視されます。 変更管理は必須のメカニズムであり、動向を追跡して問題のあるシステムまたはアプリケーションを突き止めるためだけでなく、重要なセキュリティ メカニズムとしても使用できます。
変更管理プロセスは、予防的な手順として実行する必要があり、事後対応的な変更は、問題管理プロセスを使用する場合に限定する必要があります。 変更管理プロセスでは、変更の前に必ず提出または承認を要求し、次のような詳細が含まれている必要があります。
承認者の名前
実装者の名前
変更の期限
変更の理由
行われる変更
変更の影響を受けるシステム
ビジネスへの影響
変更を行った実際の結果
確立する必要のあるもう 1 つのプロセスは、ユーザーの追加/変更/削除手順を介したユーザー プロビジョニング プロセスです。このプロセスもまた、監査記録を作成して不正なアカウント変更を防止します。 このようなプロセスを確立する前に、現在あるユーザー アカウントのセキュリティ監査を実行してこれらのアカウントの有効性を確認し、このリストの変更に応じて定期的に検証することが重要です。
Microsoft Identity Integration Server (MIIS) 2003 などの自動ユーザー プロビジョニングおよび ID 管理ソリューションを使用すると、アカウント変更やそのような活動の背後にあるプロセスが自動化されるため、さらに役立ちます。 このようなソリューションを使用する場合、管理者アカウントが持つ新規アカウントの作成権限はそのまま残りますが、アカウントは確立されたプロセスによって作成されるようになるため、管理者がアカウントを作成する必要はなくなります。 したがって、イベント 624 など、アカウントの作成に関連するイベントはすべて、MIIS 2003 または自動プロビジョニングに使用されるその他の確立されたサービス アカウントにのみ関連付けられる必要があります。
ビジネス ネットワークに対する外部からの脅威が絶えずメディアで報道されていますが、ネットワークおよび企業データは、不適切な構成や手続き上のミスによる損失または漏えいに対してはるかに脆弱であることが経験からわかっています。 外部と内部のすべての脅威から保護することが重要であり、外部の脅威からの企業の保護を支援するベンダは多数ありますが、企業のネットワークおよびセキュリティの担当者のミスを防止するパッケージを企業に販売できるベンダはありません。 そのようなリスクを軽減するための最善の方法は、ネットワーク上で実行される変更に関する適切なプロセスおよび手順を実装して実施することです。
セキュリティ対応を定義する
セキュリティ違反によって発生する可能性のある損害を抑えるには、明確で適切な対応計画を作成し、インシデントに対応するためのプロセスを確立することが重要です。 インシデント レポート、迅速に対応するチームの編成、緊急対応の手順などが良い例です。 インシデント対応のスピードと効果によって、組織のセキュリティ プロファイルが向上し、侵入の試行によって発生する可能性のある、実際に感じられる損害が限定的なものになります。
確立されたセキュリティ対応プロセスを構成すると、実際のインシデントが引き起こす可能性のある損害を限定するのに役立つだけでなく、インシデントによって、セキュリティ違反には組織的かつ迅速な対応がなされることがスタッフおよびその他の個人に周知されるため、抑止力にもなります。
人事
CERT および米国シークレット サービスによって行われた研究によると、企業が従業員の行動の変化や脅威により注意を払い、それに対する措置をとれば、内部の人間による攻撃の多くは回避することができます。 ビジネスにおける最も価値のあるセキュリティ リソースはおそらく、従業員自身です。スタッフが不満を持っている場合そのことに気付いたり、訪問者の行動に不審な点がある場合に適切な担当者に警告するのは従業員だからです。 実際、外部のセキュリティ監査グループが最初にとる行動の 1 つは、紙に書かれたパスワード情報を探す、セキュリティ保護されていないデバイスを見つける、または内部ネットワークに直接接続することによって侵入を試行する、などの目的で「歩き回る」ことです。
企業のスタッフは、内部および外部の脅威に対する重要な保護レイヤとしての役割を果たすことができます。 同僚の気がかりな行動について話せるようにオープン ドア ポリシーを奨励したり、サポート担当者にトレーニングを実施して、コンピュータの異常な動作についてスタッフから受けた報告はすべて真面目に受け取るように教育すると、侵入の試行やマルウェアのインシデントを軽減できます。 社内トレーニングは、報告する必要のあるコンピュータの動作の種類を見分ける方法を従業員に教える手段としても重要です。 トレーニングは、ソーシャル エンジニアリング攻撃の回避という点で予防策にもなります。
セキュリティ ポリシー違反を監査イベントに関連付ける
セキュリティ イベント情報の関連付けでは、複数のシステムからセキュリティ イベントを収集し、このデータを安全な集中管理場所に保存します。 セキュリティ情報が関連付けられたら、適切な担当者がこの中央リポジトリを分析して違反や外部からの攻撃を特定することができます。 このリポジトリは、フォレンシック分析のためだけでなく、攻撃を検出し脆弱性に対処するツールとしても重要です。 この目的のために提供されているサードパーティ ソリューションはいくつかありますが、次のマイクロソフト製品およびツールでは、セキュリティ イベント ログおよびその他のセキュリティ監視情報を中央リポジトリに関連付けることによってこのニーズに対処できます。
EventCombMT
EventCombMT (マルチスレッド型) は、「Windows Server 2003 セキュリティ ガイド」のコンポーネントです。このツールでは、複数のコンピュータ上にあるイベント ログからイベントを収集して解析できます。 このツールは、マルチスレッド型のアプリケーションとして実行され、ユーザーはイベント ログのスキャン時に次のようなパラメータをいくつでも指定できます。
イベント ID (1 つまたは複数)
イベント ID の範囲
イベント ソース
特定のイベント テキスト
イベントの経過時間 (分、時間、日数)
.gif)
図 4. EventCombMT
.gif){kind=link}
EventCombMT には、次のイベントの検索機能を提供するアカウント ロックアウト (上図参照) など、特定の検索カテゴリがいくつか組み込まれています。
529。ログオンが失敗した (ユーザー名またはパスワードが正しくない)
644。ユーザー アカウントが自動ロックされた
675。ドメイン コントローラで事前認証に失敗した (パスワードが正しくない)
676。認証チケット要求が失敗した
681。ログオンが失敗した
セキュリティ ログ ファイルにはないもう 1 つのセキュリティ関連のイベントは、システム ログ ファイルにあるイベント 12294 です。 このイベントをすべての検索に追加することが重要です。このイベントは、ロックアウトのしきい値がなく、したがって攻撃者となる人物にとっては脆弱な格好のターゲットである管理者アカウントへの攻撃の試行を検出するために使用できるからです。
注 イベント 12294 は、セキュリティ ログではなく、システム ログに Security Accounts Manager (SAM) イベントとして表示されます。
EventCombMT では、Microsoft SQL Server™ データベース テーブルにイベントを保存できるため、長期保存や分析に便利です。 SQL Server データベースに保存したイベント ログの情報には、SQL Query Analyzer、Microsoft Visual Studio® .NET、多数のサードパーティ製ユーティリティなど、各種プログラムを使用してアクセスできます。
Log Parser 2.2
Log Parser はマイクロソフトが提供する無償のツールです。ログ内のデータの検索、SQL データベースまたは CSV ファイルへのログのアップロード、およびイベント ログ、CSV ファイル、または他のログ形式 (IIS ログを含む。Log Parser は本来、IIS ログ用に設計されたものです) からのレポート生成に使用できます。
このコマンドライン スクリプト作成ツールは、イベント ログ情報を集中管理場所に関連付け、注意を引くイベントを解析し、さらにレポートを生成するためのリソースとして使用できます。 ただし、スクリプト作成およびコマンドライン インターフェイスには、ある程度詳細な説明が必要ですが、これはこの文書の対象外です。 Log Parser の詳細、使用方法、およびスクリプト作成リソースについては、「Log Parser 2.2 (日本語版)」および「Log Parser 2.2 の動作方法」を参照してください。
EventQuery.vbs
EventQuery.vbs は、Windows XP と共にリリースされたツールです。 このツールを使用すると、1 つまたは複数のイベント ログからイベントおよびイベントのプロパティを一覧表示できます。 このスクリプトを使用するには、コマンドベースのスクリプト ホスト (CScript.exe) が実行されている必要があります。 既定の Windows スクリプト ホストが CScript に設定されていない場合、次のコマンドを実行することによって設定できます。
Cscript //h:cscript //s //nologo
このコマンドライン スクリプト ユーティリティは非常に柔軟で、出力に適用されるフィルタや形式を調整するさまざまなパラメータを受け入れることができます。 このツールの使用方法および使用できるパラメータの詳細については、「Windows XP Professional Product Documentation」の「Managing event logs from the Command Line」(英語) を参照してください。
インターネット インフォメーション サービス ログ
インターネット インフォメーション サービス (IIS) で使用できる追加のログ機能には、サイトの訪問者の ID 、訪問者がアクセスした情報、および訪問者がアクセスした日時を報告する機能があります。 IIS ログは、サイト、仮想フォルダ、およびファイルへのアクセスの成功と失敗を記録します。また、ストレージ要件を最小限に抑え、不要な情報の記録を制限するために、その情報を選択的に監査するように構成できます。
これらのログは、ネイティブ形式でファイルとして保存すると、前述の解析および照合ツールのいずれかを使用してフィルタリングできます。または、ODBC データベース ログを使用して集中管理場所に直接保存することもできます。この場合、SQL データベースまたはその他の ODBC 準拠データベースに情報を保存できます。
次のような特定の活動および一連のイベントは、厳重に監視する必要があります。
実行可能ファイルまたはスクリプトを実行しようとして失敗したコマンドが複数ある。
単一の IP アドレスまたはアドレス範囲からのログオン試行の失敗が極端に多い。これは、DoS または特権の昇格のいずれかの試行を示す可能性があります。
.bat ファイルまたは .cmd ファイルに対するアクセスまたは変更の試行が失敗した。
実行可能ファイルを含むフォルダへファイルを不正にアップロードしようとしている。
Windows Server 2003 以降、新しい監査機能が IIS に組み込まれ、イベント ログに直接統合されている IIS の新しいログ機能と共に使用するか、カスタム ソリューションの ASP ページを使用してアクセスすることができます。 これらの機能の詳細および実装方法については、IIS のマニュアルを参照してください。
Microsoft Internet Security and Acceleration Server
Microsoft Internet Security and Acceleration (ISA) Server は、高度なステートフル パケットおよびアプリケーション レイヤ ファイアウォールで、VPN および プロキシ キャッシング機能などの追加機能も提供します。
ISA Server は、有効な防御ユーティリティを提供するだけでなく、ネットワークの境界を通過するすべての活動を監視できる集中ログ ツールとしての機能を使用することにより、セキュリティの監視機能としても役立ちます。 ISA Server のログ機能には、ファイアウォール トラフィック ログ、Web プロキシのアクティビティ ログ、および SMTP メッセージのスクリーニング ログのキャプチャ機能が含まれます。 これらのログは、ビルトインのリアルタイム ログ ビューア (次のスクリーン ショットを参照) を使用して、またはダッシュボードを監視して、リアルタイム ベースでフィルタリング、照会、または監視することができます。
.gif)
図 5. Microsoft ISA Server 2004 リアルタイム ログ ビューア
.gif){kind=link}
ISA Server には、ビルトインのログ機能以外にも、電子メール、イベント ログ エントリ、または開始/停止サービスによって警告を発行できる警告機能があります。 不審な活動をイベント ログ エントリに記録する機能は、この文書の目的では特に有効です。 この機能を使用すると、予想される攻撃の情報を他の監査イベント ログ データと共に集中管理場所に記録および保管することができます。
このログおよび警告機能に加えて、ISA Server で有効にすることができるビルトインの侵入検出ツールもあります。 これらの基本的な侵入検出サービス (IDS) は、Internet Security Systems からライセンス供与されたもので、IP パケット フィルタ、DNS アプリケーション フィルタ、および POP アプリケーション フィルタを含みます。 これらのサービスでは、多くの一般的な悪用を検出できます。
ISA Server の侵入検出機能では、イベントをログに記録し、潜在的な攻撃が検出された場合に警告を生成することができます。 また、サービスや不審な接続を終了することもできます。 検出できる攻撃プロファイルには、次のものがあります。
WinNuke (帯域外攻撃)
Land 攻撃
IP half scan 攻撃
UDP bomb
ポート スキャン
長いホスト名を送信しオーバーフローを引き起こす DNS 攻撃
特権または上位 TCP/IP ポートからの DNS ゾーン転送
いずれの場合も、ISA Server を使用するか、他のファイアウォールおよび IDS ソリューションを使用するかにかかわらず、セキュリティの監視および攻撃検出システムを設計する際には、境界ネットワーク (DMZ、非武装ゾーン、スクリーン サブネットとも呼ばれます) を考慮することが重要です。
Microsoft Operations Manager 2005
Microsoft Operations Manager (MOM) は、エンタープライズ環境で複数のサーバーを中央から監視します。 MOM エージェントは、イベント ログからイベントを収集して MOM 管理サーバーに転送し、MOM 管理サーバーはそれらのイベントを MOM データベースに格納します。 MOM 2005 およびそれ以降のバージョンでは、MOM エージェントを実行していないコンピュータからイベントを収集することができます。
MOM は、管理パック ルールを使用して、サーバーの運用効果に影響する問題を特定します。 特定のイベントを監視し、これらのイベントの発生時に、電子メールやポップアップ メッセージで、またはポケベルに直接、警告通知が送信されるように追加のルールを作成することができます。
MOM には、セキュリティの監視および攻撃検出に使用できる便利な機能が多数ありますが、本来はこのために設計されたものではありません。 MOM の今後のリリースでは、セキュリティ ログ収集機能がさらに強化される予定です。
Microsoft Systems Management Server 2003
Microsoft Systems Management Server (SMS) 2003 では、ネットワーク内のサーバーとワークステーションを中央から監視および管理できます。 SMS は管理タスクを対象としていますが、セキュリティ更新プログラムの配布を管理し報告することによって、または不正なソフトウェア インストールについて報告することによって、セキュリティの監視ソリューションで重要なセキュリティ関連機能も提供します。
SMS のインベントリ機能は、あらゆるセキュリティ監査および監視プロセスに欠かせない、集中管理されたリアルタイムのインベントリ管理ソリューションとして機能することにより、セキュリティの監視ソリューションで重要なニーズに応えます。
フォレンシック分析を実装する
フォレンシック分析は、それ自体が 1 つの大きな主題であり、ここで包括的に説明することはできません。 特にこの文書では、フォレンシック分析の証拠の取り扱い要件や、セキュリティ イベント ログによって提供される情報以外のフォレンシック データについては説明しません。
セキュリティ違反のタイミング、深刻度、および結果の判断や、攻撃者によって影響を受けたシステムの特定は、フォレンシック分析によって行うことができます。 有効なフォレンシック分析を行うには、収集される情報に次の情報が含まれている必要があります。
攻撃の時刻
攻撃の持続期間
攻撃の影響を受けたシステム
攻撃時に行われた変更
繰り返しになりますが、証拠立ての手順を規定する法律、フォレンシックに関する重要なデータ型、分析に必要なツール、証拠の収集、証拠の保存、およびフォレンシックの方法を理解するには膨大な説明が必要になるため、ここでこの主題を詳しく取り上げることは不可能です。 ただし、CERT による「First Responders Guide to Computer Forensics」(英語) など、優れたリソースがいくつかあり、セキュリティの研究を扱うサイトで入手することができます。
ビジネス上の問題
フォレンシック分析の使用計画は、他のソリューションへのアプローチとは異なります。この計画には、インシデントのリアルタイム分析ではなく、発生後のインシデントの調査が含まれるからです。 したがって、複数のシステムから収集したイベントの詳細な履歴をより長期にわたって維持する必要があります。 このような追加条件があるため、効果的なフォレンシック分析システムには、集中管理と、適切なデータベース構造で大量のレコードを保存するための膨大なストレージ容量が必要です。
これを軽減するビジネス上の意思決定の 1 つでは、このようなレコードをフォレンシック分析のために保持する必要のある期間と、どのような種類の保存サイクルを使用する必要があるかに注目します。 これらの要素は、フォレンシック分析計画のストレージ要件および機器要件に大きく影響することがあります。 次の表に、確立されたフォレンシック分析計画を持つ企業でよく見られる一般的な保存期間を示します。
Table 2. Storage Limits for Forensic Analysis
| 保存の要素 | 保存期限 | コメント |
|---|---|---|
| オンライン ストレージ (データベース) | 21 日間 | イベントの詳細への高速アクセスが可能 |
| オフライン ストレージ (バックアップ) | 180 日間 | ほとんどの組織にとって妥当なアーカイブ期限 |
| 規制環境 | 7 年間 | 規制対象ビジネスのアーカイブ要件 |
| 情報機関 | 永久 | 情報および防衛組織の要件 |
フォレンシック分析ソリューションでは、ビジネス環境の要件、機能、および規制の制約を考慮に入れる必要があります。これらに関しては組織によってそれぞれ異なるからです。
ソリューションを展開および管理する
攻撃を特定し、プロファイルし、対応する能力は、あらゆるセキュリティの監視および攻撃検出ソリューションの基本的な目標です。 したがって、このセクションの大部分では、イベント ログで見つかった場合に進行中の攻撃を示す可能性のある関連イベントについて詳細に説明します。 これを念頭に置いたうえで、セキュリティの監視および攻撃検出計画は次の要件を満たす必要があります。
内部のポリシー違反を検出する
外部ソースからの攻撃を特定する
効率的で正確なフォレンシック分析を可能にする
ここで説明するソリューションでは、これらの 3 つの各要件に対して同様のコンポーネントを使用します。 フォレンシック分析機能の実装には、後述する追加の要件があります。
セキュリティの監視と攻撃検出
セキュリティの監視および攻撃検出ソリューションの概念では、次の領域についての適切なレベルのセキュリティ監査の計画が必要です。
アカウント管理
保護されたファイルへのアクセス
セキュリティ ポリシーの変更
信頼の作成と削除
ユーザー権利の使用
システムの再起動と時間の変更
レジストリの変更
不明なプログラムの実行
セキュリティの監視および攻撃検出システムは、セキュリティ イベント ログから情報を収集し、この情報を中央の場所で照合します。 その後セキュリティ監査担当者は、不審な活動がないかこのデータを分析できます。 さらにこの情報は、後日必要が生じた場合にフォレンシック分析を行うために保存およびアーカイブすることもできます。
このソリューションの主要なコンポーネントは、Microsoft Windows 2003 Service Pack 1 (SP1) および Microsoft Windows XP Service Pack 2 (SP2) のユーザーごとの監査と呼ばれる機能を構成する機能です。 ユーザーごとの監査では、特定のユーザー アカウントに対して異なる監査レベルを指定することができ、それにより、機密性の高いアカウントや不審なアカウントに関するより高いレベルの監査詳細を得ることができます。
ソリューションの必要条件
このセキュリティの監視および攻撃検出ソリューションを構成するには、次のような必要条件があります。
サーバーが Windows Server 2003 SP1 以降を実行し、Active Directory ドメイン内にあること
クライアント コンピュータが Active Directory ドメインのメンバとして Windows XP SP2 以降を実行していること
注 企業の境界にあるコンピュータがドメインに属していない場合、これらのコンピュータを Active Directory グループ ポリシー設定で構成することはできません。 ただし、そのようなシステムの構成には、ローカル ポリシーおよびテンプレートを使用できます。
この文書では、攻撃の特有のパターンを特定することに重点を置いています。考えられるソリューションをいくつか挙げてはいますが、セキュリティ イベントの照合に使用する特定のテクノロジの推奨は行っていません。 適切な収集メカニズムに関する決定を行った後は、ここで挙げるイベントおよびイベントのシーケンスを使用して、不審な動作を特定するためのクエリと警告を設計することができます。
ポリシー違反としきい値
Microsoft Windows Server 2003 および Microsoft Windows XP SP2 の新機能では、個々のユーザー アカウントの監査レベルを選択することができます。 たとえば、すべてのユーザーについてログオンおよびログオフ活動のみを報告し、同時にある特定のユーザーについてはすべての活動を監査するように監査レベルを設定することができます。 ユーザーごとに選択可能な監査は、特定のアカウントを特定の活動の監査生成から除外することによって、セキュリティ ログ内のイベントの量を減らすためにも使用できます。 この機能を使用して監査できるのは、ユーザー アカウントのみです。セキュリティ グループおよび配布グループは、この方法で監査することはできません。 Administrators ローカル グループに属するアカウントは、ユーザーごとに選択可能な監査メカニズムを使用して監査から除外することはできません。
Windows Server 2003 および Windows XP SP2 で、選択可能な監査を行うための、ユーザーごとの監査ポリシーの設定に使用するコマンドライン ユーティリティは、Auditusr.exe です。選択可能な監査で有効なカテゴリは次のとおりです。
System Event (システム イベント)
Logon/Logoff (ログオン/ログオフ)
Object Access (オブジェクト アクセス)
Privilege Use (特権の使用)
Detailed Tracking (詳細追跡)
Policy Change (ポリシーの変更)
Account Management (アカウント管理)
Directory Service Access (ディレクトリ サービス アクセス)
Account Logon (アカウント ログオン)
コマンドラインから Aauditusr.exe をパラメータを指定せずに実行すると、選択可能な監査の現在の設定が表示されます。これは最初は空白のままになっています。 選択可能な監査のパラメータを入力する方法は 2 とおりあります。ユーザーごとに 1 つ、コマンドライン パラメータとして手動で入力する方法と、ユーザーごとの監査設定ファイルをインポートすることによって複数のパラメータを入力する方法です。
Audituser.exe は、次のように使用します。
Audituser.exe /<パラメータ> <ユーザー アカウント>:”<カテゴリ>”
(または、コンマで区切られたカテゴリのリスト)
たとえば、LocalUser というアカウントについてシステム イベントとログオン/ログオフ イベントの失敗の監査を有効にするには、次のコマンドラインを入力します。
Audituser /if LocalUser:”System Event”,”Logon/Logoff”
コマンドラインでは、次のパラメータを使用できます。
/is – include-success エントリを追加または変更
/if – include-failure エントリを追加または変更
/es – exclude-success エントリを追加または変更
/ef – exclude-failure エントリを追加または変更
/r – 特定のユーザー アカウントのユーザーごとの監査エントリをすべて削除
/ra – すべてのユーザー アカウントのユーザーごとの監査エントリをすべて削除
/e – 指定したファイルに設定をエクスポート
/i – 指定したファイルから設定をインポート
ユーザーごとの監査の設定ファイルはテキストファイルで、次の図のような形式を使用します。
.gif)
図 6. Auditusr.exe のインポート ファイルの例
注 正常にインポートするには、インポート ファイルの最初の行が図のように “Auditusr 1.0” となっている必要があります。
上図に示されている監査の設定ファイルをインポートするには、次のコマンドを使用します。
Audituser /i path\audit.txt
このユーティリティは、監査ログ情報のしきい値の設定に役立てることができます。しきい値を設定することで、ストレージ要件を軽減し、侵入の試行が検出される可能性を高めることができます。
セキュリティ ポリシー違反と監査イベントの相関関係
このセクションでは、ポリシー違反の発生源が外部ソースか内部ソースかを区別して扱いませんが、内部のポリシー違反は外部が発生源となる攻撃と同じくらいビジネスにとって致命的となる可能性があることを認識することが重要です。 前述したように、悪意のある攻撃のうちかなりの割合が内部ソースによって実行されたもので、この割合には、確立された手順の範囲外で上位の特権を誤用したことによって発生した偶発的な損害は含まれていません。
内部ソースによる上位の特権の偶発的または意図的な誤用にはリスクを避けるため、これらの特権の適切な使用に関してポリシーと手順を確立することと、相関する監査記録を作成することが重要です。 変更管理プロセスと文書化ポリシーを設定したら、承認されたイベントおよび未承認のイベントそれぞれと監査情報とを関連付ける相関関係を作成し、それによって企業内の不審な動作を容易に検出できるようになります。 このセクションでは、この相関関係を作成するため、追跡できるさまざまなイベントの種類と、それらをポリシーおよびプロセスに適用する方法について説明します。
許可されていないコンピュータへのアクセス
管理/サポート スタッフが、リモート システムとの接続や管理にターミナル サービスなどのリモート管理機能を使用する機会は増えてきています。 これらのシステムの対話型ログオンの試行は監視する必要があり、接続試行ごとに有効性を確認する必要があります。 このような確認では、次の作業を実行する必要があります。
サービス アカウント ログオンを特定する
許可されていないアカウントによるアクセス試行を記録する
いつもと違う地域からの試行を調査する
外部の IP アドレス範囲からの試行のリストを作成する
高価値資産の監視には特に注意する必要があります。 そのような重要なリソースは特定のサーバーに配置し、厳しい監査の監視設定およびアクセス制御設定を適用して構成する必要があります。
次の表は、ログオン監査イベントのリストです。これらのイベントが高価値資産のシステムで発生した場合、許可されたアカウントのリストと比較します。
表 3. コンピュータの不正使用イベント
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 528 | ログオンの成功 | [ワークステーション名] と [ユーザー アカウント名] を確認してください。 ソース ネットワーク アドレスがネットワーク内にあることを確認してください。 |
| 529 | ログオン失敗 – ユーザー名が不明またはパスワードが無効です | [対象アカウント名] が Administrator または名前が変更された既定の管理者アカウントである試行をチェックしてください。 また、アカウントのロックアウトのしきい値を下回る複数のログオン失敗も確認します。 |
| 530 | ログオン失敗 – 時間の制限 | 許可されている時間範囲を超えたログオン試行を示します。 [ユーザー アカウント名] と [ワークステーション名] を確認してください。 |
| 531 | ログオン失敗 – アカウントは現在無効に設定されています | [対象アカウント名] と [ワークステーション名] を確認してください。 このイベントは、元の従業員が侵入しようとしたことを示す場合があるため、調査する必要があります。 |
| 532 | ログオン失敗 – 指定されたユーザー アカウントの有効期限が切れています | [対象アカウント名] と [ワークステーション名] を確認してください。 このイベントは、契約社員または臨時社員による悪用を示す可能性があるため、調査する必要があります。 |
| 533 | ログオン失敗 – ユーザーはこのコンピュータへのログオンを許可されていません | ユーザーが、制限されたワークステーションにログオンしようとした可能性があることを示します。 |
| 534 | ログオン失敗 – 許可されていないログオンの種類です | [対象アカウント名]、[ワークステーション名]、および [ログオンの種類] を確認してください。 このイベントは、サービス アカウント資格情報を使用した対話形式のログオンがグループ ポリシー設定で禁止されている場合に、そのアカウントで対話形式のログオン試行に失敗したことを示します。 |
| 535 | ログオン失敗 – 指定されたアカウントのパスワードの有効期間が切れています | ユーザーが、パスワードの有効期間が切れているアカウントでログオンしようとしたことを示します。 該当するパスワードの変更やサポートへの連絡がなく繰り返される場合は、調査が必要なことがあります。 |
| 536 | ログオン失敗 – NetLogon コンポーネントがアクティブではありません | NetLogon サービスが機能していることを確認します。 機能していない場合、調査が必要なことがあります。 |
| 540 | ログオンの成功 | このイベントは、イベント 528 がネットワークで発生する場合に相当します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 592 | 新しいプロセスの作成 | 未承認のプロセスの [イメージ ファイル名] と [ユーザー名] のエントリ、予期しない起動時刻、または開始してすぐに終了する不明なプログラムをチェックします。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 560 | アクセスは、既存のオブジェクトに対して許可されました | オブジェクトに対するアクセス要求が許可されたことを示します。 不正アクセスを検出するには、[プライマリ ログオン ID]、[クライアント ユーザー名]、および [プライマリ ユーザー名] を確認してください。 操作の種類を判断するには、[アクセス] フィールドを確認してください。 このイベントは、実際にアクセスが行われたかどうかではなく、アクセス要求のみを検出します。 |
| 567 | ハンドルに関連付けられているアクセス許可が使用されました | オブジェクトに対するあるアクセスの種類の最初のインスタンスを示します。[アクセス] フィールドに “WRITE_DAC” が表示される場合、アクセス許可が変更されています。 [ハンドル ID] フィールドを比較することによって、イベント 560 との関連を確認してください。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 627 | パスワード変更の試行 | パスワードの変更要求を示します。この要求で、要求者は元のパスワードを入力しました。 要求元のアカウントが変更対象のアカウントかどうかを判断するには、[Primary Account Name] と [対象アカウント名] を比較します。 |
| 628 | ユーザー アカウント パスワードの設定またはリセット | パスワード変更プロセスではなく、管理インターフェイスからのパスワードのリセットを示します。 要求者は、ヘルプ デスク アカウントやセルフサービス パスワード リセット アカウントなどの許可されたアカウントである必要があります。 |
| 698 | ディレクトリ サービスの復元モード パスワードの変更 | ドメイン コントローラでディレクトリ サービスの復元モード パスワードを変更しようとしたことを示します。 [Workstation IP] と [アカウント名] を確認します。 このイベントが発生した場合は、直ちに調査する必要があります。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 624 | ユーザー アカウントの作成 | ネットワーク アカウントの作成が行われたことを示します。 |
| 630 | ユーザー アカウントの削除 | ネットワーク アカウントの削除が行われたことを示します。 |
| 642 | ユーザー アカウントの変更 | セキュリティ関連のユーザー アカウントの変更がイベント 627 ～ 630 に該当しないことを示します。 |
| 685 | ユーザー アカウント名の変更 | ユーザー アカウント名の変更を示します。 |
アカウントの作成、最初のログオン、およびパスワードの変更の間の間隔を確認することも重要です。 新しいアカウントが、あらかじめ定義された期間内に使用されない場合 (通常は、アカウントの作成プロセスによって新しいユーザーの開始予定日が記録されます)、そのアカウントを無効にして調査を開始し、遅延の理由を調べる必要があります。
グループ メンバシップの変更
優れたセキュリティの実践方法として、最小限の特権の原則をお勧めします。つまり、職務を十分に遂行するために必要な最小レベルのアクセス許可をアカウントに付与するということです。 これを実践した場合、ほとんどのアカウントは既定の Domain Users グループのメンバになり、それにビジネス固有のセキュリティ グループのメンバシップが追加されます。
セキュリティ グループのメンバシップの変更は、特に上位の特権を持つアカウントがかかわる場合、必ず確立されたポリシー ガイドラインに従って行う必要があります。 セキュリティ グループのメンバシップの変更は、アカウント管理に使用される確立されたアカウントによってのみ実行される必要があり、発生するイベントは、この変更に対して確立されたプロセスに関連していなければなりません。 このプロセスにない変更が行われた場合、直ちに調査する必要があります。
次の表に示すアカウント管理の監査イベントは、グループ メンバシップの変更を詳細に説明しています。
表 8. グループ メンバシップの変更イベント
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 631、632、 633、634 |
セキュリティが有効なグローバル グループが変更されました | 変更されたグループがグローバル グループであるかどうか、または広範なアクセス特権を持つかどうかを判断するには、[対象アカウント名] フィールドを確認します。 |
| 635、636、 637、638 |
セキュリティが有効なローカル グループが変更されました | 変更されたグループが Administrators、Server Operators、または Backup Operators であるかどうかを判断するには、[対象アカウント名] フィールドを確認します。 |
| 639、641、 668 |
セキュリティが有効なグループが変更されました | 削除、作成、またはメンバシップの変更以外の変更がグループに加えられたことを示します。 高い特権を持つグループが変更されていないことを確認するには、[対象アカウント名] を確認します。 |
| 659、660、661、662 | セキュリティが有効なユニバーサル グループが変更されました | Enterprise Admins などの高い特権を持つグループが変更されていないことを確認するには、[対象アカウント名] フィールドを確認します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 528 540 | ログオンの成功 | 528 は、一般的なイベントです。 ただし、イベント 540 が発生した場合は、イベントの原因が既定の管理者アカウントかどうかを判断するために [対象アカウント名] を確認する必要があります。 |
| 529 | ログオン失敗 – 不明なユーザー名またはパスワード | [対象アカウント名] が Administrator または名前が変更された既定の管理者アカウントである場合は必ず調査してください。 また、ログオン失敗がロックアウトのしきい値をぎりぎりで下回る場合も調査します。 さらに、[対象アカウント名] が Administrator または root で、[ドメイン名] が不明な試行も確認します。 |
| 531 | ログオン失敗 – 無効なアカウント | ソースを判断するには、[対象アカウント名] と [ワークステーション名] を確認してください。 このイベントが発生した場合は、元のアカウント ユーザーによる侵入の可能性があるため調査する必要があります。 |
| 532 | ログオン失敗 – 期限切れのアカウント | ソースを判断するには、[対象アカウント名] と [ワークステーション名] を確認してください。 このイベントが発生した場合は、元のアカウント ユーザーによる侵入の可能性があるため調査する必要があります。 |
| 576 | 新しいログオンへの特権の割り当て | 新しいアカウントに管理者特権または監査記録を変更する権限を付与できる特権が割り当てられたことを示します。 [ログオン ID] フィールドをイベント 528 または 540 と比較すると、取得されたアカウントが管理者と同等かどうかを簡単に判断できます。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 528 | ログオンの成功 – コンソール攻撃またはターミナル サービス | ログオンの種類 10、サービス アカウント、またはローカル システム アカウントがこのイベントに関連付けられている場合は、攻撃が進行中であることを示します。 このイベントが発生した場合は、直ちに調査する必要があります。 |
| 534 | ログオン失敗 – 許可されていないログオンの種類です | グループ ポリシー設定で禁止されている、サービス アカウント資格情報を使用した対話形式のログオン試行が失敗したことを示します。 このイベントが発生した場合は、[対象アカウント名]、[ワークステーション名]、および [ログオンの種類] を確認します。 |
| 600 | プロセスへのプライマリ トークンの割り当て | サービスが、Windows XP 以降を実行しているシステムにログオンするために名前付きのアカウントを使用していることを示します。 イベント 672、673、528、および 592 の情報と関連付けて調査してください。 |
| 601 | ユーザーがサービスをインストールしようとしました | このイベントは、使用を許可するアプリケーションについてのポリシーとシステム標準化プロセスがビジネス環境で明確に定義されていれば、たびたび発生するようなことはありません。 そのような環境でこのイベントが発生し、変更管理プロセスが関連付けられていない場合は、調査する必要があります。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 592 | 新しいプロセスの作成 | 新しいプロセスが作成されたことを示します。 使用を許可するプログラムについてのポリシーを企業で設定している場合は、[イメージ ファイル名] および [ユーザー名] フィールドを確認し、許可されているプログラムのリストと比較してください。 また、コマンド プロンプトの起動に LocalSystem が使用されているインスタンスも確認します。これは、監査記録から逃れるための一般的な方法だからです。 |
| 602 | スケジュールされたジョブの作成 | このようなイベントが予期しない時間に発生する場合は、[ターゲット名] と [Task Time] を確認します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 560 | アクセスは、既存のオブジェクトに対して拒否されました | [オブジェクト名] フィールドを確認してアクセスされたリソースを判断し、[プライマリ ユーザー名] と [プライマリ ドメイン] フィールド、または [クライアント ユーザー名] と [クライアント ドメイン] フィールドを関連付けて発生源を判断します。 |
| 568 | 監査対象ファイルへのハード リンクを作成しようとしました | ユーザーまたはプログラムが、ファイルまたはオブジェクトへのハード リンクを作成しようとしたことを示します。 ハード リンクを確立すると、アカウントにそのオブジェクトに対する権利がある場合、監査記録を作成せずにファイルを操作できます。 |
組織のポリシーでは、ユーザーが遠隔地から仮想プライベート ネットワークまたはリモート アクセス サービスを介してネットワークに接続する方法を指定できます。またその中に、オペレーティング システムの種類、更新レベル、およびパーソナル ファイアウォールやウイルス対策ソフトウェアなどの保護手段といった、接続システムの要件を含めることができます。 リモート システムが企業のセキュリティ ポリシーに確実に準拠するようにする方法の詳細については、「Microsoft 仮想プライベート ネットワークでの検疫サービスの実装計画ガイド」を参照してください。
ユーザーは、Windows XP インストール CD を使用してコンピュータを再起動することで、管理されていないオペレーティング システムをインストールすることもできます。 このような場合、不明なワークグループ名または既定のワークグループ名の管理者ユーザー アカウントからのログオン試行を見つけることによって、この種の活動を検出できることがあります。
注 配布されているオープン ソース プログラムの中には、CD からの起動が可能なものがあります。このような CD を使用すると、ローカル システムにインストールせずにオペレーティング システムを使用できます。 この場合、オペレーティング システムがローカル コンピュータにインストールされていないため、そのような活動を特定することは困難です。 ただし、同機種ネットワーク環境の “root” のユーザー アカウントや予期しないコンピュータ名からログオンが試行された場合、許可されていないオペレーティング システムが使用中であることを示している可能性があります。 この種の活動を阻止するには、コンピュータの BIOS 設定で CD から起動する機能を無効にしてから、BIOS 構成をパスワードで保護する方法もありますが、環境によってはこの方法は現実的ではありません。
仮想 PC イメージにより、ホスト コンピュータでコンピュータ環境を完全にエミュレートすることができます。 このエミュレーションでは、仮想環境で独自のコンピュータ名、ユーザー アカウント、ディレクトリ サービス構造、およびプログラムを使用して独自のオペレーティング システムを実行します。 また、仮想 PC インスタンスは、ホスト システムから独立して開始、実行、および停止することができるため、そのホスト コンピュータ上に監査イベントが作成される可能性はあまりありません。 この機能は、ホストのネットワークに接続して IP アドレスを取得し、共有デバイスへのマッピングも行う仮想コンピュータの機能と共に、ネットワークに導入されている確立された更新プロセスによって制御されない可能性があるため、パスワード保護が脆弱である、悪用される危険性が高まるなど、さまざまなセキュリティ リスクとなります。 仮想 PC によるこれらのリスクを考えると、仮想 PC ソフトウェアの使用を権限のある担当者のみに制限し、仮想 PC インスタンスの作成と使用に関して文書化されたプロセスを確立することが重要です。
許可されていないオペレーティング システムの使用を検出するには、セキュリティの監視ソリューションで次のものを検出できなければなりません。
認識できないユーザー アカウント、コンピュータ名、ワークグループ、またはドメイン名
重複する、または範囲外の IP アドレス
既定の管理者アカウントでのログオン試行
次の表に示すプロセス追跡イベントは、許可されていないオペレーティング システムの使用の検出に使用できます。
表 13. 許可されていないプラットフォームの使用イベント
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 529 | ログオン失敗 – 不明なユーザー名またはパスワード | [対象アカウント名] が Administrator または root であるか、[ドメイン名] が不明な試行を確認します。 |
| 533 | ログオン失敗 – ユーザーはこのコンピュータへのログオンを許可されていません | ユーザーが、制限されたワークステーションにログオンしようとした可能性があることを示します。 |
| 592 | 新しいプロセスの作成 | [イメージ ファイル名] および [ユーザー名] フィールドを確認して、プログラムがそのアカウントによるその用途に許可されていることを確認します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 610 611 620 |
別のドメインとの信頼関係が作成、削除、または変更されました | これらのイベントは、信頼関係を確立したドメイン コントローラで生成されます。 このイベントが発生し、確立された変更管理要求プロセスに関連付けられていない場合は、直ちに調査を行う必要があります。 要求元のアカウントを判断するには、[ユーザー名] フィールドを確認します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 612 | 監査ポリシーの変更 | 監査ポリシーに対する変更を示します。 これらのイベントは、確立された変更管理ポリシーに関連付けて、許可されているものかどうかを判断する必要があります。 |
| 613 614 615 |
IPSec ポリシーの変更 | IPSec ポリシーに対する変更を示します。 システムの起動時以外に発生する場合は、調査が必要です。 |
| 618 | 暗号化されたデータの回復ポリシー | これらのイベントは、暗号化されたデータの回復ポリシーが使用されている場合に発生します。 指定したポリシー以外で発生する場合は、調査する必要があります。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 529 | ログオン失敗 – 不明なユーザー名またはパスワード | [対象アカウント名] が Administrator またはその他の管理レベルのアカウントで、パスワードの変更が許可されていない可能性があるログオン試行を確認します。 ログオンが複数回失敗しているが、ロックアウトのしきい値を下回っているものを確認します。 イベント 529 とイベント 539 を関連付け、連続的なアカウント ロックアウトのパターンを特定します。 |
| 534 | ログオン失敗 – 許可されていないログオンの種類です | ネットワーク、対話型、バッチ、サービスなどの許可されていないアカウントの種類を使用してユーザーがログオンを試行したことを示します。 [対象アカウント名]、[ワークステーション名]、および [ログオンの種類] フィールドを確認してください。 |
| 539 | アカウントのロックアウト | ロックアウトされているアカウントでのログオン試行を示します。 イベント 529 と関連付け、連続するロックアウトのパターンを検出します。 |
| 553 | リプレイ攻撃の検出 | 認証パッケージ (通常は Kerberos) によって、ユーザーの資格情報のリプレイによるログオン試行が検出されたことを示します。 このイベントは、ネットワーク構成が不適切であることを示している可能性もありますが、直ちに調査する必要があります。 |
| 627 | パスワード変更の試行 | [Primary Account Name] フィールドが [対象アカウント名] フィールドと一致しない場合、アカウント所有者以外の人物がパスワードを変更しようとしたことを示します。 |
| 628 | ユーザー アカウント パスワードの設定またはリセット | この操作は、ヘルプ デスク アカウントやセルフサービス パスワード リセット アカウントなどの許可されたアカウントに制限する必要があります。 |
| 644 | ユーザー アカウントが自動的にロックされました | ログオン試行の連続失敗回数がアカウントのロックアウト制限数を超えたため、ユーザー アカウントがロックアウトされました。 イベント 529、675、681、および 676 (Windows 2000 Server のみ) と関連付けてください。 また、この表のイベント 12294 の項目も参照してください。 |
| 675 | 事前認証の失敗 | 時刻同期の問題やドメインに正しく参加していないコンピュータ アカウントがある可能性を示します。 ログオン失敗の正確な理由を判断するには、イベント 529 と関連付けてください。 |
| 12294 | アカウント ロックアウトの試行 | 既定の管理者アカウントに対するブルート フォース攻撃の可能性を示します。 このアカウントにはアカウント ロックアウトのポリシーが実施されないため、システム イベント ログには SAM イベント 12294 として記録されます。 このイベントが発生した場合は、許可されていないオペレーティング システムの使用を示す可能性があるため、調査を行う必要があります。 [ドメイン名] フィールドが不明なドメインかどうか確認します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 528 538 | ローカル ログオンとログオフ | 境界コンピュータでこのようなイベントが発生した場合は、[ログオン ID] フィールドを関連付けてください。 [ユーザー アカウント名]、[時刻]、または [ワークステーション名] フィールドに予期しない値が含まれている場合は、調査を行う必要があります。 |
| 551 | ユーザーによるログオフ開始 | このイベントは、イベント 538 に相当するものとみなすことができます。トークン リークによってイベント 538 の監査は失敗することがありますが、代わりにイベント 551 が発生するからです。 |
| 576 | 特権ログオン | 管理者アカウントのログオンを示します。これは、Windows Server 2003 SP1 以降で、Trusted Computing Base (TCP) を改ざんしたりコンピュータを支配するための十分な特権を持つアカウント ログオンです。 Windows の以前のバージョンでは、SeSecurityPrivilege や SeDebugPrivelege などの機密性の高い特権に関連付けられている場合にのみこのイベントに注目します。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 512 | Windows の起動 | 通常はイベント 513 の後に発生します。予期しない再起動は調査する必要があります。 |
| 513 | Windows のシャットダウン | 通常はイベント 512 の前に発生します。高価値コンピュータの再起動は、権限のある担当者のみが行う必要があります。その場合でも、確立された変更管理手順またはその他の手順に必ず従います。 どのサーバーでこのイベントが発生した場合でも、直ちに調査する必要があります。 |
| 516 | 監査の失敗 | このイベントは、イベントが多すぎてイベント ログ バッファに入りきらないか、セキュリティ ログが上書きするように設定されていないかのいずれかの場合に発生する可能性があります。 ほとんどのコンピュータでは、監視するイベントの種類を制限することによってこれらの問題を防ぐことができますが、高価値コンピュータや脆弱なコンピュータを保護するには詳細に監視しなくてはならないため、やはり慎重な監視が必要です。 |
| 517 | セキュリティ イベント ログの消去 | セキュリティ イベント ログは、許可なく消去しないでください。 [クライアント ユーザー名] および [クライアント ドメイン] フィールドを確認して、権限のある担当者および手順の承認記録と相互に関連付けを行います。 |
| 520 | システム時刻の変更 | この操作は、フォレンシック調査を混乱させるため、または攻撃者に偽のアリバイを提供するために使用されます。 [クライアント ユーザー名] および [クライアント ドメイン] フィールドを確認して、権限のある担当者と相互に関連付けます。さらに、[プロセス] に %windir%\system32\svchost.exe が表示されているかどうかを確認します。 |
| 521 | イベントをセキュリティ ログに記録できません | Windows がイベントをイベント ログに書き込むことができない場合に発生します。 高価値システムのいずれかでこの問題が発生した場合は、必ず調査する必要があります。 |
| 608 | ユーザー アカウントの特権が割り当てられました | ユーザー アカウントに新しい特権が割り当てられると発生します。 イベント ログには、ユーザー アカウント名ではなく、ユーザー アカウントのセキュリティ識別子 (SID) とともにこの操作が記録されます。 |
| 609 | ユーザー アカウントの特権が削除されました | ユーザー アカウントから特権が削除された場合に発生します。 イベント ログには、ユーザー アカウント名ではなく、ユーザー アカウントの SID とともにこの操作が記録されます。 |
| 612 | 監査ポリシーの変更 | このイベントは必ずしも問題があることを示すわけではありませんが、攻撃者が攻撃の一環として監査ポリシーを変更する可能性もあります。 このイベントは、高価値コンピュータおよびドメイン コントローラで監視する必要があります。 |
| 621 | アカウントに対してシステム アクセス権限が付与されました | システムへのアクセス権限がユーザーに付与された場合に発生します。 アクセス許可が対話型として表示されている場合は、[ユーザー名] および [アカウントの変更] フィールドを確認する必要があります。 |
| 622 | システムからシステム アクセス権限が削除されました。 | このイベントは、攻撃者がイベント 621 に関する証拠を削除しようとしたか、他のアカウントに対してサービス拒否を試行していることを示す可能性があります。 |
| 643 | ドメイン セキュリティ ポリシーの変更 | パスワード ポリシーまたは他のドメイン セキュリティ ポリシー設定の変更が試行されている場合に発生します。 [ユーザー名] を確認して、承認レコードと関連付けます。 |
| イベント ID | 発生イベント | コメント |
|---|---|---|
| 538 | ユーザーのログオフ | このイベントは、必ずしもユーザーがシステムの使用を停止した時間を示すわけではありません。 たとえば、コンピュータがシャットダウンされた場合やネットワーク接続が切断された場合、ログオフ イベントが全く記録されないことがあります。 |
| 562 | オブジェクトへのハンドルが閉じられました | 常に成功として記録されます。 |
| 571 | 承認マネージャによりクライアント コンテキストが削除されました | 承認マネージャを使用している場合は、正常な動作です。 |
| 573 | プロセスが AuthZ API (Authorization Application Programming Interface) を使用してシステム以外の監査イベントを生成しました | 通常の動作です。 |
| 577 578 |
特権サービスの呼び出し、特権オブジェクト操作 | これらは大量に発生するイベントですが、実行された操作の内容の説明がなく、対応するための十分な情報が得られません。 |
| 594 | オブジェクトへのハンドルの複製 | 通常の動作です。 |
| 595 | オブジェクトへの間接アクセスの取得 | 通常の動作です。 |
| 596 | データ保護マスタ キーのバックアップ作成 | 通常の動作です。 既定の設定では、90 日ごとに発生します。 |
| 597 | データ保護マスタ キーの回復 | 通常の動作です。 |
| 672 | Kerberos AS チケットの要求 | ログオン イベント 528 および 540 の監査詳細が既に収集されている場合は、追加情報がありません。 このイベントは、Kerberos TGT が付与されたことを記録します。実際のアクセスはサービス チケットが付与されるまで行われず、それについてはイベント 673 で監査されます。PATYPE が PKINIT の場合、スマート カード ログオンが行われたことを示します。 |
| 680 | アカウント ログオン | 他のイベントによって既に記録された活動。 |
| 697 | パスワード ポリシー確認 API が呼び出されました | 通常の動作です。 |
| 768 | フォレスト名前空間の衝突 | このイベントは、セキュリティには関係がありません。 |
| 769 770 771 |
信頼されたフォレスト情報の追加、削除、または変更 | 通常の動作です。 信頼そのものの追加、変更、または削除とこれらのイベントを混同しないでください。 |
| 832 833 834 835 836 837 838 839 840 841 |
Active Directory レプリケーションの各種イベント | これらのイベントは、セキュリティには関係がありません。 |
| ポリシーのパス | ポリシー | ポリシーの設定とコメント |
|---|---|---|
| ローカル ポリシー/監査ポリシー | アカウント ログオン イベントの監査 | このイベントでは、コンピュータに誰がアクセスしたかが記録されるため、すべてのコンピュータの成功の監査を有効にします。 失敗の監査は、注意して有効にします。ネットワーク アクセスが可能でも資格情報のない攻撃者が、コンピュータにこれらのイベントを記録させてコンピュータのリソースを消費することによってサービス拒否攻撃 (DoS) を開始する可能性があるからです。 成功の監査を有効にする場合にも注意が必要です。監査ログがいっぱいになったらコンピュータをシャットダウンする設定になっている場合は、この設定が Dos 攻撃に利用される可能性があるからです。 すべての管理者ログオンを他のすべての不審なエントリと関連付けます。 |
| ローカル ポリシー/監査ポリシー | アカウント管理の監査 | 成功と失敗の両方のイベントを有効にします。 成功の監査のすべてのエントリを管理者の承認と関連付けます。 失敗はすべて不審と見なす必要があります。 |
| ローカル ポリシー/監査ポリシー | ディレクトリ サービスのアクセスの監査 | 既定のドメイン コントローラ グループ ポリシーでは、この設定が既定で有効になっています。 Active Directory ユーザーとコンピュータ、またはActive Directory サービス インターフェイス エディタ (ADSI Edit) でシステム アクセス制御リスト (SACL) を使用することによって、機密性の高いディレクトリ オブジェクトの監査設定を構成します。 SACL の実装を計画し、運用環境に展開する前に、現実的なラボ環境で SACL をテストする必要があります。 このアプローチにより、大量のデータによってセキュリティ ログが過負荷になることを防ぎます。 |
| ローカル ポリシー/監査ポリシー | ログオン イベントの監査 | このイベントでは、コンピュータに誰がアクセスしたかが記録されるため、すべてのコンピュータの成功の監査を有効にします。 失敗の監査は、注意して有効にします。ネットワーク アクセスが可能でも資格情報のない攻撃者が、失敗を過剰に生成することによって DoS 状況を作り出す可能性があるからです。 |
| ローカル ポリシー/監査ポリシー | オブジェクト アクセスの監査 | 監査の量が膨大になる可能性があるため、この設定を有効にする場合は注意が必要です。 高価値フォルダにのみ SACL によって監査設定を構成し、注意を引く特定の種類のアクセスのみを監査します。 可能な場合は、読み取りアクセス イベントではなく、書き込みイベントのみを監査します。 |
| ローカル ポリシー/監査ポリシー | ポリシーの変更の監査 | 成功と失敗の両方の監査を有効にします。 すべての成功イベントを管理者の承認と相互に関連付けます。 |
| ローカル ポリシー/監査ポリシー | 特権使用の監査 | 特権使用の監査は有効にしないでください。この構成によって大量のイベントが生成されるからです。 |
| ローカル ポリシー/監査ポリシー | プロセス追跡の監査 | 脆弱なコンピュータでこの設定を有効にし、予期しないアプリケーション動作は、必要に応じてシステムを分離して直ちに調査します。 この設定は、Common Gateway Interface (CGI) Web サーバー、テスト システム、バッチ プロセスを実行するサーバー、または開発者用ワークステーションでは有効にしないでください。この設定によってイベント ログがいっぱいになる可能性があります。 |
| ローカル ポリシー/監査ポリシー | システム イベントの監査 | 成功と失敗の両方の監査を有効にします。 |
| ローカル ポリシー/ユーザー権利の割り当て | セキュリティ監査の生成 | この設定は、既定でローカル システム、ローカル サーバー、およびネットワーク サービスに割り当てられます。 この権利は、サービス アカウント以外のアカウントに適用しないでください。 攻撃者がこの設定を使用して、事実と異なるイベントや不正確なイベントをセキュリティ ログに作成する可能性があります。 |
| ローカル ポリシー/ユーザー権利の割り当て | 監査とセキュリティ ログの管理 | 管理者によるファイル、フォルダ、およびレジストリの監査設定の変更を制限するには、この設定を使用します。 監査設定の変更を許可されている管理者のみのセキュリティ グループを作成し、ローカル セキュリティ ポリシー設定からは管理者グループを削除する方法もあります。 つまり、セキュリティ グループのメンバのみが監査を構成できるようにします。 |
| ローカル ポリシー/セキュリティ オプション | 監査 : グローバル システム オブジェクトへのアクセスを監査する | この設定は、ミューテックス、セマフォ、MS-DOS デバイスなどの名前が付けられたシステム オブジェクトに SACL を追加します。 Windows Server 2003 の既定の設定では、このオプションが有効になっていません。 大量のイベントが発生することになるため、この設定は有効にしないでください。 |
| ローカル ポリシー/セキュリティ オプション | 監査 : バックアップと復元の特権の使用を監査する | バックアップおよび復元操作では、ACL を回避されるとデータ盗難の可能性が発生します。 膨大なイベントが発生することになるため、この設定は有効にしないでください。 |
| ローカル ポリシー/セキュリティ オプション | 監査 : セキュリティ イベントのログを記録できない場合に、直ちにシステムをシャットダウンする | この設定は、適用する前に慎重に検討し、高価値コンピュータについてのみ有効にします。攻撃者がこの設定を使用して DoS 攻撃を開始する可能性があるからです。 |
| イベント ログ | セキュリティ ログの最大サイズ | 推奨される設定は、計画されるイベントの量とセキュリティ ログの保存の設定によって異なります。 この設定は、64 KB 単位でのみ増やすことができます。イベントの平均サイズは 0.5 KB です。 大量のイベントが発生する環境では、この設定を 250 MB に設定できますが、すべてのイベント ログの合計サイズが 300 MB を超えることはできません。 |
| イベント ログ | ゲストによるセキュリティ ログへのアクセスを許可しない | Windows Server 2003 では、この設定が既定で有効になっています。変更しないでください。 |
| イベント ログ | セキュリティ ログの保存日数 | 選択した保存方法が [指定した日数を過ぎたら上書きする] の場合のみこの設定を有効にします。 イベントをポーリングするイベント関連付けシステムを使用する場合、ポーリング サイクルの失敗を考慮に入れ、日数がポーリング間隔の 3 倍以上になるように指定します。 |
| イベント ログ | セキュリティ ログの保存方法 | 高度なセキュリティ環境では、[イベントを上書きしない] 設定を有効にします。 この場合、[セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする] が有効になっている場合は特に、定期的にログを空にしてアーカイブする手順を確立します。 |