次の方法で共有


セキュリティの監視および攻撃検出計画ガイド

第 4 章 - ソリューションの設計

最終更新日: 2006年2月1日

ダウンロード

セキュリティの監視および攻撃検出計画ガイド (英語)

トピック

はじめに
ソリューションの要素
ポリシー違反の検出
外部からの攻撃の特定
フォレンシック分析の実装
まとめ

はじめに

セキュリティの監視および攻撃検出システムの計画を作成する最後の手順として、ソリューション要件に対処するソリューションの設計を行います。このソリューションの設計では、ここまでに定義した次の 3 つのシナリオの問題を対象にする必要があります。

  • ポリシー違反の検出

  • 外部からの攻撃の特定

  • フォレンシック分析の実装

ソリューションの主な目的は攻撃の特定とプロファイリングにあるので、この章の大部分を使って、攻撃が進行中であることを示す可能性のあるイベントについて説明します。これらの攻撃の特徴は、第 3 章「問題点と要件」で説明した各シナリオのセキュリティ上の問題点に結び付けられます。このソリューションの正確な実装は、各組織のネットワーク トポロジによって異なります。

ページのトップへ

ソリューションの要素

ソリューションの設計では、3 つのシナリオすべてに同じ基本コンポーネントを使用します。フォレンシック分析では、オンライン、オフライン、およびアーカイブの保管場所として追加のリソースが必要ですが、それ以外のソリューション アーキテクチャは他の 2 つのシナリオの実装と大きな違いはありません。

ソリューションの概念

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

  • ユーザーの作成やユーザーのグループへの追加などのアカウント管理操作

  • 保護されたファイルへのアクセス

  • セキュリティ ポリシーの変更

  • 信頼関係の作成と削除

  • ユーザーの権利の使用

  • システムの再起動とシステム時刻の変更

  • レジストリ設定の変更

  • 不明なプログラムの実行

セキュリティの監視および攻撃検出システムでは、主としてセキュリティ イベント ログから情報を収集し、この情報を照合します。管理者は、疑わしい行動についてこのデータを分析できます。また、後でフォレンシック分析を行うために、情報を格納および保管できます。

このソリューションの主要コンポーネントは、ユーザー単位に監査を構成できる機能です。このような機能は、Service Pack 1 (SP1) を適用した Microsoft® Windows Server™ 2003 および Service Pack 2 (SP2) を適用した Microsoft Windows® XP に含まれています。ユーザー単位の監査により、特定のユーザー アカウントに異なる監査レベルを指定できます。疑わしい個人や機密性の高いアカウントには高い監査レベルを指定します。

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

セキュリティの監査および攻撃検出システムを構成するためのソリューションの必要条件は次のとおりです。

  • サーバーでは Windows Server 2003 SP1 以降が実行されていて、Active Directory® ディレクトリ サービス ドメインに所属している必要があります。

  • クライアント コンピュータでは Windows XP Service Pack 2 以降が実行されていて、Active Directory ドメインのメンバである必要があります。

注 : 境界ネットワーク内のコンピュータは、ドメインのメンバではなく、ワークグループのメンバになる可能性があるので、このようなコンピュータは Active Directory グループ ポリシー設定を使って構成することはできません。ただし、ローカル ポリシーやテンプレート ファイルを使用して、このようなコンピュータを構成できます。

このガイドでは、セキュリティ イベントの照合の一元管理に特定のテクノロジを推奨することではなく、攻撃の特徴ある形跡を特定することに重点を置いています。適切な収集メカニズムを決定した後に、この章で説明するイベントやイベント シーケンスを使用して、攻撃を特定するクエリを作成できます。

ソリューションの計画

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

  • 現在のセキュリティ監査設定のレビュー

  • 管理者の役割とユーザーのタスクの査定

  • 組織のポリシーと手順のレビュー

  • 脆弱なコンピュータの特定

  • 高価な資産の一覧

  • 機密性の高いアカウントや疑わしいアカウントの特定

  • 認証済みのプログラムの一覧

詳細については、この章の「フォレンシック分析の実装」を参照してください。

現在のセキュリティ監査設定のレビュー

この章で推奨する変更のベースラインを用意するために、現在のセキュリティ監査設定とセキュリティ イベント ログ ファイルの設定をレビューする必要があります。このレビューでは、次の情報を入手します。

  • 現在効果のあるセキュリティ監査設定

  • このような設定を適用するレベル (ローカル コンピュータ、サイト、ドメイン、または組織単位)

  • 現在のログ ファイルの設定 (サイズ、ログの最大サイズに達したときの動作)

  • 適用する追加のセキュリティ監査設定 (たとえば、バックアップと復元の特権の使用)

記録する必要のある設定を特定するためのチェック リストとして、付録 B 「グループ ポリシー設定の実装」を使用できます。セキュリティ監査設定の詳細については、「Windows Server 2003 セキュリティ ガイド」 (https://www.microsoft.com/download/details.aspx?FamilyID=66994ba0-c977-41c8-a698-ef6edb9a4b52&DisplayLang=ja) を参照してください。

管理者の役割とユーザーのタスクの査定

効果的なセキュリティの監視を実装するには、だれが管理者で、その管理者はどのような役割を担っているかを確認しておくことが重要です。たとえば、多くの組織では、管理者を Domain Admins グループに含めています。ドメイン管理者は、ドメインに新しいユーザー アカウントを作成できます。ただし、組織のポリシーとして、プロビジョニング システムだけが新しいアカウントを作成できるように指定できます。このようにしておけば、管理者がユーザー アカウントを作成した場合、すぐに注意を促すことができます。

ユーザーは管理者に比べてアクセスできるネットワーク リソースが極めて少ないので、ユーザーのタスクを査定するのは簡単です。たとえば、ユーザーは一般的には境界ネットワーク内のコンピュータのファイル システムにはアクセスしないので、このようなサーバーでユーザーの行動を監視することにはあまり意味がありません。

組織のポリシーと手順のレビュー

組織の手順のレビューは、管理者の役割や責務を査定することに対応しています。たとえば、ユーザーをグループに追加するプロセスは、注意深くレビューする必要があります。各部門で変更を要請する手順を確立し、このような要請を実装する方法を定義する必要があります。承認済みのプロセス以外でユーザーがグループに追加された場合は調査が必要です。

脆弱なコンピュータの特定

脆弱なコンピュータは、外部からの攻撃者が組織のネットワーク内で最初にアクセスを試みる可能性の高いコンピュータになります。多くの攻撃シナリオでは、このようなコンピュータが境界ネットワーク内に含まれています。

すべての脆弱なコンピュータの包括的なレビューを行い、次のことを確認する必要があります。

  • Service Pack とセキュリティの更新がすべて適用されていること

  • 不要なサービスやユーザー アカウントが無効になっていること

  • 可能な場合は Local Service アカウントまたは Network Service アカウントでサービスが実行されるように構成されていること

  • ユーザー アカウントの資格情報 (特に、管理権限のあるアカウント) で実行されるサービスは、間違いなくユーザー アカウントが必要かどうかをチェックすること

  • セキュリティの高いコンピュータ ポリシー テンプレートが適用されていること

注 : このようなレビューは、脆弱なコンピュータだけに必要なわけではありません。適切なセキュリティの実践方法として、ネットワーク上のすべてのコンピュータに対してこのようなチェックを行うことをお勧めします。

サービスを安全に実行する方法の詳細については、「The Service and Service Accounts Security Planning Guide」 (https://go.microsoft.com/fwlink/?LinkId=41311) (英語) を参照してください。

高価な資産の一覧

既に高価な資産を識別しているかもしれませんが、このような資産や資産ごとの保護を文書化して、組織のポリシーの一環としてこれを形式化します。たとえば、企業の財務記録を NTFS ファイル システム パーティションに安全に保管するために、アクセス制御リスト (ACL) や暗号化を使用できます。ただし、組織のポリシーでは、このような記録を未承認のユーザーや管理者がアクセスしてはいけない保護されたファイルとして特定する必要があります。そして、管理者とユーザーがこの制限を認識する必要があります。

次に、このような保護されたファイルの ACL の変更を調査する必要があります。所有権の変更は特に重要です。所有権の変更は、適切な承認なしに攻撃者がファイルにアクセスを試みていることを示す場合があります。所有権の変更はそれほど頻繁には行われないので、検出は容易です。

機密性の高いアカウントや疑わしいアカウントの特定

機密性の高いアカウントをすべてレビューし、高い監査レベルが必要なアカウントを特定します。このようなアカウントには、既定の Administrator アカウント、Enterprise グループ、Schema グループ、Domain Admins グループに所属するアカウント、サービスがログオンに使用するアカウントなどがあります。

個人による疑わしい行動に気付いたときは、セキュリティ ポリシーの要件でその個人に高い監査レベルを要求します。ユーザー アカウントの監査レベルの変更方法の詳細については、この章の「選択的監査を有効にする」を参照してください。

認証済みのプログラムの一覧

攻撃者がネットワークに関する情報を発見するにはプログラムを実行する必要があるので、ネットワークで実行できるプログラムを制限すれば、外部からの攻撃の脅威を大幅に軽減できます。承認済みのすべてのプログラムの監査を実行し、不明なプログラムは疑わしいと見なします。Microsoft Systems Management Server 2003 では、大規模エンタープライズ環境のソフトウェア監査を実行できます。

注 : 場合によっては、開発者のワークステーションなど、特定のコンピュータを例外として扱う必要があります。開発者が作成している実行可能ファイルは、承認済みのプログラムの一覧には載っていないためです。より安全を期すために、開発者がプログラムを開発およびテストする場合は、企業のネットワークに接続されていない仮想コンピュータを使用するよう求めます。

ソリューション アーキテクチャ

セキュリティの監視および攻撃検出ソリューションには、セキュリティの警告を提供するために調整するコンポーネントがいくつか含まれています。これには、次のようなコンポーネントがあります。

  • Active Directory ドメイン コントローラ

  • イベント関連付けインフラストラクチャ

  • 監視と分析用ワークステーション

  • オンラインでの保管用データベース

  • バックアップ メディア

  • オンサイトでの短期的なアーカイブ用保管場所

  • オフサイトでの長期的なアーカイブ用保管場所

ローカル セキュリティ設定を使用してセキュリティ監査レベルを構成できるので、Active Directory ドメイン コントローラは厳密な要件ではありません。ただし、ソリューションでセキュリティ監査の実装にグループ ポリシーを使用する場合は、Active Directory が必要です。

ソリューションのしくみ

ソリューション アーキテクチャのコンポーネントは、次の方法で機能します。

  1. 管理者がグループ ポリシーを使用して、監査レベルに必要な変更を適用します。グループ ポリシーの推奨設定の一覧については、付録 B「グループ ポリシー設定の実装」を参照してください。

  2. グループ ポリシーにより、このような変更が指定されたコンピュータに反映されます。

  3. 管理者は、境界ネットワーク内のコンピュータなど、ドメインに含まれないコンピュータのローカル セキュリティ ポリシーに変更を適用します。

  4. セキュリティ イベント ログは、グループ ポリシーの設定に従ってイベントを収集します。

  5. イベント関連付けシステムはセキュリティ イベント ログを定期的にスキャンして、情報を適切なデータベースに保存します。

  6. セキュリティ管理者はデータベースの情報を直接分析するか、Lakeside Software の SysTrack 3 のようなユーティリティを使用して、疑わしい行動を特定できます。

フォレンシック分析用のセキュリティの監視の実装では、次の操作が別に必要になります。

  1. イベント関連付けシステムでは、関連イベントを定期的に抽出し、それらをオンライン データベースに格納します。

  2. オンライン データベースのバックアップ システムでは、あらかじめ決められた間隔 (通常は毎日) で、古くなったレコードをオンライン データベースからアーカイブに保管し、削除します。

  3. バックアップ メディアは、指定された期間、短期的にオンサイトの保管場所に保持します。

  4. 古いバックアップ メディアは定期的 (通常は毎週) にオフサイトの長期的な保管場所に移動します。

  5. 復元操作を担当する管理者は、バックアップが依然として機能することを確認するために、毎月復元テストを実行します。

選択的監査を有効にする

Service Pack 1 を適用した Windows Server 2003 の新機能では、ユーザー アカウントで有効にする監査レベルを選択できます。たとえば、すべてのユーザーのログオンとログオフを監査し、ある特定のユーザーのすべての利用状況を監査できます。または、ある特定のユーザー アカウントを除くすべてのユーザーの利用状況を監査できます。監査レベルを選択して有効にできることにより、疑わしい個人をフィルタ処理したり、追跡するときに必要な定常的なイベントの数を削減できます。選択的に監査を有効にできるのは、セキュリティ グループや配布グループではなく、ユーザー アカウントのみです。

選択的監査レベルを実装する場合は、auditusr.exe コマンド ライン ユーティリティを使用できます。このユーティリティは、SP1 を適用した Windows Server 2003 と SP2 を適用した Windows XP の両方に含まれています。ユーザー単位に監査を構成する方法の詳細については、コマンド プロンプトから「auditusr.exe /?」を実行してください。

注 : ユーザー単位の監査では、組み込みの Administrators グループのメンバのイベントを除外することはできません。

ページのトップへ

ポリシー違反の検出

第 3 章「問題点と要件」では、ネットワークに対する最も大きな脅威は、組織内部のユーザーからの攻撃であると特定しました。採用や選択に最も厳しい手続きを行っている機関でも、最も信頼のおける社内ユーザーの監視を怠ると不利益を被る可能性があります。この章では、多くの内部からの脅威のシナリオを紹介し、併せてこのような脅威の発生を検出する方法について説明します。

システムやネットワークの構成エラーは、一般的に管理者の不注意に原因があります。たとえば、管理者は構成の変更を実装する前に承認プロセスに従い、その後その管理者の正しい資格情報を使用して、ユーザーがアクセスできるワークステーションからログオンしたとします。この例では、管理者は自分の操作を隠そうとしませんでした。一般に、管理者がその操作を隠そうとするかどうかといった要因が、不注意による構成エラーと意図的な妨害行為とを区別することになります。

注 : 適切な変更管理プロセスを既に作成し、実装していた場合は、セキュリティの監視の実装ははるかに効果が高くなります。適切な変更管理プロセスがないと、行われる変更をチェックする対象がないので、変更が適切な手順を使用して行われたことを確認するのは非常に困難です。

ポリシー違反に関する攻撃のプロファイリングは、潜在的な攻撃を示す可能性のあるイベントやイベント シーケンスを特定することに依存しています。この情報とイベント関連付けシステムを併用して、攻撃の形跡を検索できます。

次のような行動に対処することでポリシー違反を検出します。

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

  • パスワードをリセットすることによるリソースへのアクセス

  • ユーザー アカウントの作成、変更、または削除

  • グループへのユーザーの配置

  • 未承認のアカウントを使用する試み

  • サービス アカウントの資格情報による対話的なログオン

  • 未承認プログラムの実行

  • 未承認リソースへのアクセス

  • 承認済みファイルの損傷 (ディスク エラーに起因する損傷以外)

  • 未承認オペレーティング システムの導入

  • 他のユーザーの資格情報の入手

  • 監査を回避する試み

  • 信頼関係の作成または破棄

  • セキュリティ ポリシーの未承認の変更

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

管理者は、ファイルの所有権を変更し、ファイルの読み取りアクセス許可リストに自身を追加することによって、読み取りアクセス許可のないファイルを表示できます。Windows Server 2003 以降では、管理者が所有権とアクセス許可を元の状態に戻すと、このような行為を隠ぺいできます。

すべてのファイルでオブジェクト アクセス監査を構成することは非生産的で、不正行為が莫大な量のイベントに埋もれてしまうことになります。ただし、価値の高いファイルやそのようなファイルを含むフォルダに対するすべてのアクセスや変更はチェックするように、セキュリティ監査レベルを設定する必要があります。ACL エントリだけでは、未承認のアクセスを適切に防御できません。

不正行為を効果的に阻止するには、価値の高いファイルに関して次の要因を特定する必要があります。

  • どのオブジェクトがアクセス試行の対象になったか

  • どのユーザーがアクセスを要求したか

  • ユーザーはそのオブジェクトへのアクセスを認められていたか

  • ユーザーはどの種類のアクセス (読み取り、書き込み、一覧など) を試みたか

  • イベントの監査は成功したか失敗したか

  • ユーザーはどのコンピュータからアクセスを試みたか

イベント ビューアにはこの情報を特定するのに十分なフィルタ設定が用意されていないので、このような分析には EventComb MT やサードパーティの他のユーティリティを使用する必要があります。

次の表では、ファイルのアクセス許可の変更に起因する可能性のある監査イベントを示します。監査カテゴリは、オブジェクト アクセスです。

表 4.1: ファイルのアクセス許可変更イベント

イベント ID 発生事象 コメント
560 アクセスは、既存のオブジェクトに対して許可されました。 一覧、読み取り、作成、削除など、要求したアクセス許可がオブジェクトに正常に許可された場合に表示されます。ファイルのアクセス許可の未承認の変更試行を検出するには、[プライマリ ログオン ID]、[クライアント ユーザー名]、[プライマリ ユーザー名] の各フィールドをチェックします。操作の種類を特定するには、[アクセス] フィールドをチェックします。このイベントはアクセスが要求されたか、許可されたことを表示するだけで、アクセスが行われたことを意味するものではありません。操作を行ったユーザーは [クライアント ユーザー] 存在する場合、または [プライマリ ユーザー] に表示されます。
567 ハンドルに関連付けられているアクセス許可が使用されました。 あるオブジェクトに対するアクセスの種類 (一覧、読み取り、作成など) の最初のインスタンスで発生します。イベント 560 と関連付けるには、2 つのイベントの [ハンドル ID] を比較します。
#### パスワードをリセットすることによるリソースへのアクセス パスワードのリセットは、承認済みの枠組み内のみで行う必要があります。正しく構成されたセキュリティ監査レベルにより、セキュリティ イベント ログにパスワードのリセットが記録され、適切な手順に従わないで行われたリセットを特定する必要があります。 次の表では、パスワードのリセットに起因する監査イベントを示します。監査カテゴリは、アカウント管理です。 **表 4.2: パスワード リセットのイベント**
イベント ID 発生事象 コメント
627 パスワードの変更が試行されました。 ユーザーがアカウントに最初に指定したパスワードの変更要求により発生します。パスワードの変更を試みたのがアカウントの所有者か、それ以外のユーザーかを判断するには、[プライマリ アカウント名] と [対象アカウント名] を比較します。[プライマリ アカウント名] と [対象アカウント名] が等しくない場合は、アカウントの所有者以外のユーザーがパスワードの変更を試みています。Microsoft Windows Me または Windows NT® を実行しているコンピュータでは、変更を要求したアカウントは通常 [匿名] になります。これは、ユーザーが認証されないためです。ただし、要求者は古いパスワードを入力する必要があるので、大きなセキュリティ リスクにはなりません。
628 ユーザー アカウントのパスワードがセットまたはリセットされました。 ユーザーやプロセスが、パスワード変更プロセスではなく、Active Directory ユーザーとコンピュータなどの管理インターフェイスによりアカウントのパスワードをリセットしたときに記録されます。ヘルプ デスクやユーザーのセルフサービス パスワード リセットなど、承認済みのスタッフまたはプロセスだけがこのプロセスを実行する必要があります。
698 ディレクトリ サービス復元モードのパスワードが変更されました。 ユーザーがドメイン コントローラでディレクトリ サービス復元モードのパスワードの変更を試みたときに記録されます。[ワークステーション IP] と [アカウント名] をチェックし、すぐに調査します。
#### ユーザー アカウントの作成、変更、または削除 常に、確立済みのプロセスに従って、新しいユーザー アカウントを作成する必要があります。自動プロビジョニング システムを使用する大規模組織では、このプロセスは新しい雇用者のアカウントの作成を承認するためにマネージャが Web サイトにログオンする必要があるような、複数手順のビジネス ロジック プロセスが必要になることがあります。小規模組織であっても、Active Directory でのユーザー アカウントの作成は、公式の要請の結果としてのみ行う必要があります。その後、ユーザー アカウントの作成を記録する各イベントをアカウント作成要求に対応付けます。信頼できない管理者が、存在しない社員のもっともらしいユーザー アカウントを容易に作成できると、そのアカウントを使って、不正なアクセスや悪意のある行動が可能になります。 また、新しいユーザー アカウントの作成から、そのユーザーがログオンしてパスワードを変更するまでに短期間しか経過しないことも確認する必要があります。新規ユーザーがあらかじめ決められた時間内に新しいアカウントでログオンしない場合は、プロビジョニング システムでそのアカウントを無効にし、セキュリティの管理者がその遅れの理由を調査する必要があります。 セキュリティの監視および攻撃検出を使用してユーザー アカウントの問題を特定するには、次のことを行うクエリを構成する必要があります。 - 変則的または特異なアカウントの利用状況を検索する。 - アカウントの作成や変更の特権を悪用する管理者を特定する。 - 組織のセキュリティ ポリシーに違反するアカウント利用状況のパターンを検出する。 次の表では、ユーザー アカウントの変更を特定するイベントを示します。すべてのイベントは、アカウント管理の監査カテゴリに所属します。 **表 4.3: ユーザー アカウントの変更イベント**
イベント ID 発生事象 コメント
624 ユーザー アカウントが作成されました。 承認済みのユーザーとプロセスだけがネットワーク アカウントを作成する必要があります。承認済みのユーザーまたはプロセスがアカウントを作成しているかどうかを検出するには、[プライマリ ユーザー名] フィールドを調べます。また、管理者が組織のポリシー ガイドラインに従わないでアカウントを作成しているかどうかも検出します。
630 ユーザー アカウントが削除されました。 承認済みのユーザーとプロセスだけがネットワーク アカウントを削除する必要があります。未承認のユーザーがアカウントを削除したことを検出するには、これらのイベントを検索し、[プライマリ アカウント名] フィールドを調べます。
642 ユーザー アカウントが変更されました。 イベント 627 ~ 630 で対応されない、ユーザー アカウントのセキュリティ関連のプロパティに行われた変更を記録します。
685 アカウント名が変更されました。 承認済みユーザーまたはプロセスに対応する [プライマリ アカウント名] を確認します。
#### グループへのユーザーの配置 優れたセキュリティの実践方法として、最小特権の原則を推奨します。つまり、ユーザーにはそのユーザーが仕事を行うのに必要最低限の権利やアクセス許可しか与えません。大部分のユーザー アカウントは、組織固有のセキュリティ グループ以外には、Domain Users グループのみに所属する必要があります。 ユーザー、特に Domain、Schema、Enterprise Admins のような高い特権を持つユーザーをセキュリティ グループに配置する場合は、必ずポリシーのガイドラインに従って行い、確立済みで承認済みのアカウントやプロセスを使用する必要があります。その他の変更は疑わしいものとして扱い、詳しい調査を行います。 **注** : 配布グループはセキュリティ プリンシパルではないので、配布グループのメンバシップはネットワーク リソースへのアクセスを行いません。ただし、特定の配布グループのメンバシップは、別の種類のセキュリティの問題を発生させる可能性があります。たとえば、ユーザー アカウントを Vice-Presidents や Directors といった配布グループに間違って配置すると、そのユーザーは地位にふさわしくないメールを受け取ることになります。 次の表では、グループの変更を特定するイベントを示します。すべてのイベントは、アカウント管理の監査カテゴリに所属します。 **表 4.4: グループ メンバシップ変更のイベント**
イベント ID 発生事象 コメント
631 ~ 634 セキュリティが有効なグローバル グループが変更されました。 組織のポリシーの制約に従わない変更が行われないことを確認するには、Domain Admins グループなど、グローバルまたは広範なアクセス特権を持つグループについて、このイベントを調査します。[対象アカウント名] フィールドのグループ名を調べます。
635 ~ 638 セキュリティが有効なローカル グループが変更されました。 ポリシーの制約に従わない変更が行われないことを確認するには、Administrators、Server Operators、Backup Operators などのグループについて、このイベントを調査します。[対象アカウント名] フィールドのグループ名を調べます。
639 641 668 セキュリティが有効なグループが変更されました。 これらのイベントは、削除、作成、またはメンバシップの変更以外の変更がグループに行われたことを示します。ポリシーの制約に従わない変更が行われないことを確認するには、高い特権レベルを持つグループについて、これらのイベントを照査する必要があります。[対象アカウント名] フィールドのグループ名を調べます。
659 ~ 662 セキュリティが有効なユニバーサル グループが変更されました。 ポリシーの制約に従わない変更が行われないことを確認するには、Enterprise Admins や Schema Admins など、高い特権レベルを持つグループについて、このイベントを調査します。[対象アカウント名] フィールドのグループ名を調べます。
#### 未承認のアカウントを使用する試み フォレスト内の最初の Active Directory ドメイン コントローラの昇格により、Domain Admins グループおよび Enterprise Admins グループのメンバである管理者アカウントが作成されます。このアカウントは、アカウントのロックアウト設定が適用されない唯一のアカウントなので、特定の保護が必要です。したがって、適切なアカウント ロックアウト ポリシーを備えている場合でも、このアカウントは辞書攻撃に対して脆弱になる可能性があります。 この管理者アカウントの名前を変更していたとしても、セキュリティの監視でこの管理者アカウントでのログオン試行を特定する必要があります。管理者アカウントのセキュリティの昇格の詳細については、「[管理者アカウント セキュリティ計画ガイド](https://go.microsoft.com/fwlink/?linkid=41315)」 (https://go.microsoft.com/fwlink/?LinkId=41315) を参照してください。 無効なアカウントや有効期限の切れたアカウントでのログオン試行は、元社員、臨時雇用者、請負業者などが現在の承認を受けないでネットワークにアクセスしようとしていることを示す可能性があります。このようなイベントはすぐに調査が必要です。 次の表では、未承認アカウントの使用を特定するイベントを示します。イベントは、アカウント ログオン監査カテゴリとログオン監査カテゴリに所属します。 **表 4.5: 未承認ログオンのイベント**
イベント ID 発生事象 コメント
528/540 ログオンに成功しました。 [対象アカウント名] と既定の管理者アカウントが等しい場合は、疑わしいと思われます。ただし、イベント 528 は通常の運用用途では一般的なイベントです。
529 ログオンに失敗しました — ユーザー名やパスワードが不明です。 [対象アカウント名] が Administrator または名前を変更した管理者アカウントに等しい場合は、ログオン試行をチェックします。アカウント ロックアウトのしきい値よりも少なくても、複数回ログオンに失敗しているものをチェックします。
531 ログオンに失敗しました — アカウントが無効です。 このイベントは必ず調査します。[対象アカウント名] と [ワークステーション名] をチェックします。このイベントは、以前の内部ユーザーが悪用を試みている兆候を示す可能性があります。
532 ログオンに失敗しました — アカウントの有効期限が切れています。 このイベントは必ず調査します。[対象アカウント名] と [ワークステーション名] をチェックします。このイベントは、請負業者や一時的な内部ユーザーが悪用を試みている兆候を示す可能性があります。
576 新しいログオンに特殊な特権が割り当てられました。 新しいログオン セッションに、管理アクセスや監査記録の改ざんを行える特権が与えられると必ず発生します。2 つのイベントの [ログオン ID] フィールドを比較することにより、イベント 528 または イベント 540 と関連付けます。イベント 576 によって、アカウントがログオン時に管理者と同等の特権を得たかどうかを迅速に判断できます。この方法は、グループのメンバシップを調べるよりも簡単です。
#### サービス アカウントの資格情報による対話的なログオン サービスは、開始時にログオン資格情報を提示する必要があります。場合によっては、リモート コンピュータに接続してサービスを実行するために、サービス アカウントとしてドメイン アカウントが必要になることがあります。一部のサービス アカウントでは、管理者の資格情報で実行したり、デスクトップとの対話が必要になることもあります。 Windows Server 2003 以降では、一部のサービス アカウント (Alerter サービスなど) を –LocalService スイッチを指定して開始できます。ネットワークへの接続を必要とするサービスは、Network Service アカウント、つまり NT AUTHORITY\\NetworkService を使用できます。このようなアカウントが強固なパスワードを使用していることを確認するために、ユーザー アカウントを必要とするすべてのサービスをチェックする必要があります。セキュリティの監視では、このようなアカウントのログオン イベントが関連サービスの開始時のみ発生していることを確認する必要があります。サービス アカウントのセキュリティの昇格の詳細については、「[The Service and Service Accounts Security Planning Guide](https://go.microsoft.com/fwlink/?linkid=41311)」 (https://go.microsoft.com/fwlink/?LinkId=41311) (英語) を参照してください。 サービス アカウントでサービスとしてログオンするのではなく、対話的にログオンされたときに、セキュリティ上の主な懸念が生じます。侵入者がサービス アカウントのパスワードを見つけ出し、そのアカウントでログオンする場合のみこの事象が発生します。そのサービス アカウントに管理特権があると、侵入者は通常のネットワーク サービスを混乱に陥れる大きな力を得ることになります。 サービス アカウントがアクセスできるすべてのリソースを特定します。たとえば、時にはサービス アカウントがログ ファイル ディレクトリに書き込みアクセス許可を必要とする適切な理由があることもありますが、一般的にはこのようなことはありません。サービス アカウントには、価値の高いデータにアクセスする、説明できないアクセス許可を与えてはいけません。サービス アカウントは攻撃者に大きなチャンスを与える可能性があるので、デスクトップと対話できるサービス アカウントは綿密に精査する必要があります。 次の表では、サービス アカウントの未承認の使用を特定するイベントを示します。イベントは、アカウント ログオン監査カテゴリとログオン監査カテゴリに所属します。 **表 4.6: サービス アカウントの資格情報でのログオン イベント**
イベント ID 発生事象 コメント
528 ログオンに成功しました — コンソール攻撃またはターミナル サービス。 イベント ログに、[ログオンの種類 2] でサービス アカウントまたはローカル システムについてイベント 528 が記録される場合は、攻撃が進行中で、攻撃者がサービス アカウントのパスワードを入手し、コンソールにログオンしたことを示します。イベント ログに [ログオンの種類 10] が記録されている場合は、攻撃者はターミナル サービスを使用してログオンしました。いずれの場合も、すぐに調査が必要です。
534 ログオンに失敗しました — ログオンの種類が許可されていません。 [対象アカウント名]、[ワークステーション名]、および [ログオンの種類] をチェックします。このイベントは、グループ ポリシーの設定によって、サービス アカウントで対話的にログオンすることが防止されている場合に、サービス アカウントの資格情報で対話的にログオンしようとして失敗したことを示します。
600 プロセスにプライマリ トークンが割り当てられました。 サービスが名前付きアカウントを使用して、Windows XP 以降を実行するコンピュータにログオンすると発生します。このイベントをイベント 672、673、528、および 592 と関連付けます。
601 ユーザーがサービスのインストールを試みました。 サービスのインストールは日常的な操作ではないので、めったに発生することはありません。このイベントについては、成功したものも失敗したものもすべて調査する必要があります。
#### 未承認プログラムの実行 管理者は信頼のおけるスタッフなので、プログラムをインストールして実行できます。組織では、承認済み (かつライセンスが許可された) プログラムの一覧と、新しいプログラムを承認するプロセスの両方を作成する必要があります。管理者は新しいプログラムを独立したネットワーク セグメントでテストすることに加えて、承認済みの一覧に含まれていないプログラムは実行しないようにします。 プロセス追跡のセキュリティ監査で、未承認のプログラムを特定できます。ただし、プロセスの追跡では複数のセキュリティ ログ エントリが生成されるので、イベントの数が検出メカニズムに悪影響を与えないことを確認する必要があります。 次の表では、未承認プログラムの使用を特定するイベントを示します。イベントは、プロセスの追跡監査カテゴリに所属します。 **表 4.7: 未承認プログラムの実行のイベント**
イベント ID 発生事象 コメント
592 新しいプロセスが作成されました。 新しいプロセスの [イメージ ファイル名] と [ユーザー名] をチェックします。すべてのプロセスが、承認済みプログラムの一覧に存在する必要があります。
602 スケジュールされたジョブが作成されました。 スケジュールされたプロセスを実行するために承認の [対象名] をチェックし、既知のタスク スケジュールに関連するイベントの [時刻] をチェックします。
#### 未承認リソースへのアクセス この場合、イベント ID 560 の監査エラーの特定が必要です。次の表では、未承認のリソースにアクセスすることに起因するイベントを示します。監査カテゴリは、オブジェクト アクセスです。 **表 4.8: 未承認リソースへのアクセス試行のイベント**
イベント ID 発生事象 コメント
560 アクセスは、既存のオブジェクトに対して拒否されました。 監査エラーを監視します。アクセスしたリソースの [オブジェクト名] フィールドを確認します。[プライマリ ユーザー名] フィールドと [プライマリ ドメイン] フィールド、または [クライアント ユーザー名] フィールドと [クライアント ドメイン] フィールドを関連付けます。
568 監査対象のファイルへのハード リンクを作成しようとしました。 ユーザーまたはプログラムが、ファイルやオブジェクトへのハード リンクを作成しようとすると発生します。ユーザーがハード リンクを作成すると、そのユーザーは監査記録を作成しないで、そのユーザーの権利内でファイルを操作できます。
#### 承認済みファイルの損傷 これは、ユーザーが結果を考えずに、自身がアクセスできるファイルを故意に損傷する場合です。この種の行動がよく見られるのは、組織があるユーザーを解雇し、管理者がそのユーザーのアカウントをまだ無効にしていない場合です。 このような意図的な妨害行為を削減するには、ユーザーのアカウントを即時無効にし、そのユーザーを強制的にログオフするような、明示的に文書化された効果的なプロビジョニング解除戦略が必要です。 #### 未承認オペレーティング システムの導入 管理者やユーザーは、次のメカニズムを使用してネットワークに未承認のオペレーティング システムを導入できます。 - ネットワークに接続されたホーム コンピュータ - CD から起動できるオペレーティング システム - Windows XP またはその他の Windows オペレーティング システムの再インストール - Microsoft Virtual PC イメージ 未承認のオペレーティング システムは、次のような重大な問題を引き起こす可能性があります。 - セキュリティの更新が適用されていないことによる脆弱性保護の低下 - 未承認のオペレーティング システムがネットワーク上の他のコンピュータと同じアドレスを使用する場合の IP アドレスの重複 - ウイルスやその他の悪意のあるソフトウェアに対する脆弱性の増加 - ファイル損傷の確率の増加 - ヘルプ デスクへの支援要請の増加 - 生産性の低下 リモートの場所から作業するユーザーが、リモート アクセス サービスや仮想プライベート ネットワークによって企業ネットワークに接続できるかどうかを組織のポリシーで指定できます。リモート コンピュータをネットワークに接続する前に、リモート コンピュータが組織のセキュリティ ポリシーに準拠していることを確認する方法の詳細については、「[Implementing Quarantine Services with Microsoft Virtual Private Network Planning Guide](https://go.microsoft.com/fwlink/?linkid=41307)」 (https://go.microsoft.com/fwlink/?LinkId=41307) (英語) を参照してください。 **注 :** 配布されているオープン ソース ソフトウェアの中には、スタートアップ CD を入手できるものがあります。ユーザーは CD を挿入してコンピュータを再起動するだけで、このようなオペレーティング システムを起動できます。オープン ソース ソフトウェアは Windows とは無関係に実行されるので、イベント ログを監視していても、このような事象は検出できません。ただし、異種環境の "root" ユーザーからのログオン試行により、未承認のオペレーティング システムの存在が示されることがあります。クライアント コンピュータから CD ドライブを撤去することで、この問題に対処できますが、あまり実践的ではありません。 ユーザーは、Windows XP のインストール CD を入手し、コンピュータを再起動することで、Windows XP を再インストールできます。この場合は、他のコンピュータのイベント ログを監視することで、未確認のワークグループ名または既定名の "Workgroup" を持つ "Administrator" ユーザーからのログオン試行を検出できます。 Virtual PC イメージにより、ホスト コンピュータでコンピュータ環境を完全にエミュレーションできます。このエミュレーションでは、独自のコンピュータ名、アカウント、ワークグループやドメインのメンバシップ、およびプログラムを使って独自のオペレーティング システムを実行できます。ホスト コンピュータに影響を及ぼさずに、Virtual PC イメージを開始、実行、終了できます。Virtual PC は、企業ネットワーク リソースの IP アドレスやアクセスを要求することもできます。Virtual PC イメージでは、空白のパスワードや簡単に想像できるパスワードを使用し、セキュリティを考慮していないことも珍しくはないので、これが脅威になります。セキュリティが考慮されていない Virtual PC イメージを実行するユーザーはネットワーク共有にドライブを割り当てたり、Microsoft インターネット インフォメーション サービス (IIS) のような、後に Service Pack やセキュリティの更新で対処されることになった固有の脆弱性を含むコンポーネントをインストールできます。 セキュリティの監視を構成して、次のことを検出する必要があります。 - 未承認のユーザー名、コンピュータ名、ワークグループ名、またはドメイン名 - 重複した、または範囲外の IP アドレス - 既定の Administrator アカウントでのログオン試行 次の表では、未承認オペレーティング システムの使用を特定するイベントを示します。イベントは、プロセスの追跡監査カテゴリに所属します。 **表 4.9: 未承認プラットフォームの実行のイベント**
イベント ID 発生事象 コメント
529 ログオンに失敗しました — ユーザー名やパスワードが不明です。 [対象アカウント名] が Administrator に等しくかつ [ドメイン名] が不明か、[対象アカウント名] が root に等しいログオン試行をチェックします。
592 新しいプロセスが作成されました。 新しいプロセスの [イメージ ファイル名] と [ユーザー名] をチェックします。すべてのプロセスが認証済みのプログラムである必要があります。
**注 : **Rootkit の信頼性の高い検出を確保するには、Sysinternals の RootkitRevealer や F-Secure のブラックライトなど、サードパーティの製品を評価します。ブラックライトの詳細については、プレス リリース「[次世代侵入防止技術「F-Secure ブラックライト」を発表](https://www.f-secure.co.jp/news/200503091/)」 (https://www.f-secure.co.jp/news/200503091/) を参照してください。 #### 他のユーザーの資格情報の入手 優れたパスワード ポリシー (一定のパスワード長の要求や定期的なパスワード変更の強制など) の意図しない結果の 1 つに、ユーザーがパスワードを書きとめることが挙げられます。このような状況は、ユーザーに複数回のログオンを求める、複数の ID ストアを備えた異種環境で顕著に見受けられます。 **注 :** 異種環境でのパスワード管理の詳細については、「[ID およびアクセス管理 - 基本概念](https://www.microsoft.com/japan/technet/security/guidance/identitymanagement/idmanage/p1fund_0.mspx)」 (https://www.microsoft.com/japan/technet/security/guidance/identitymanagement/idmanage/p1fund\_0.mspx) を参照してください。 承認を受けていない個人がオフィスに入り込み、ユーザーのログオン資格情報を簡単に見つけ出すことができるので、組織ではパスワードを書き留めたり、そのメモを目に付くところに放置する行為に警戒する必要があります。セキュリティの監視では、ユーザーが通常使用しているコンピュータ以外からログオンした場合はそれを検出する必要があります。この種の攻撃を検出するには、ログオンに成功したワークステーション名と、これらのワークステーションに対するユーザー アクセスや認証を相互に関連付ける必要があります。 **注 :** Active Directory により、ユーザーがログオンできるワークステーションを制御できます。このような機能には、Windows インターネット ネーム サービス (WINS) などによる、ネットワーク基本入出力システム (NetBIOS) の名前付けがサポートされる必要があります。 このような事象に対するイベントは、表 4.5 「未承認ログオンのイベント」の一覧と同じです。 #### 監査を回避する試み 攻撃者は発見されないように、さまざまな方法を使用する可能性があります。たとえば、コンピュータやドメインのセキュリティ ポリシーを変更して、イベント ログに疑わしい行動が記録されないようにしたり、監査データが失われるようにセキュリティ ログを意図的に消去する可能性があります。このようなイベントの多くは、通常のネットワーク操作の一環として正規に発生するので、証拠を隠ぺいする試みを検出するのは困難です。 次の表では、攻撃者がセキュリティ違反を隠そうとすることによって生じる可能性の高い事象を特定するイベントを示します。イベントは、複数の監査カテゴリに所属します。 **表 4.10: 監査を回避するイベント**
イベント ID 発生事象 コメント
512 Windows を起動しています。 通常は、イベント 513 の後に発生します。予期しない再起動を調査します。
513 Windows をシャットダウンしています。 通常は、イベント 512 の前に発生します。価値の高いコンピュータでは、承認済みのユーザーが確立済みのポリシーに従ってコンピュータを再起動する必要があります。任意のサーバーでこのイベントが発生したときはすぐに調査します。
516 監査でエラーが発生しました。 イベント ログ バッファに収容しきれないほど多くのセキュリティ イベントが発生したときに、このイベントが発生する可能性があります。監査するイベントの数を制限します。セキュリティ ログを上書きしないように構成している場合もこのイベントが発生する可能性があります。監査ログのレベルを高く維持する必要のある領域では、コンピュータを綿密に監視する必要があります。セキュリティの設定によって、セキュリティ ログがいっぱいになったときに、一部のコンピュータがシャットダウンされる原因になる可能性があります。セキュリティが懸案事項であるすべてコンピュータでイベント 516 を監視します。
517 セキュリティ イベント ログが消去されました。 管理者は、承認を得ないでセキュリティ ログを消去してはいけません。[クライアント ユーザー名] と [クライアント ドメイン] をチェックし、承認済みユーザーと相互に関連付けを行います。
520 システム時刻が変更されました。 この操作は、フォレンシック調査を誤った方向に導いたり、攻撃者に虚偽のアリバイを提供する可能性があります。プロセス名は、%windir %\system32\svchost.exe です。[クライアント ユーザー名] と [クライアント ドメイン] をチェックし、承認済みユーザーと相互に関連付けを行います。
521 イベントをログに記録できません。 Windows がイベントをセキュリティ イベント ログに書き込めません。価値の高いコンピュータでこのイベントが発生した場合は、すぐに調査する必要があります。
608 ユーザー アカウントの特権が割り当てられました。 この操作では、ユーザー アカウントに新しい特権が許可されます。イベント ログには、ユーザー アカウント名ではなく、ユーザー アカウントのセキュリティ ID (SID) と共にこの操作が記録されます。
609 ユーザー アカウントの特権が削除されました。 この操作では、ユーザー アカウントから特権が削除されます。イベント ログには、ユーザー アカウント名ではなく、ユーザー アカウントの SID と共にこの操作が記録されます。
612 監査ポリシーが変更されました。 このイベントは、必ずしも問題を示しているわけではありません。ただし、攻撃者はコンピュータ システムへの攻撃の一環として、監査ポリシーを変更する可能性があります。価値の高いコンピュータやドメイン コントローラではこのイベントを監視する必要があります。
621 アカウントに対してシステム アクセス権限が許可されました。 ユーザーにシステムへのアクセスが許可されました。特にアクセス権限が対話的な場合は、[ユーザー名] と [アカウントの変更] をチェックします。
622 アカウントからシステム アクセス権限が削除されました。 このイベントは、攻撃者がイベント 621 の証拠を削除したか、他の一部のアカウントに対してサービスの拒否を試みていることを示す可能性があります。
643 ドメイン セキュリティ ポリシーが変更されました。 このイベントは、パスワード ポリシーまたはその他のドメイン セキュリティ ポリシー設定の変更が試みられていることを示します。対象のユーザー名をチェックし、承認と関連付けます。
#### 信頼関係の作成または破棄 信頼関係により、あるドメインのユーザーが別のドメインのネットワーク リソースにアクセスできるようになります。自動的に推移する双方向の信頼関係は、同じ Active Directory フォレスト内のすべてのドメインに展開されます。次のようなその他の状況では、信頼関係を手動で作成する必要があります。 - Windows NT 4.0 ドメインを含む信頼 - ドメイン間のショートカット信頼 - Windows 2000 Server の異なるフォレスト内のドメイン間の信頼 - Windows Server 2003 のフォレスト間信頼 信頼関係の作成は、定常的な操作ではありません。エンタープライズ管理者のみが、明確に定義された、承認済みの確立されたプロセスで行うべき操作です。同様に、信頼関係の破棄は、エンタープライズ管理者がネットワークでの効果を注意深く分析した後、明確に定義された、承認済みの確立されたプロセスを参照することによって行うべき操作です。 次の表では、信頼関係に関する操作を特定するイベントを示します。イベントは、ポリシーの変更監査カテゴリに所属します。 **表 4.11: 信頼関係の変更イベント**
イベント ID 発生事象 コメント
610 611 620 他のドメインとの信頼関係が、作成、削除、または変更されました。 これらのイベントは、信頼されるドメイン オブジェクトが作成されるドメイン コントローラで表示されます。このイベントでは、警告を生成し、すぐに調査する必要があります。信頼操作が実行された対象の [ユーザー名] をチェックします。
#### セキュリティ ポリシーの未承認の変更 承認済みのセキュリティ構成に対する変更は、合意済みのプロセスと一連の手順の枠組み内でのみ行う必要があります。管理者の不注意によるエラーまたは意図的な妨害行為のいずれかのような、この枠組み以外でのセキュリティ構成に対する変更を監視する必要があります。 次のようなセキュリティ構成設定は、定義済みの枠組み以外で変更してはいけません。 - グループ ポリシー設定 - ユーザー アカウント パスワードのポリシー - ユーザー アカウント ロックアウトのポリシー - 監査ポリシー - セキュリティ イベント ログに適用するイベント ログ設定 - IPSec ポリシー - ワイヤレス ネットワーク (IEEE 802.11) ポリシー - 公開キーのポリシー、特に暗号化ファイルシステム (EFS) に適用する公開キーのポリシー - ソフトウェア制限ポリシー - セキュリティ設定 - ユーザー権利の割り当て - ユーザー アカウント パスワードのポリシー - セキュリティ オプション この一覧は、最低要件を表しています。多くの組織では、おそらくさらに多くのグループ ポリシー設定を追加しています。このような設定に対する変更の試みが成功したものと失敗したものの両方を特定するようにセキュリティ監査を構成する必要があります。また、成功したすべての試みは、適切に認証を受けたユーザー アカウントと関連付ける必要があります。 次の表では、ポリシーの変更 (グループ ポリシーまたはローカル セキュリティ ポリシーのいずれか) を特定するイベントを示します。イベントは、ポリシーの変更監査カテゴリに所属します。 **表 4.12: ポリシーの変更イベント**
イベント ID 発生事象 コメント
612 監査ポリシーが変更されました。 監査ポリシーに対するすべての変更を特定します。このイベントを承認済みのユーザーがシステム ポリシーに行った変更と関連付けます。
613 614 615 IPsec ポリシーが変更されました。 これらのイベントを監視し、システムの起動時以外での発生を調査します。
618 暗号化されたデータの回復ポリシーが変更されました。 暗号化されたデータの回復ポリシーを使用している場合は、このイベントを監視し、指定したポリシー以外での発生を調査します。
グループ ポリシー設定の詳細については、「[Security Policy Settings](https://msdn2.microsoft.com/en-us/library/aa455966.aspx)」 (https://msdn2.microsoft.com/en-us/library/aa455966.aspx) (英語) を参照してください。 [](#mainsection)[ページのトップへ](#mainsection) ### 外部からの攻撃の特定 外部からの攻撃は、個人の行為または悪意のあるプログラムによる影響によって生じます。このような攻撃は重複する可能性があります。たとえば、トロイの木馬はデスクトップ コンピュータへのアクセス権を取得しますが、その後個人がこのアクセス権を直接悪用する可能性もあります。 多くの場合、外部からの攻撃者は、1 台以上のコンピュータの管理アクセス許可を得るまで、特権を昇格することによってセキュリティ違反を試みます。このようなアプローチは、一般に、特権が制限されたユーザー アカウントで侵入を成功させることから始まります。その後、システム コンテキストで実行されるプロセスやサービスを作成することで、特権の昇格を試みます。次に、ネットワークを詳しく探索するソフトウェア (たとえば、パスワードを横取りするツールや、ネットワーク パケットをスキャンするツール) をアップロードして実行します。 攻撃者は、サーバーに Rootkit のインストールを試みることもあります。Rootkit は、コンピュータを完全に制御し、標準の診断ツールからその存在を隠ぺいするソフトウェア コンポーネントです。Rootkit はハードウェアの非常に低いレベルを操作するので、システム コールをインターセプトしたり、変更することができます。Rootkit の実行可能ファイルを検索しても、返された検索結果の一覧から Rootkit 自体を削除するので見つけることができません。ポート スキャンを実行しても、Rootkit はスキャナが開いているポートを検出できないようにするので、Rootkit が使用しているポートが開かれていることが明らかになることはありません。したがって、Rootkit を扱うときに最も困難なことはその存在を確認することです。 トロイの木馬アプリケーションはより破壊的な結果を招く可能性がありますが、Rootkit に比べれば検出はそれほど困難ではありません。トロイの木馬は、Rootkit と同様にリモート制御機能を提供する場合もあれば、ウイルスのように単純にデータを破壊する場合もあります。トロイの木馬の主な特徴的な機能は、その古典的な名前が示すとおり、一見有用に見え、ユーザーが誤ってそれを実行するように欺こうとすることです。 悪意のあるプログラムの大部分は、人手による攻撃ほど柔軟でも、反応が早くもありません。ただし、電子メールなど、境界ネットワークを迂回してウイルスを配信する可能性のあるメカニズムに注意を払う必要があります。電子メールの添付ファイルを厳密にフィルタ処理することにより、この種の攻撃を軽減できます。 外部からの攻撃には、次のカテゴリがあります。 - 資格情報を侵害する試み - 脆弱性の悪用 - Rootkit またはトロイの木馬のインストール - ユーザーを利用した悪意のあるプログラムの実行 - 未承認コンピュータのアクセス #### 資格情報を侵害する試み 攻撃者は、いくつかの手口を使ってユーザー アカウントの資格情報を入手します。最もよく知られている手口は、1 つのユーザー アカウントに辞書攻撃を仕掛けることです。この場合は、1 つのユーザー アカウントが知られるだけです。ディレクトリ サービス データベースに含まれるすべてのユーザー アカウントに同じセットのパスワードを当てはめる手口もあります。この場合、攻撃者はおそらく組織のディレクトリ サービスにアクセスできます。2 番目の手口を検出するには、たとえログオン試行の合計回数がアカウント ロックアウトのしきい値よりも少なくても、アカウントのロックアウトと一連のアカウントでの複数回のログオンの失敗を監視できる必要があります。 パスワードの変更やリセットも、ユーザーのログオン情報を入手する手口の 1 つです。パスワードの変更やリセットの操作は、成功しても失敗しても同じイベントが生成されるので、攻撃者はアカウント ロックアウト ポリシーを迂回して検出を回避できます。セキュリティの監視ソリューションでは、パスワードの複数回の変更やリセットの試み、特に組織で決められたパスワードの変更やリセットの枠組み外で行われるものを特定する必要があります。 パスワードの循環は攻撃ではありませんが、変更用パスワードを数多く用意し、ユーザー起動のスクリプトでそのパスワード変換を順番に行っていくときに、以前に使用したパスワードに戻るとパスワードの循環が発生します。パスワードの変更を試みる回数は、パスワード再利用のしきい値と等しくなります。このシナリオでは、\[プライマリ アカウント名\] と \[対象アカウント名\] が等しい 627 イベントが短期間に連続して発生します。パスワードの変更禁止期間を実装することで、このようにパスワードを変更する試みは失敗することになります。 次の表では、ユーザーの資格情報を対象とする攻撃に起因するイベントを示します。ただし、これらのイベントは通常のネットワーク操作の一環として、または正規のユーザーがパスワードを忘れたときにも発生する可能性があります。 **表 4.13: 認証資格情報への攻撃のイベント**
イベント ID 発生事象 コメント
529 ログオンに失敗しました — ユーザー名やパスワードが不明です。 [対象アカウント名] が Administrator または名前を変更した管理者アカウントに等しい場合は、ログオン試行をチェックします。アカウント ロックアウトのしきい値よりも少なくても、複数回ログオンに失敗しているものをチェックします。このイベントは、未承認ユーザーがローカル管理者のパスワードの推測を試みていることを示す可能性があります。連続的なアカウント ロックアウトのパターンを特定するには、イベント 529 とイベント 539 を関連付けます。
534 ログオンに失敗しました — ログオンの種類が許可されていません。 ネットワーク、対話型、バッチ、サービスなど、許可されない種類のログオンを使用してユーザーがログオンを試行しました。[対象アカウント名]、[ワークステーション名]、および [ログオンの種類] をチェックします。
539 アカウントがロックアウトされていました。 ユーザーが、既にロックアウトされたアカウントにログオンしようとしました。連続するロックアウトのパターンを検出するには、イベント 529 と関連付けます。
553 リプレイ攻撃が検出されました。 認証パッケージ (通常 Kerberos) で、ユーザーの資格情報のリプレイによるログオン試行が検出されたときに発生します。すぐに調査します。また、これは不適切なネットワーク構成の兆候を示す可能性もあります。
627 パスワードの変更が試行されました。 アカウント パスワードの変更を試みたのがアカウントの所有者か、それ以外のユーザーかを判断するには、[プライマリ アカウント名] と [対象アカウント名] を比較します。[プライマリ アカウント名] と [対象アカウント名] が等しくない場合は、アカウントの所有者以外のユーザーがパスワードの変更を試みていることを示します。
628 ユーザー アカウントのパスワードがセットまたはリセットされました。 ヘルプ デスクやユーザーのセルフサービス パスワード リセットなど、承認済みユーザーまたはプロセスのみが、この作業を実行する必要があります。これ以外の場合は、このイベントをすぐに調査します。
644 ユーザー アカウントが自動的にロックされました。 ログオン試行の連続失敗回数がアカウントのロックアウト制限数よりも大きくなったので、ユーザー アカウントがロックアウトされました。このイベントをイベント 529、675、676 (Windows 2000 Server のみ)、および 681 と関連付けます。この表のイベント 12294 のエントリを参照してください。
675 事前認証が失敗しました。 ログオンの失敗の詳細な理由を検索するには、イベント 529 と関連付けます。理由には、時刻の同期や、ドメインに正しく参加していないコンピュータ アカウントなどがあります。
12294 アカウントのロックアウトが試行されました。 このイベントは、既定の Administrator アカウントに対するブルート フォース攻撃の可能性を示します。このアカウントはロックアウトされないので、システム イベント ログには、代わりに SAM イベント 12294 が記録されます。これは未承認のオペレーティング システムの存在を示す可能性もあるので、このイベントが 1 回でも発生した場合は調査します。[ドメイン名] が不明なドメインかどうかをチェックします。
#### 脆弱性の悪用 どのコンピュータにも脆弱性が存在する可能性があるので、攻撃者は組織のネットワークに侵入するために、このような脆弱性を悪用しようとします。脆弱性の悪用を試みる攻撃者に対する最善の保護は、Microsoft Systems Management Server 2003 や Microsoft Software Update Services を使用する効果的な修正プログラム管理プロセスを定義することです。 修正プログラム管理の詳細については、「[Patch Management Using Systems Management Server 2003](https://www.microsoft.com/download/details.aspx?familyid=e9eab1bd-13e7-4e25-85c5-ce2d191c3d63)」 (https://www.microsoft.com/download/details.aspx?FamilyID=e9eab1bd-13e7-4e25-85c5-ce2d191c3d63) (英語) および「[Patch Management Using Software Update Services](https://www.microsoft.com/download/details.aspx?familyid=38d7e99b-e780-43e5-aa84-cdf6450d8f99)」 (https://www.microsoft.com/download/details.aspx?familyid=38d7e99b-e780-43e5-aa84-cdf6450d8f99) (英語) を参照してください。 境界ネットワーク内のコンピュータは最も攻撃を受けやすいので、境界ネットワークでのセキュリティの監視が特に重要です。攻撃が進行中であることを検出するメカニズムが存在しなければ、攻撃者がネットワークを危険に曝すまで間違いに気付かない可能性があります。境界ネットワーク内のコンピュータのセキュリティの監視では、広範なイベントを検出できる必要があります。 脆弱性の悪用を示す一般的な事象には、未承認のアクセス試行や特権のある ID の使用があります。次の表では、コンピュータで可能性のある攻撃を特定できるイベントをいくつか示します。 **注 :** この種の攻撃を特定できるその他のイベントについては、表 4.13 「認証資格情報への攻撃のイベント」を参照してください。 **表 4.14: 特権を昇格することで脆弱性を悪用するイベントの特定**
イベント ID 発生事象 コメント
528 538 ローカル ログオンとログオフ 境界コンピュータでローカル ログオンが行われることはめったにありません。[ログオン ID] フィールドに関連付けます。[ユーザー アカウント名]、[時刻]、または [ワークステーション名] が予定どおりの値かどうかを調査します。
576 特権付きログオン SP1 以降を適用した Windows Server 2003 では、このイベントは "管理者" ログオンを示します。このログオンは、Trusted Computing Base (TCB) を改ざんしたり、コンピュータを支配できる十分な特権を備えています。以前のバージョンの Windows では、SeSecurityPrivilege や SeDebugPrivilege など機密性の高い特権を含む場合のみ、このイベントに注意します。
**注 :** Windows Server 2003 よりも前のバージョンの Windows では、イベント 576 は特権の使用カテゴリの一覧に分類されます。Windows Server 2003 以降では、ログオン カテゴリの一覧にも分類されます。したがって、どちらのカテゴリの監査設定の構成にもこのイベントが示されることになります。 #### Rootkit またはトロイの木馬のインストール セキュリティの監視によって Rootkit のインストールを検出することは困難ですが、不可能ではありません。短期間に連続的に開始と停止を繰り返す不明なプログラムは、Rootkit を示す可能性があります。Rootkit が開始されると、オペレーティング システムでの検出はできなくなります。そのため、プログラムは終了したように見え、それ以上イベントを生成することはありません。 トロイの木馬には Rootkit のようなステルス特性がないので、一般的に Rootkit よりも容易に特定できます。キーストローク ロガー (キーストロークの記録を試みるプログラム) もこのカテゴリに入ります。 次の表では、Rootkit のインストールに起因する可能性があるイベントを示します。 **表 4.15: Rootkit やトロイの木馬のイベント**
イベント ID 発生事象 コメント
592 新しいプロセスが作成されました。 新しいプロセスの [イメージ ファイル名] と [ユーザー名] をチェックします。すべてのプロセスは、認証済みのプログラムである必要があります。
#### ユーザーを利用した悪意のあるプログラムの実行 この手口では、攻撃者は実行可能な添付ファイルをユーザーに配信するために、ファイアウォールや境界ネットワークの迂回を試みます。電子メールが最も一般的な配信メカニズムですが、ウイルスに感染した Web サイトに接続させることによって同じ結果を達成するものもあります。 攻撃者は、まずユーザーにプログラムを実行させようとします。ユーザーがプログラムを実行すると、そのプログラムはユーザーのセキュリティ コンテキストで開始されます。その後プログラムは、たとえば管理者相当の権限を得るため、またはネットワークへのアクセス許可を獲得するために、特権の昇格を試みます。 プログラムを起動しようとする試みを検出するために、プロセスの追跡を構成できます。ユーザーが実行できるプログラムを制限するようにソフトウェア制限ポリシーが適切に設定されていれば、未承認のプログラムを起動しようとする試みにより、調査すべき監査エラー イベントが作成されます。次のイベントが発生した場合は特に注意が必要です。 - **LocalSystem で起動されるプロセス** : LocalSystem で実行されるプロセスは明確になっている必要があります。一般には、services.exe などのサービスの実行可能形式です。その他の実行可能イメージの存在を示すイベント 592 が発生する場合は、その正当性を詳しく調査します。 - **予想外のタイミングで起動されるプロセス** : コンピュータでバックアップ、CGI、スクリプトなどのスケジュールされたバッチ プロセスを使用していない場合は、異例のタイミング (夜間など) に作成されるプロセスは詳しく調査する必要があります。イベント 592 の発生を調べます。 表 4.15 「Rootkit やトロイの木馬のイベント」では、ユーザーを利用して悪意のあるプログラムを起動させるときに発生する可能性のあるイベントを示しています。 #### 未承認コンピュータのアクセス 特定のコンピュータに接続するために、管理者がターミナル サービスなどのリモート管理機能を使用する機会が増えてきています。そのため、対話的にログオンを試みるコンピュータを監視し、その接続試行が妥当かどうかをチェックする必要があります。次のチェックを行います。 - サービス アカウントを使用するログオンを特定する。 - 未承認のアカウントでサーバーにアクセスする試みを記録する。 - 予期しない地域からサーバーにアクセスする試みをチェックする。 - 外部の IP アドレス範囲からサーバーにアクセスする試みの一覧を作成する。 財務記録や顧客情報など、価値の高い資産では、この種の監視が特に重要になります。このようなリソースは独立したサーバーに配置して、厳密なポリシーによりリソースへのアクセスを管理する必要があります。 セキュリティの監視では、このようなコンピュータにアクセスを試みたユーザーを特定し、この情報をアクセスを許可されたユーザーの一覧と照合する必要があります。次の表では、未承認コンピュータの使用に起因するイベントを示します。 **表 4.16: 未承認コンピュータの使用に関するイベント**
イベント ID 発生事象 コメント
528 ログオンに成功しました。 [ワークステーション名] をチェックし、次に [ユーザー アカウント名] をチェックします。[ソース ネットワーク アドレス] が組織の IP アドレス範囲に含まれていることをチェックします。
530 ログオンに失敗しました — 許容時間外にログオンしようとしました。 このイベントは、許容時間外のログオン試行を示します。[ユーザー アカウント名] と [ワークステーション名] をチェックします。
[](#mainsection)[ページのトップへ](#mainsection) ### フォレンシック分析の実装 第 3 章「問題点と要件」で、フォレンシック分析はポリシー違反の検出や外部からの攻撃の特定とは根本的に異なることを説明しました。フォレンシック分析ではこのガイドで既に説明した多くの要素を使用しますが、このガイドでは分析と結果データの長期間の保管に重点を置いて説明しました。大部分のフォレンシック調査は、その後「ユーザー A のすべてのイベントの一覧」や「コンピュータ B からのすべての一覧」のような調査に進みます。 フォレンシック分析用のセキュリティの監視では、次のことを行う必要があります。 - 保管するイベントの種類を選択する。 - 毎日発生が予想されるイベントの数を計算する。 - オンラインでの保管、オフラインでの保管、アーカイブの保管の有効期限を決定する。 - 予想されるイベント数に対応できるようにオンライン データベースのサイズを決める。 - 予想される毎日の負荷に対応できるバックアップ システムを指定する。 - 保管システムを管理する方法を決める。 保管に関する要件は、次の 3 つの主な要因によって決まります。 - 記録する必要のあるイベントの数 - 対象のコンピュータでこのようなイベントが生成される比率 - この情報をオンラインで使用できるようにする期間 **注 :** オブジェクト アクセス以外のすべての監査カテゴリが有効なドメイン コントローラでは、1 時間に 3,000 ものセキュリティ イベントが生成される可能性があります。Event Comb MT から .CSV に保存されるこの情報は 1 MB に達します。オブジェクト アクセスの監査とプロセスの追跡を使用すると、この量が大幅に増加する可能性があります。 分析の結果、非現実的な保管の要件が計算されることがあります。このような場合は、監視するコンピュータの台数、監視するイベント数、およびこれらのイベントをオフラインの保管場所に移動する前にオンラインで保持しておく期間を比較検討する必要があります。 このガイドの付録 A 「除外する不要なイベント」では、有益な情報を提供しないイベントを示しています。この付録は、有益なセキュリティ情報を追加しないイベントを除外できるようにしています。 [](#mainsection)[ページのトップへ](#mainsection) ### まとめ 効果的なセキュリティの監視および攻撃検出システムは、ネットワークの整合性を維持するために不可欠なコンポーネントです。Windows のセキュリティ監査に基づく監視と攻撃検出ソリューションを計画する場合は、システムの目標についての包括的な知識が必要になります。また、ネットワークが影響を受けやすい脅威および各種の脅威に関連する攻撃の兆候についての詳細な評価も必要です。 Windows Server 2003 には、セキュリティ ログを使用するセキュリティの監視および攻撃検出のための基本的なコンポーネントが用意されています。マイクロソフトでは、Microsoft Operations Manager のようなサーバー ベースのコンポーネントから、複数のコンピュータのイベント ログを相互に関連付け、セキュリティ イベントを分析できる Event Comb MT ようなユーティリティまで提供しています。マイクロソフトのパートナーからも、攻撃の特徴を迅速に特定できる追加のツールやユーティリティが提供されています。 [](#mainsection)[ページのトップへ](#mainsection)