セキュリティの監視と攻撃検出

トピック

	はじめに
	定義
	中規模ビジネスの課題
	ソリューション
	概要
	付録 A : 不要なイベントを除外する
	付録 B : グループ ポリシー設定を実装する

はじめに

この文書は、中規模ビジネス セキュリティ ガイダンスの一部として提供されています。 Microsoft は、次の情報を得ることでさらにセキュリティが強化され、より生産性の高いコンピュータ環境が皆様の組織で実現されることを望んでいます。

要点

悪意のあるソフトウェアの脅威や事件の報道がここ何年もメディアを独占し注目を集めるケースが増えたため、セキュリティの問題への認識が高まり、企業はこの問題の広がりを防ぐために時間とリソースを投じるようになりました。 しかし、ビジネス インフラストラクチャにとっての最大の脅威は、ウイルスなど外側からの攻撃といった形をとるのではなく、内部ネットワーク自体に潜んでいる可能性があります。

ビジネス ネットワークの内部から開始された攻撃は、損害をもたらす可能性が非常に高くなります。特に、信頼ある地位につき、社内のすべてのネットワーク リソースにアクセスできる人物によって行われた場合は深刻です。 外部と内部の両方の脅威によるリスクを慎重に検証する場合、多くのビジネスでは、ネットワークを監視して発生源がどこであろうと攻撃を検出することができるシステムに関心が向かいます。

セキュリティの監視手段は、規制の制約を受けるビジネスにとってオプションの考慮事項ではなく、必須事項です。 この同じ規制によって、セキュリティの監視記録の保存およびアーカイブの期間と方法も制御される場合があります。 規制環境は常に変化し、ネットワークの保護、リソースにアクセスするユーザーの ID の追跡、個人情報の保護といった、規制対象のビジネスに対する要求は増える一方であるため、世界中のビジネスは効果的なセキュリティの監視ソリューションを確立するというさらに大きな要求を突きつけられています。

法規制に準拠する必要のない中規模ビジネスにとってもセキュリティの監視と攻撃検出が重要な問題となる理由はいくつかあります。 その理由の 1 つは、ビジネス インフラストラクチャに対する攻撃が成功した場合、どのような結果を招くかということです。 業務が中断するだけでなく、生産性の損失や金銭的な損失にもつながる可能性があります。 企業の評判も低下します。多くの場合、評判の回復には、攻撃によってもたらされたその他の損失の回復よりも時間を要します。

Microsoft® Windows® のセキュリティ ログ機能は、セキュリティの監視ソリューションの開始点として使用できます。 ただし、セキュリティ ログだけでは、インシデント対応の計画に十分な情報が得られません。 セキュリティ ログと、ログ情報を収集して照会する他のテクノロジとを組み合わせ、包括的なセキュリティの監視および攻撃検出ソリューションの中心部分を構成することができます。

セキュリティの監視および攻撃検出システムの主な目的は、悪意のある活動や操作上のエラーを示している可能性のあるネットワーク上の疑わしいイベントを特定することです。 ここでは、Windows ベースのネットワークにおけるこのようなシステムの必要性に対応するための計画を作成する方法について説明します。 また、このようなシステムを実装、管理、検証する方法についても説明します。

概要

この文書では、効果的なセキュリティの監視と攻撃検出ソリューションの設計と実装に必要となる重要な概念と問題を 4 つの主なセクションに分けて詳細に説明しています。 最初のセクションは、現在お読みになっている「はじめに」です。 残りのセクションは次のとおりです。

定義

このセクションには、この文書に示されているソリューションの生成および適用に関連するプロセスの理解に役立つ情報が記載されています。

中規模ビジネスの課題

このセクションでは、中規模ビジネスが直面する一般的な課題について、セキュリティの監視および攻撃検出システムと関連付けながら幅広く説明します。

ソリューション

このセクションでは、この文書に示されているソリューションを開発、実装、管理、および検証する方法について詳細に説明します。このセクションはさらに 2 つのサブセクションに分かれています。 「ソリューションを開発する」では、事前に必要な作業について説明し、計画手順を作成します。 「ソリューションを展開および管理する」では、セキュリティの監視および攻撃検出システムの展開、管理、および検証作業に役立つ情報を提供します。

対象読者

この文書では、中規模ビジネス、特に規制の制約により身元情報の保護とデータ アクセス制御を必要とする企業を対象に、プライバシーおよびセキュリティに関する問題について説明しています。 したがってこの文書は、技術部門の責任者や意思決定者から、会社のネットワークの計画、展開、運用、また特にセキュリティを担当する IT プロフェッショナルやテクノロジの実装担当者まで幅広い読者を対象とします。

この文書の一部は、ほとんどの技術部門の意思決定者にとって有用ですが、読者は特に、自社のネットワーク環境におけるセキュリティおよびリスクに関する問題に詳しく、Windows イベント ログ サービスの概念を理解している必要があります。この概念は、ここで説明する内容のすべてに応用されています。

ページのトップへ

定義

ここでは、MOF セキュリティ管理およびインシデント管理サービス管理機能 (SMF) に加え、Microsoft Operations Framework (MOF) プロセス モデルを使用しています。

特に、この文書に示されているソリューションでは、セキュリティの監視と攻撃検出の実現に、線形の展開アプローチではなく、継続プロセス アプローチを推奨しています。 具体的には、このソリューションには次の図のような手順が含まれている必要があります。

図 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 ベースの環境では、この機能がセキュリティの監視の基礎となります。 ただし、この情報を関連付ける追加のユーティリティまたはツールがなければ、情報は分散し、この機能を予防的に使用することは難しくなります。

図 2. イベント ビューアのセキュリティ ログ
画像を画面全体に表示

セキュリティ イベント ログ (上図) は、カスタム ファイル形式を使用してセキュリティ監視データを記録します。 これらの記録の一部はテキスト エディタで読み取ることができますが、これらのログに記録された情報をすべて表示するには、イベント ビューアなどの適切なプログラムが必要です。 セキュリティ イベント ログ ファイル (SecEvent.evt) は、%systemroot%\System32\config ディレクトリにあります。 イベント ログへのアクセスは常にイベント ログ サービスを介して管理され、イベント ログ サービスによって、各ログに対するアクセスが制御されます。  セキュリティ ログの既定のアクセス許可は、システム上の他のログと比較して非常に厳しくなっています。既定では、管理者のみがセキュリティ ログにアクセスすることができます。

セキュリティ イベント ログに記録されるイベントには、 成功の監査と失敗の監査の 2 種類があります。 成功の監査イベントは、ユーザー、サービス、またはプログラムが実行した操作が正常に完了したことを示します。 失敗の監査イベントは、正常に完了しなかった操作の詳細を示します。 失敗の監査イベントの例としてはユーザーのログオン失敗があり、ログオン監査が有効になっている場合は、セキュリティ イベント ログに記録されます。

コンピュータの構成\Windows の設定\ローカル ポリシーの下にある [監査ポリシー] グループ ポリシー設定で、セキュリティ ログにエントリを作成するイベントの種類を制御します。 監査ポリシーの設定は、[ローカル セキュリティ設定] コンソールから、またはサイト、ドメイン、組織単位 (OU) レベルで Active Directory のグループ ポリシーを介して構成することができます。

監査イベントを解釈する

監査イベントについては、この文書を通じてかなり詳細に説明します。したがって、監査イベントの構造と監査イベントに含まれる情報について基本的に理解することが重要です。

図 3. [イベントのプロパティ] ウィンドウ

イベントは、 イベント ヘッダー、イベントの説明、およびバイナリ データ セクションの 3 つの基本部分で構成されています。

イベント ヘッダーは、次の各フィールドで構成されています。

表 1. イベント ヘッダー

イベントの説明フィールドには、実際にもさまざまな情報が表示され、その内容はイベントによって異なります。 たとえば、上図のイベント ID 680 の例では、[エラー コード:] フィールドに "0xC000006A" と表示されています。これは、間違ったパスワードが入力されたことを示しています。 このフィールドには、イベントの種類ごとにそのイベント固有の情報が表示されます。

Windows セキュリティ イベント ログのイベントでは、イベント レコードのバイナリ データ セクションは使用されません。

技術的な問題

Windows セキュリティ イベント ログに基づくセキュリティの監査および攻撃検出システムを実装するには、次の問題に対処する必要があります。

ソリューションの計画

セキュリティの監査および攻撃検出システムを実装する前に、次の作業を実行する必要があります。

ストレージ要件に関する詳細については、後述の「フォレンシック分析を実装する」セクションを参照してください。

現在のセキュリティ監査設定を確認する

企業は、現在のセキュリティ監査とセキュリティ ログ ファイルの設定を確認し、この文書で推奨されている変更の基準にする必要があります。 このような見直しをソリューションの実装後も定期的に行い、次のような情報を入手する必要があります。

この文書の最後にある「付録 B: グループ ポリシー設定の実装」 を参考に、どの設定を記録する必要があるかを判断してください。 セキュリティ監査設定の詳細については、「Windows Server 2003 セキュリティ ガイド」を参照してください。

管理者の役割と通常のユーザーのタスクを評価する

効果的なセキュリティの監視ソリューションを実装するための重要な要素の 1 つは、管理者アカウントの所有者、およびその役割と責任を周知徹底することです。 たとえば、ほとんどのビジネスでは、管理者が Domain Admins グループに属し、新しいユーザー アカウントをドメイン内に作成できるようになっています。 ただし、インストールされているプロビジョニング システムのみが新しいアカウントを作成できることがビジネス ポリシーで指定されている場合があります。 このような場合、管理者アカウントがアカウント作成イベントを開始すると、すぐに調査するように警告されることがあり得ます。

ユーザー アカウント タスクの評価は通常、もっと簡単です。このようなアカウントがネットワーク リソースにアクセスすることは、管理者アカウントに比べて通常はるかに少ないからです。 たとえば、一般ユーザーは通常、ネットワークの境界にあるコンピュータのファイル システムにアクセスする必要はないため、このようなサーバーで一般ユーザーの活動を監視する必要はほとんどありません。

ビジネス ポリシーと手順を確認する

ビジネス プロセスと手順の確認は、管理者の役割と責任の評価に限定されるというわけではありませんが、かなり密接に対応しています。 この確認作業を構成する重要な要素には、たとえばユーザーの作成プロセスや変更管理プロセスの検証があります。 承認プロセスを行ったり、ネットワーク上で発生するすべてのイベントの監査記録を作成するメカニズムの検証は、何が認証された監査イベントとなり、何が侵入の試行であるとされるかの関係を定義するために不可欠です。

脆弱なシステムを特定する

脆弱なシステムとは、ネットワーク上で、外部の攻撃者が最初に探りを入れ、アクセスしようとするコンピュータおよびデバイスのことで、そこを突破口にその他の方法を試そうとします。 通常このようなコンピュータはネットワークの境界にありますが、内部のデバイスも攻撃に対して脆弱である場合があるため、完全に無視することはできません。

脆弱なシステムの包括的な見直しでは、次のことを確認する必要があります。

注   この確認プロセスは、境界にある脆弱なコンピュータに限らず行う必要があります。 セキュリティの点で望ましいのは、ネットワーク上のすべてのコンピュータにこれらのチェックを適用することです。

サービスが安全に実行されるように構成する方法については、「サービスおよびサービス アカウントのセキュリティ計画ガイド」を参照してください。

高価値資産のリストを作成する

ほとんどのビジネスでは、ネットワーク内にある高価値資産が既に特定されていると考えられますが、この情報が組織のポリシーの中で、各資産に適用する保護対策を詳細に文書化するという一定の形になっていない場合があります。 たとえば、ある企業はアクセス制御リスト (ACL) と暗号化を使用して、機密性の高い財務記録を安全に NTFS ファイル システムのパーティションに保存しているかもしれません。 しかし、このような記録は権限のないユーザーや管理者がアクセスしてはいけない保護対象のファイルとして組織のポリシーで明確に特定し、管理者とユーザーにこの制限を認識させる必要があります。

このようなファイルの保護に使用される ACL に変更が加えられる場合、特に所有権の変更が関係する場合はすべて調査する必要があります。このようなイベントは、正式な許可のない不正なファイル アクセスを示す可能性があるからです。 この種の所有権の変更は非常にまれであるため、高価値資産を特定し文書化した後は、このような変更の検出が簡単になるはずです。

機密性の高いアカウントや不審なアカウントを特定する

機密性の高いアカウントをすべて見直して、より高い監査レベルが必要なアカウントを特定する必要があります。 そのようなアカウントには、既定の管理者アカウント、Enterprise、Schema、または Domain Admins グループのすべてのメンバ、およびサービスによって使用されるすべてのアカウントが含まれます。

機密性の高いアカウントとは別に、リスクとして特定されている個人、または不審な活動への関与が疑われる個人が持つアカウントのセキュリティ監査レベルを調整することも重要です。 個人のユーザー アカウントの監査レベルを調整する方法については、後述の「ポリシー違反としきい値」セクションを参照してください。

認証されたプログラムのリストを作成する

ネットワークに関する情報を検出するために、攻撃者はそのネットワーク内にあるシステムでプログラムを実行する必要があります。 ネットワーク上で実行が許可されるプログラムを制限することによって、外部からの攻撃の脅威を大幅に軽減できます。 認証されたプログラムのリストを作成するには、現在ネットワーク環境で認証されているか、必要と特定されたすべてのプログラムについて監査を実行する必要があります。 このような監査で検出された不明なプログラムはすべて不審とみなし、直ちに調査する必要があります。 Microsoft Systems Management Server 2003 はソフトウェアの監査に役立ちますが、この製品がなくても可能です。

注   特定のコンピュータについては一部例外が必要な場合があります。たとえば開発者のワークステーションに存在する開発中の実行可能ファイルが、承認済みプログラムのリストに載っていない場合などです。 ただしより安全なアプローチとしては、開発およびテストを必ず仮想コンピュータ環境または分離された開発ネットワーク ドメインでのみ行うようにすることです。

ポリシー違反としきい値を検出する

ポリシー違反は、セキュリティ問題の中で最大のカテゴリを形成しているため、それに合った計画を作成する必要があります。 この種のインシデントには次のものがあります。

ポリシー違反の最も一般的な種類は、制限されたディレクトリの参照など、故意でないユーザー アクセス試行です。このような違反は通常、アクセス制限および適切に設計された権利ポリシーで対処できるため、重要度が最も低くなります。 管理ポリシーの違反は、管理者権限の性質上、故意か偶然かにかかわらず最も重大な種類のイベントです。

管理者アカウントの特権により、業務にその種の権限を必要とする個人に対して大幅なシステム アクセス権が与えられます。 ただしこの権限は、許可された範囲またはプロセス以外でも同様のシステム権限を使用することを認めるものではありません。 管理者アカウントでは、ユーザー アカウントの作成の有効化、ユーザー アカウントの変更、制限されたデータの表示、データ アクセス権の変更ができるため、そのような強力な権限に伴うリスクを軽減する方法を慎重に検討する必要があります。

脅威モデルを作成する

以上のように、脅威には監査によって軽減することができるものとできないものがあり、監査によって軽減できてもそれがコストに見合わない場合もあります。 理解すべき主な点は、すべての脆弱性がネットワークにとって脅威となるわけではないということです。 どの部分の脆弱性を軽減することが可能であるか、またはそれが必要であるかを判断するには、脅威モデル作成の原則を適用することが役立つ場合があります。

脅威モデルの作成は、脅威と脆弱性を特定することにより、特定の環境についてより効率的に対策を立てるためのエンジニアリング技術です。 このプロセスには通常、次の 3 つの基本手順があります。

より端的に言えば、攻撃者の観点からネットワーク環境を検証すると、ネットワークにアクセスしようとする人物にとって最も魅力的なターゲットは何か、そのようなターゲットへの攻撃が成功するにはどのような条件を満たす必要があるのかが把握されます。 格好の脆弱なターゲットを特定したら、環境を検証して、既存の保護手段が攻撃の条件にどう影響するかを判断することができます。 このプロセスにより、関連する脅威が明らかになり、それらの脅威が示すリスクのレベルに基づいて脅威をランク付けすることができます。また、その脅威に対して最も有効な解決策をもたらす改善活動は何か、リスクの軽減が他の領域にプラスに影響するのかマイナスに影響するのか (これがその改善活動の価値に影響します) も明らかになります。

したがって、これらの要件に基づいて、ネットワークの脅威モデルの作成プロセスを成功させる具体的な手順が実際にいくつかあります。

改善計画が実施された後であっても、脅威モデルの作成手法は反復的なプロセスであるため、常に再評価しながら定期的に実行し、セキュリティ措置が可能な限り効果的で包括的なものになるようにする必要があります。

経歴調査および再調査

ほとんどのビジネスでは、雇用の条件として、内定者に関する何らかの経歴調査を既に実行していますが、雇用後は調査しません。 企業は、制限された情報にアクセスできる重要な地位の場合は特に、従業員の雇用期間中も定期的に経歴調査を実行することを検討する必要があります。

コンピュータの使用ポリシーに関する合意

コンピュータまたはネットワークの使用に関する合意は、会社の資産の使用方法を従業員に知らせるためだけでなく、ネットワーク活動およびコンピュータの使用を監視するためのポリシーと、これらのポリシーに違反しようとした場合に起こりうる結果を知らせるためにも重要です。

使用ポリシー ステートメントは、これらの事項を明確に定義し、合意の印として従業員の署名を必要としている場合、法律文書としても機能します。 内部セキュリティの監視ポリシーと、会社の資産を使用する際に許容される範囲について従業員が十分に認識していたという証拠がなければ、従業員に不正な行為があった場合その従業員を起訴することはますます難しくなっています。

また、会社のネットワーク上のすべてのアクセス ポイントで、アクセスおよび不正使用の警告を発行し、アクセスしようとするすべてのユーザーに、それがプライベート ネットワークであることと、不正なアクセスは禁止されており、行った場合は起訴されることを通知することも重要です。 たとえば、Windows オペレーティング システムには、ログオン試行イベント時に警告メッセージを表示する機能があり、これを使用すると、保護された企業のリソースにアクセスしようとしていること、不正なアクセスは禁止されていることをユーザーに通知することができます。

この種の文書の正確な文言や使用に関する法的な問題はここでは説明の対象外ですが、こういった文書やポリシーの必要性に言及することは重要です。 こういった使用やアクセスに関するステートメントの例はインターネット上に多数存在しますが、これらの資料を準備する際は必ず、資格を持つ法律顧問に相談してください。地域に固有の法律問題や国際法にかかわる問題が多くあるため、慎重に検討する必要があります。

職務の分離

システムのさまざまな機能がネットワーク全体でセキュリティ、パフォーマンス、および可用性といった目的別にセグメント化されているように、IT セキュリティ部門の配属要件を作成する場合は、職務の重複と分離を規定することが重要です。

機密性の高いデータおよびシステムに対するアクセスまたは制御を伴う重要な役割は、可能かつ妥当である限り、複数のスタッフに割り当てる必要があります。これは、スタッフが欠けた場合の知識の喪失に伴う問題を防止するためだけでなく、社内で妨害活動があった場合のセキュリティ機能という意味でもあります。 たとえば、管理パスワードを知っているスタッフが 1 人だけで、そのスタッフが管理パスワードを誰にも教えずにいなくなった場合、事態の回復は困難です。

役割を重複させることに加えて、重要な役割については役割を分離することも重要です (特にセキュリティの監視)。 ネットワーク管理者がセキュリティ監査情報の確認も担当することがないようにします。また、セキュリティ スタッフが管理者と同等の管理者権限を持つべきではありません。 場合によっては、職務の分離をさらに適用するために、部門の情報を管理スタッフから隔離する必要もあります。 たとえば、財務や人事など機密性の高い情報を保護するために、組織単位が独自のシステムまたは管理者アカウントを持つ例もあります。

注   このように職務を分離しても、管理者アカウントの所有者が抜け道を見つけ出すことを阻止できないかもしれませんが、少なくとも、職務の分離の原則を使用する管理権限について、正しい使用を規定するガイドラインを確立することが重要です。

セキュリティの監視機能を検証する

セキュリティの監視ソリューションを実装する前に、そのようなプログラムの定期的なテストを入念に計画する必要があります。 初期テストは、セキュリティの監視ソリューションを検証するために重要ですが、セキュリティ環境は常に変化するため、テストのスケジュールを作成して定期的に実行することが重要です。

侵入の試行や管理者特権のテスト使用をテストに盛り込んで、そのような活動の検出にソリューションが有効かどうかを判断することができます。 ただし、セキュリティ技術や攻撃プロファイルにおける最新の変更内容を調査して、テストを変更する必要があるかどうかを判断することも重要です。 攻撃者はセキュリティの実装に適応するため、ビジネス ネットワークにとっての脅威は常に変化しています。したがって、防御および監視技術は常に進化して有効性を維持する必要があります。

プロセスを確立する

認証されたイベントと不正なセキュリティ イベントを区別するには、変更管理プロセスと問題管理プロセスの確立と義務付けを計画する必要があります。 このような計画により、セキュリティ ログ情報と相互に関連付けることができる詳細な紙面記録が得られます。 ほとんどの企業では、問題の追跡はヘルプ デスク チケットやその他の問題追跡プロセスという形で行うのが一般的ですが、変更管理はしばしば軽視されます。 変更管理は必須のメカニズムであり、動向を追跡して問題のあるシステムまたはアプリケーションを突き止めるためだけでなく、重要なセキュリティ メカニズムとしても使用できます。

変更管理プロセスは、予防的な手順として実行する必要があり、事後対応的な変更は、問題管理プロセスを使用する場合に限定する必要があります。 変更管理プロセスでは、変更の前に必ず提出または承認を要求し、次のような詳細が含まれている必要があります。

確立する必要のあるもう 1 つのプロセスは、ユーザーの追加/変更/削除手順を介したユーザー プロビジョニング プロセスです。このプロセスもまた、監査記録を作成して不正なアカウント変更を防止します。 このようなプロセスを確立する前に、現在あるユーザー アカウントのセキュリティ監査を実行してこれらのアカウントの有効性を確認し、このリストの変更に応じて定期的に検証することが重要です。

Microsoft Identity Integration Server (MIIS) 2003 などの自動ユーザー プロビジョニングおよび ID 管理ソリューションを使用すると、アカウント変更やそのような活動の背後にあるプロセスが自動化されるため、さらに役立ちます。 このようなソリューションを使用する場合、管理者アカウントが持つ新規アカウントの作成権限はそのまま残りますが、アカウントは確立されたプロセスによって作成されるようになるため、管理者がアカウントを作成する必要はなくなります。 したがって、イベント 624 など、アカウントの作成に関連するイベントはすべて、MIIS 2003 または自動プロビジョニングに使用されるその他の確立されたサービス アカウントにのみ関連付けられる必要があります。

ビジネス ネットワークに対する外部からの脅威が絶えずメディアで報道されていますが、ネットワークおよび企業データは、不適切な構成や手続き上のミスによる損失または漏えいに対してはるかに脆弱であることが経験からわかっています。 外部と内部のすべての脅威から保護することが重要であり、外部の脅威からの企業の保護を支援するベンダは多数ありますが、企業のネットワークおよびセキュリティの担当者のミスを防止するパッケージを企業に販売できるベンダはありません。 そのようなリスクを軽減するための最善の方法は、ネットワーク上で実行される変更に関する適切なプロセスおよび手順を実装して実施することです。

セキュリティ対応を定義する

セキュリティ違反によって発生する可能性のある損害を抑えるには、明確で適切な対応計画を作成し、インシデントに対応するためのプロセスを確立することが重要です。 インシデント レポート、迅速に対応するチームの編成、緊急対応の手順などが良い例です。 インシデント対応のスピードと効果によって、組織のセキュリティ プロファイルが向上し、侵入の試行によって発生する可能性のある、実際に感じられる損害が限定的なものになります。

確立されたセキュリティ対応プロセスを構成すると、実際のインシデントが引き起こす可能性のある損害を限定するのに役立つだけでなく、インシデントによって、セキュリティ違反には組織的かつ迅速な対応がなされることがスタッフおよびその他の個人に周知されるため、抑止力にもなります。

人事

CERT および米国シークレット サービスによって行われた研究によると、企業が従業員の行動の変化や脅威により注意を払い、それに対する措置をとれば、内部の人間による攻撃の多くは回避することができます。 ビジネスにおける最も価値のあるセキュリティ リソースはおそらく、従業員自身です。スタッフが不満を持っている場合そのことに気付いたり、訪問者の行動に不審な点がある場合に適切な担当者に警告するのは従業員だからです。 実際、外部のセキュリティ監査グループが最初にとる行動の 1 つは、紙に書かれたパスワード情報を探す、セキュリティ保護されていないデバイスを見つける、または内部ネットワークに直接接続することによって侵入を試行する、などの目的で「歩き回る」ことです。

企業のスタッフは、内部および外部の脅威に対する重要な保護レイヤとしての役割を果たすことができます。 同僚の気がかりな行動について話せるようにオープン ドア ポリシーを奨励したり、サポート担当者にトレーニングを実施して、コンピュータの異常な動作についてスタッフから受けた報告はすべて真面目に受け取るように教育すると、侵入の試行やマルウェアのインシデントを軽減できます。 社内トレーニングは、報告する必要のあるコンピュータの動作の種類を見分ける方法を従業員に教える手段としても重要です。 トレーニングは、ソーシャル エンジニアリング攻撃の回避という点で予防策にもなります。

セキュリティ ポリシー違反を監査イベントに関連付ける

セキュリティ イベント情報の関連付けでは、複数のシステムからセキュリティ イベントを収集し、このデータを安全な集中管理場所に保存します。 セキュリティ情報が関連付けられたら、適切な担当者がこの中央リポジトリを分析して違反や外部からの攻撃を特定することができます。 このリポジトリは、フォレンシック分析のためだけでなく、攻撃を検出し脆弱性に対処するツールとしても重要です。 この目的のために提供されているサードパーティ ソリューションはいくつかありますが、次のマイクロソフト製品およびツールでは、セキュリティ イベント ログおよびその他のセキュリティ監視情報を中央リポジトリに関連付けることによってこのニーズに対処できます。

EventCombMT

EventCombMT (マルチスレッド型) は、「Windows Server 2003 セキュリティ ガイド」のコンポーネントです。このツールでは、複数のコンピュータ上にあるイベント ログからイベントを収集して解析できます。 このツールは、マルチスレッド型のアプリケーションとして実行され、ユーザーはイベント ログのスキャン時に次のようなパラメータをいくつでも指定できます。

図 4. EventCombMT
画像を画面全体に表示

EventCombMT には、次のイベントの検索機能を提供するアカウント ロックアウト (上図参照) など、特定の検索カテゴリがいくつか組み込まれています。

セキュリティ ログ ファイルにはないもう 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 準拠データベースに情報を保存できます。

次のような特定の活動および一連のイベントは、厳重に監視する必要があります。

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 メッセージのスクリーニング ログのキャプチャ機能が含まれます。 これらのログは、ビルトインのリアルタイム ログ ビューア (次のスクリーン ショットを参照) を使用して、またはダッシュボードを監視して、リアルタイム ベースでフィルタリング、照会、または監視することができます。

図 5. Microsoft ISA Server 2004 リアルタイム ログ ビューア
画像を画面全体に表示

ISA Server には、ビルトインのログ機能以外にも、電子メール、イベント ログ エントリ、または開始/停止サービスによって警告を発行できる警告機能があります。 不審な活動をイベント ログ エントリに記録する機能は、この文書の目的では特に有効です。 この機能を使用すると、予想される攻撃の情報を他の監査イベント ログ データと共に集中管理場所に記録および保管することができます。

このログおよび警告機能に加えて、ISA Server で有効にすることができるビルトインの侵入検出ツールもあります。 これらの基本的な侵入検出サービス (IDS) は、Internet Security Systems からライセンス供与されたもので、IP パケット フィルタ、DNS アプリケーション フィルタ、および POP アプリケーション フィルタを含みます。 これらのサービスでは、多くの一般的な悪用を検出できます。

ISA Server の侵入検出機能では、イベントをログに記録し、潜在的な攻撃が検出された場合に警告を生成することができます。 また、サービスや不審な接続を終了することもできます。 検出できる攻撃プロファイルには、次のものがあります。

いずれの場合も、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

注   一部の規制対象業界の慣習 (たとえば、医療記録を扱うビジネスの慣習など) では、規定された保存期間ではなく、「～を超えて保存しない」という表現で期間の制限を定めています。

考慮すべきオプションの 1 つは、オンライン データベースを使用してオンライン フォレンシック分析データを保存し、古いイベントから順に、コンマで区切った (コンマ区切り形式または CSV とも呼ばれます) テキストなど、より圧縮性の高い形式でオフライン ストレージにアーカイブすることです。 必要であれば、CSV ファイルを再びオンライン データベースにインポートして分析に使用することができます。

どんなソリューションを選択した場合でも、最新のイベントを迅速に調査するためのビジネス要件を満たし、さらに必要に応じて古いイベントを復元する機能があることを確認してください。 企業内のセキュリティ インシデントの履歴と利用可能なリソースのリストを参考にして、オンラインおよびオフライン ストレージのデータ保存期間の組み合わせが最適な計画を作成する必要があります。 可能な場合は、十分な容量のデータベースで必要なレポートを実行してイベント収集システムをテストし、レポートが短時間で実行され実用的な情報が得られることを確認してください。

また、フォレンシック分析データのセキュリティも考慮する必要があります。この情報へのアクセスが必要になることはめったにないからです。 アクセスが必要な場合は、選ばれた数名の信頼できるセキュリティ担当者のみにアクセスを許可します。 この情報への管理者アクセスは、セキュリティ監視がより強化されている確立された変更管理プロセス内で厳しく制限する必要があります。 担当者以外は誰も、この情報へのアクセス、情報収集の妨害、または情報の変更ができないようにしなくてはなりません。

技術的な問題

フォレンシック分析用のセキュリティの監視ソリューションの計画では、膨大な数のイベントを安全かつ確実に収集し保存するための慎重なプロビジョニングが必要です。 セキュリティの監視の要件は、他のソリューションのシナリオで詳細に説明されているものと同様ですが、データベース ストレージ用のはるかに多くのリソースと、非常に効率的なデータ管理を必要とします。

次の技術的な課題を考慮する必要があります。

これらの課題は、セキュリティの監視に特有のものではありません。データベース管理者は、オンライン トランザクション処理 (OLTP) データベースなどの他のアプリケーションについても同様の問題を抱えているからです。 ただし、OLTP などの従来の他のデータベース アプリケーションと異なり、フォレンシック分析データベースは、読み取りよりもはるかに大量の書き込みに対応する必要があります。

要件

効果的なフォレンシック分析プログラムを計画するには、次の要件を満たす必要があります。

フォレンシック分析ソリューションでは、ビジネス環境の要件、機能、および規制の制約を考慮に入れる必要があります。これらに関しては組織によってそれぞれ異なるからです。

ソリューションを展開および管理する

攻撃を特定し、プロファイルし、対応する能力は、あらゆるセキュリティの監視および攻撃検出ソリューションの基本的な目標です。 したがって、このセクションの大部分では、イベント ログで見つかった場合に進行中の攻撃を示す可能性のある関連イベントについて詳細に説明します。 これを念頭に置いたうえで、セキュリティの監視および攻撃検出計画は次の要件を満たす必要があります。

ここで説明するソリューションでは、これらの 3 つの各要件に対して同様のコンポーネントを使用します。 フォレンシック分析機能の実装には、後述する追加の要件があります。

セキュリティの監視と攻撃検出

セキュリティの監視および攻撃検出ソリューションの概念では、次の領域についての適切なレベルのセキュリティ監査の計画が必要です。

セキュリティの監視および攻撃検出システムは、セキュリティ イベント ログから情報を収集し、この情報を中央の場所で照合します。 その後セキュリティ監査担当者は、不審な活動がないかこのデータを分析できます。 さらにこの情報は、後日必要が生じた場合にフォレンシック分析を行うために保存およびアーカイブすることもできます。

このソリューションの主要なコンポーネントは、Microsoft Windows 2003 Service Pack 1 (SP1) および Microsoft Windows XP Service Pack 2 (SP2) のユーザーごとの監査と呼ばれる機能を構成する機能です。 ユーザーごとの監査では、特定のユーザー アカウントに対して異なる監査レベルを指定することができ、それにより、機密性の高いアカウントや不審なアカウントに関するより高いレベルの監査詳細を得ることができます。

ソリューションの必要条件

このセキュリティの監視および攻撃検出ソリューションを構成するには、次のような必要条件があります。

注   企業の境界にあるコンピュータがドメインに属していない場合、これらのコンピュータを Active Directory グループ ポリシー設定で構成することはできません。 ただし、そのようなシステムの構成には、ローカル ポリシーおよびテンプレートを使用できます。

この文書では、攻撃の特有のパターンを特定することに重点を置いています。考えられるソリューションをいくつか挙げてはいますが、セキュリティ イベントの照合に使用する特定のテクノロジの推奨は行っていません。 適切な収集メカニズムに関する決定を行った後は、ここで挙げるイベントおよびイベントのシーケンスを使用して、不審な動作を特定するためのクエリと警告を設計することができます。

ポリシー違反としきい値

Microsoft Windows Server 2003 および Microsoft Windows XP SP2 の新機能では、個々のユーザー アカウントの監査レベルを選択することができます。 たとえば、すべてのユーザーについてログオンおよびログオフ活動のみを報告し、同時にある特定のユーザーについてはすべての活動を監査するように監査レベルを設定することができます。 ユーザーごとに選択可能な監査は、特定のアカウントを特定の活動の監査生成から除外することによって、セキュリティ ログ内のイベントの量を減らすためにも使用できます。 この機能を使用して監査できるのは、ユーザー アカウントのみです。セキュリティ グループおよび配布グループは、この方法で監査することはできません。 Administrators ローカル グループに属するアカウントは、ユーザーごとに選択可能な監査メカニズムを使用して監査から除外することはできません。

Windows Server 2003 および Windows XP SP2 で、選択可能な監査を行うための、ユーザーごとの監査ポリシーの設定に使用するコマンドライン ユーティリティは、Auditusr.exe です。選択可能な監査で有効なカテゴリは次のとおりです。

コマンドラインから Aauditusr.exe をパラメータを指定せずに実行すると、選択可能な監査の現在の設定が表示されます。これは最初は空白のままになっています。 選択可能な監査のパラメータを入力する方法は 2 とおりあります。ユーザーごとに 1 つ、コマンドライン パラメータとして手動で入力する方法と、ユーザーごとの監査設定ファイルをインポートすることによって複数のパラメータを入力する方法です。

Audituser.exe は、次のように使用します。

Audituser.exe /<パラメータ> <ユーザー アカウント>:”<カテゴリ>”

(または、コンマで区切られたカテゴリのリスト)

たとえば、LocalUser というアカウントについてシステム イベントとログオン/ログオフ イベントの失敗の監査を有効にするには、次のコマンドラインを入力します。

Audituser /if LocalUser:”System Event”,”Logon/Logoff”

コマンドラインでは、次のパラメータを使用できます。

ユーザーごとの監査の設定ファイルはテキストファイルで、次の図のような形式を使用します。

図 6. Auditusr.exe のインポート ファイルの例

注   正常にインポートするには、インポート ファイルの最初の行が図のように “Auditusr 1.0” となっている必要があります。

上図に示されている監査の設定ファイルをインポートするには、次のコマンドを使用します。

Audituser /i path\audit.txt

このユーティリティは、監査ログ情報のしきい値の設定に役立てることができます。しきい値を設定することで、ストレージ要件を軽減し、侵入の試行が検出される可能性を高めることができます。

セキュリティ ポリシー違反と監査イベントの相関関係

このセクションでは、ポリシー違反の発生源が外部ソースか内部ソースかを区別して扱いませんが、内部のポリシー違反は外部が発生源となる攻撃と同じくらいビジネスにとって致命的となる可能性があることを認識することが重要です。 前述したように、悪意のある攻撃のうちかなりの割合が内部ソースによって実行されたもので、この割合には、確立された手順の範囲外で上位の特権を誤用したことによって発生した偶発的な損害は含まれていません。

内部ソースによる上位の特権の偶発的または意図的な誤用にはリスクを避けるため、これらの特権の適切な使用に関してポリシーと手順を確立することと、相関する監査記録を作成することが重要です。 変更管理プロセスと文書化ポリシーを設定したら、承認されたイベントおよび未承認のイベントそれぞれと監査情報とを関連付ける相関関係を作成し、それによって企業内の不審な動作を容易に検出できるようになります。 このセクションでは、この相関関係を作成するため、追跡できるさまざまなイベントの種類と、それらをポリシーおよびプロセスに適用する方法について説明します。

許可されていないコンピュータへのアクセス

管理/サポート スタッフが、リモート システムとの接続や管理にターミナル サービスなどのリモート管理機能を使用する機会は増えてきています。 これらのシステムの対話型ログオンの試行は監視する必要があり、接続試行ごとに有効性を確認する必要があります。 このような確認では、次の作業を実行する必要があります。

高価値資産の監視には特に注意する必要があります。 そのような重要なリソースは特定のサーバーに配置し、厳しい監査の監視設定およびアクセス制御設定を適用して構成する必要があります。

次の表は、ログオン監査イベントのリストです。これらのイベントが高価値資産のシステムで発生した場合、許可されたアカウントのリストと比較します。

表 3. コンピュータの不正使用イベント

トロイの木馬、Rootkit、マルウェア

イベント ID 592 は、新しいプロセスが開始された場合に必ず作成されるため、トロイの木馬、Rootkit、およびその他のマルウェアの発生の検出に特に役立ちます。 このイベントが発生し、イメージ ファイル名が承認済みプログラムのリストにあるプロセスと一致しない場合は必ず、直ちに調査を行う必要があります。

トロイの木馬とキーロガーは特定が比較的簡単ですが、Rootkit は検出が特に困難です。 Rootkit を検出するには、開始してすぐに終了する不明なプログラムを特定します。 しかし、Rootkit が開始されると、オペレーティング システムには Rootkit を検出する方法がないため、それ以上イベントを生成しません。

その他のマルウェアの場合は電子メールの添付ファイルや Web サイトからの感染といった形をとる可能性があり、実行中のアカウントに新しいプログラムを起動する権限がない場合は、特権を昇格させようとします。 このような場合、許可されていないソフトウェアから失敗イベントが作成されるため、このイベントを調査する必要があります。特に次のイベントが発生した場合に注意が必要です。

表 4. イベント 592

ファイルのアクセス許可の変更によるリソースへのアクセス

管理者特権を使用すると、データの所有者を変更し、そのデータの読み取りアクセス許可リストにアカウントを追加することによって、通常はアクセスが拒否されるファイルにアクセスすることができます。 また、Windows Server 2003 では、所有者とアクセス許可を元の設定に戻すことによってそのような活動を隠蔽することもできます。

この点で、高価値資産およびデータの特定は重要です。平均的な中規模ビジネスのネットワーク上にあるすべてのファイルに対してオブジェクト アクセスの監査を実装することは、毎日膨大な量のアクセス イベントが発生することを考えると、生産的とは言えないからです。 オブジェクト アクセスの監査は、機密性の高いファイルおよびフォルダに対して行う必要があります。ACL のエントリは、不正アクセスの試行に対する防御策としては不十分です。

不正な活動を効率的に検出するには、すべての高価値ファイルについて次の要素を簡単に特定できなければなりません。

ビルトインのイベント ビューアには、この情報を特定するための十分なフィルタ設定がありません。 したがって、この分析を実行するには、EventCombMT または他の何らかのメカニズムを使用する必要があります。

次の表に示すオブジェクト アクセス�