【ITニュース解説】Windows Event Logging You Will Actually Use in an Investigation

Windowsシステムを運用する上で、システムに何が起こっているかを記録するイベントログは、セキュリティとトラブルシューティングの観点から非常に重要だ。しかし、多くの組織では、大量のログを収集しているにもかかわらず、いざ問題が発生して調査が必要になった時に、本当に役立つ情報が不足しているという課題に直面している。この原因は、単にログの量が多いか少ないかではなく、必要な情報が記録されるように、Windowsのセキュリティポリシー設定が適切に有効化されていないためだ。システムエンジニアを目指す者にとって、インシデント発生時に迅速かつ正確な調査を行うためには、どのようなイベントが記録されるべきか、そしてそれがどのように役立つかを理解し、事前に適切な設定を行うことが不可欠となる。

まず、どのようなイベントを記録するかを決定する三つの主要な監査ポリシーカテゴリがある。一つ目は「プロセス作成」の監査だ。これは、システム上でどのようなプログラムが、どのようなコマンドライン引数（実行時の詳細な指示）と共に実行されたかという履歴を記録する。マルウェアの実行や攻撃者の活動において、エンコードされたペイロード、スクリプトインタープリタ、あるいは横方向への移動ツールなどの実行を示すコマンドライン情報は、インシデント調査において最も有用な手掛かりとなる。この情報がなければ、「何が実行されたのか」という基本的な問いに答えることが困難になる。

二つ目は「ログオン監査」だ。これは、ユーザーがシステムにログインしようとした際の成功または失敗、そして管理者権限でのログインなどを記録する。これらのログオンイベントは、システム上でのユーザーセッションのタイムラインを把握するために不可欠だ。ログオンの種類（インタラクティブ、ネットワークなど）、ログイン元のIPアドレス、誰がログインしたかというユーザーの識別情報は、不正なアクセス元や、どのユーザーアカウントが侵害されたかを特定するための重要な証拠となる。

三つ目は「PowerShellスクリプトブロックログ」だ。PowerShellはWindowsシステム管理に広く使われる強力なスクリプト言語だが、攻撃者も悪用することがある。この設定を有効にすると、PowerShellスクリプトが実際に実行されたテキスト内容が記録される。難読化されたスクリプトの実行内容も含まれるため、攻撃者がPowerShellを使って何を行ったかを詳細に把握できる。これらのカテゴリは、より新しい「高度なセキュリティ監査ポリシー（Advanced audit policy）」によって設定されることが多い。この高度なポリシーは、グループポリシーを通じて設定され、従来の監査カテゴリ設定を上書きするため、設定の競合に注意が必要だ。

これらの監査ポリシーが適切に設定されていれば多くのイベントが記録されるが、その中でも特に「アラートを出す価値があり、調査で積極的にクエリすべき」と見なされる特定のイベントが存在する。これらは、インシデントの初期段階で調査員が必ず尋ねる質問に答える情報を提供するからだ。

具体的な価値の高いイベントとして、次のようなものが挙げられる。既知のツールパターンに一致するコマンドラインを持つプロセス作成は、マルウェアや攻撃ツールに特有のコマンドライン引数パターンを検知することで、脅威を早期に特定できる。サービスのインストールは、攻撃者がシステムに常駐（持続性）するために、サービスをインストールすることがあるため重要だ。スケジュールされたタスクの作成または変更も、サービスと同様に、攻撃者が持続性を確立するためによく利用する。アカウントの作成とグループメンバーシップの変更は、攻撃者が特権を昇格させるために、新しいユーザーアカウントを作成したり、既存のアカウントを管理者グループに追加したりすることがあるため、注意が必要だ。明示的な資格情報の使用は、特定の資格情報が通常とは異なる方法や場所で使用された場合、その痕跡を記録する。そして、ログのクリアは、攻撃者が自身の痕跡を消すためにイベントログをクリアしようとすることがあるため、通常発生しないことから発生時は非常に注目すべき異常なイベントとなる。これらは、インシデント発生から最初の1時間以内に調査員が確認したい基本的な情報であり、事前に記録されていることを確認しておくことが極めて重要だ。

また、ログの「保存期間」と「アクセス制御」も、収集したデータが実際に使えるかどうかを左右する重要な要素となる。多くのインシデントは最初の侵入から数週間後に発覚することが多いため、ログの保存期間が短すぎると、初期の重要なイベント情報が失われている可能性がある。最低でも数週間、可能であれば数ヶ月間は、クエリ可能な形式でログを保持する必要がある。さらに、攻撃者がログを保存しているプラットフォームにアクセスできると、自身の活動の証拠を削除できてしまう。これを防ぐためには、本番環境のシステムを管理するIDとは異なる権限を持つ場所に、ログのコピーを保存することが推奨される。

最後に、これらの設定が適切に機能しているか、定期的に「検証する」ことが極めて重要だ。最も手早くログ収集のギャップを発見する方法は、何も異常が起こっていないクリーンなシステムで、実際にインシデント調査をシミュレーションしてみることだ。具体的には、四半期に一度など定期的に、次のような検証を行うことが推奨される。特定のサーバー上でセッションを開始したログオンと、そのログオン元IPアドレスが記録されているかを確認する。既知のサービスを開始したプロセスと、その実行時のコマンドライン情報が記録されているかを確認する。過去1ヶ月以内に行われたグループメンバーシップの変更が、問題なく検索可能かを確認する。意図的にログをクリアするイベントを発生させ、それがログ収集プラットフォームに記録されているかを確認する。サーバーだけでなく、ワークステーションでも同様のイベントが記録されているかを確認する。セキュリティポリシーの適用範囲が、運用チームの想定と異なることがよくあるためだ。これらの検証で失敗があった場合、それは設定変更で対応可能なギャップであり、半日程度の作業で完了する。この検証作業は、将来のインシデント発生時に役立つログが確実に収集されていることを保証するための、非常に価値のある投資となる。適切なWindowsイベントログの設定、保存、そして定期的な検証は、現代のサイバーセキュリティ対策において、システムエンジニアが果たすべき重要な役割の一つだ。これにより、もしもの時にシステムに何が起こったのかを正確に把握し、迅速な対応と復旧へと繋げることが可能となる。