セキュリティエンジニアとして、あるいは情報処理安全確保支援士として、最も重要なスキルのひとつが「ログを読む力」です。システムは常に稼働状況を記録していますが、平常時のログは単なるデータの羅列に過ぎません。しかし、ひとたびインシデントが発生した瞬間、それらのログは犯人を追うための「証拠」であり、被害の全貌を解明するための「ストーリー」へと変わります。
今週は、セキュリティの「目」とも言えるログ分析手法を中心に、SIEMによる統合管理、そして組織的なインシデント対応（CSIRT/SOC）まで、運用フェーズにおける防御と対応の要諦を学習してきました。本記事では、これまでの知識を総動員し、実際の攻撃者がどのような痕跡をログに残すのか、そしてそれをどのように検知・分析し、組織として対応していくべきかを深掘りします。
ログファイルという無機質なテキストデータから、攻撃者の息遣いを感じ取る。その感覚を養うことが、科目B（旧午後）の記述問題突破、そして実務における即戦力への近道となります。
この記事で学べること
- Apacheアクセスログ・Linux Syslog・Windowsイベントログ（4625/4624/4688/1102）から攻撃の痕跡を読み取る視点
- SIEMによるログの集約と相関分析の考え方、SOARとの違い
- CSIRTとSOCの一般的な役割分担と、NIST SP 800-61の4フェーズによるインシデント対応の流れ
- 証拠保全（揮発性の高い順の保全・ハッシュ値・Chain of Custody）とサイバー保険の位置づけ
- 科目A-2（旧午前II）・科目B（旧午後）での出題パターン
攻撃の予兆を捉える：ログ分析の基礎と視点
ログ分析は、砂漠の中から一粒のダイヤモンドを見つけ出すような作業に例えられます。しかし、漫然と眺めていては何も見つかりません。「何を探すべきか」という仮説と、「正常な状態とは何か」という基準が必要です。ここでは、代表的なログの種類と、そこで見るべきポイントを整理します。
Webサーバーログ（Apache/Nginx）の解読
Webアプリケーションへの攻撃は、そのほとんどがHTTPリクエストとしてWebサーバーのアクセスログに記録されます。Apacheの標準的なログ形式（Combined Log Format）を例に、攻撃の痕跡をどう読み解くかを見ていきましょう。
通常、アクセスログには「IPアドレス」「日時」「リクエストメソッドとパス」「ステータスコード」「転送バイト数」「リファラ」「ユーザーエージェント」が記録されます。ここで注目すべきは、ステータスコードとリクエストパスの組み合わせです。
例えば、HTTPステータスコード「200（OK）」は通常であれば正常な通信を示しますが、もし /admin/login.php に対して外部IPから数秒間に数百回のアクセスがあり、その全てが「200」だった場合、それは何を示唆しているでしょうか？ステータス200はHTTP上のリクエスト成功を示しますが、アプリケーション上のログイン成功を意味するとは限りません。多くのログイン画面は認証に失敗しても失敗画面を200で返すため、POSTリクエストでの200連発は、ブルートフォース攻撃やパスワードリスト攻撃を現在進行形で受けている可能性を示します。成功したかどうかは、後述するように応答サイズやステータスコードの変化を正常時・失敗時と比較し、認証ログなどで裏付けて判断します。
SQLインジェクション攻撃の痕跡
リクエストパスに含まれる異常な文字列は、攻撃の明確な証拠となります。以下はSQLインジェクション攻撃の典型的なログサンプルです。1行目は、入力値を文字列としてSQLに埋め込むアプリケーション（WHERE id = '入力値' のような形）を狙った例です（読みやすさのため、URLエンコードされた文字列をデコードして表示しています。実際のログでは %27（'）や %20（空白）などの形で記録されるのが一般的です）。
203.0.113.45 - - [21/Feb/2025:14:22:01 +0900] "GET /shop/item.php?id=1' OR '1'='1' -- HTTP/1.1" 200 4520 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
203.0.113.45 - - [21/Feb/2025:14:22:05 +0900] "GET /shop/item.php?id=1 UNION SELECT null, username, password FROM users -- HTTP/1.1" 200 12500 "-" "Mozilla/5.0..."このログから読み取れる重要なポイントは、URLパラメータに ' OR '1'='1' -- や UNION SELECT といったSQL特有のキーワードが含まれていることです。さらに注意すべきは、どちらのリクエストにもステータスコード200が返り、2行目では応答サイズが4520バイトから12500バイトへと大きく増えていることです。200だけでは攻撃の成否は判断できません（エラー画面も200で返ることがあります）が、UNION SELECT でユーザー名やパスワードを要求したリクエストの応答が大きくなっている点と合わせると、攻撃が成立してデータベースから情報が漏洩した可能性を示唆しています。ただし応答サイズはページの内容でも変わるため、同じページの正常時やエラー時の応答サイズ・ステータスと比較し、アプリケーションログやDBの監査ログで実際に実行されたクエリを確認して裏付けます。
ディレクトリトラバーサル攻撃の検知
サーバー内の非公開ファイルへのアクセスを試みる攻撃も、ログに明確な痕跡を残します。
203.0.113.8 - - [21/Feb/2025:03:15:10 +0900] "GET /../../../../etc/passwd HTTP/1.1" 404 280 "-" "curl/7.68.0"
203.0.113.8 - - [21/Feb/2025:03:15:12 +0900] "GET /images/../../../../windows/win.ini HTTP/1.1" 403 310 "-" "curl/7.68.0"../（親ディレクトリへの移動）が繰り返され、etc/passwd や win.ini などのシステムファイルを狙っていることが分かります。このケースでは404（未検出）や403（拒否）が返っているため、この試行は失敗した可能性が高いと読めます。ただし攻撃の成否はアクセスログだけで断定せず、エラーログやアプリケーションログでも確認します。継続的な試行が行われている事実そのものも、警戒すべきシグナルです。
ブルートフォース攻撃の特徴的パターン
ログインページに対する執拗なPOSTリクエストは、パスワードリスト攻撃やブルートフォース攻撃の典型的なパターンです。
198.51.100.22 - - [21/Feb/2025:23:55:01 +0900] "POST /admin/login.php HTTP/1.1" 200 3500 "-" "Python-urllib/3.8"
198.51.100.22 - - [21/Feb/2025:23:55:02 +0900] "POST /admin/login.php HTTP/1.1" 200 3500 "-" "Python-urllib/3.8"
198.51.100.22 - - [21/Feb/2025:23:55:03 +0900] "POST /admin/login.php HTTP/1.1" 302 420 "-" "Python-urllib/3.8"短時間に連続したPOSTリクエストが確認できます。多くのログイン画面は「認証失敗」でも画面を表示するためステータス200を返しますが、このアプリケーションでは失敗時のログイン画面が3500バイトだと分かっていれば、転送バイト数（サイズ）が同じ（3500）行は失敗画面が返され続けていると推測できます。そのため、まず正常時・失敗時の応答サイズやステータスを把握して比較することが前提になります。最後の行のようにステータスが302（リダイレクト）に変わりバイト数も変化している場合は、ログイン成功を示唆します（成功時にリダイレクトするかどうかはアプリケーションの挙動との照合が必要です）。成否は認証ログやアプリケーションログで裏付けます。
ユーザーエージェントから読み解く攻撃者の正体
ユーザーエージェント（UA）にも注目が必要です。一般的なブラウザ（ChromeやFirefox）ではなく、sqlmap（SQLインジェクションの検査・攻撃ツール）や Nikto（Webサーバーの脆弱性スキャナー）といったツールの名称がそのまま残っている場合や、極端に短い文字列、あるいは空欄である場合は、スクリプトやツールによる自動アクセスを疑う材料になります。ただしUAはクライアントの自己申告で、自由に偽装できます。
198.51.100.4 - - [21/Feb/2025:10:00:55 +0900] "GET /admin/phpmyadmin/ HTTP/1.1" 404 196 "-" "Mozilla/5.00 (Nikto/2.5.0) (Evasions:None) (Test:000001)"
198.51.100.4 - - [21/Feb/2025:10:00:55 +0900] "GET /wp-login.php HTTP/1.1" 404 196 "-" "Mozilla/5.00 (Nikto/2.5.0) (Evasions:None) (Test:000001)"このようにツール名が記録されているケースは、自動スキャンを疑う材料になります。ただしUAだけで攻撃と断定せず、許可された脆弱性診断ではないかを確認したうえで、アクセス先の内容や頻度と照合して判断します。
システムログ（Syslog/Windowsイベントログ）の深層
Web層を突破された後、あるいは内部不正の兆候を探るには、OSレベルのログが不可欠です。
Linux Syslogにおける認証ログの監視
Linux/Unix系で標準的な Syslog では、ファシリティ（出力元）と重要度（Severity）でメッセージが分類されます。特に auth や authpriv ファシリティは認証関連のログを記録するため、SSHのログイン試行などを監視する上で最重要です。
SSHブルートフォース攻撃の典型的なログを見てみましょう。
Feb 21 04:12:33 srv01 sshd[1205]: Failed password for root from 203.0.113.77 port 48293 ssh2
Feb 21 04:12:35 srv01 sshd[1207]: Failed password for invalid user admin from 203.0.113.77 port 48298 ssh2
Feb 21 04:12:38 srv01 sshd[1209]: Failed password for invalid user test from 203.0.113.77 port 48302 ssh2Failed password が同一IPから連続しています。invalid user は、SSHの認証対象として無効と判断されたユーザーを示します。多くは存在しないユーザー名での試行で、このように一般的なユーザー名が並ぶ場合は、攻撃者が有効なアカウント名を探索している可能性が高いと読めます（AllowUsers などのアクセス制限で許可されていないユーザーでも記録されることがあります）。
さらに深刻なのは、権限昇格の悪用が疑われるログです。
Feb 21 15:30:22 srv01 sudo: webadmin : TTY=pts/0 ; PWD=/var/www/html ; USER=root ; COMMAND=/bin/cat /etc/shadow一般ユーザー（webadmin）が sudo で root として /etc/shadow（パスワードハッシュファイル）を読むコマンドを実行した記録です。実際に閲覧できたかどうかは、コマンドの終了状態やsudoのI/Oログなどで確認します。Webコンテンツの管理用アカウントが業務で /etc/shadow を読む必要はまずないため、正規の作業記録と照合できなければ、アカウントの乗っ取りによる権限昇格や内部不正を強く疑うべき重大な痕跡です。また、cron のログに身に覚えのないスケジュール実行履歴がある場合、バックドアが設置された可能性があります。
Windowsイベントログの戦略的分析
Windows環境における イベントログ は、より構造化されたデータを提供します。ここで鍵となるのは「イベントID」です。膨大なIDの中から、セキュリティ上重要なものを押さえておくと、実務や科目B（旧午後）のログ読解に役立ちます。
イベントID 4625：アカウントのログオン失敗
ログの名前: Security
イベント ID: 4625
説明: アカウントのログオンに失敗しました。
ログオン タイプ: 3 (ネットワーク経由)
ログオンに失敗したアカウント:
アカウント名: admin
エラー情報:
失敗の理由: 不明なユーザー名または無効なパスワードです。
状態: 0xC000006D
サブステータス: 0xC0000064
ネットワーク情報:
ソース ネットワーク アドレス: 192.168.1.105
ソース ポート: 54321送信元（ソース ネットワーク アドレス）192.168.1.105 から、ネットワーク経由で、存在しない admin というアカウント名でのログオン試行が失敗しています。これが短期間に大量に発生していれば、ブルートフォース攻撃などのオンラインでのパスワード推測攻撃を受けている可能性が高いと判断できます。この例のように送信元が社内のプライベートアドレスであれば、社内の端末がすでに乗っ取られ、横展開の足がかりにされていることも疑います。
失敗の詳しい理由はサブステータスで見分けます。0xC0000064 は存在しないユーザー名、0xC000006A はユーザー名は正しいもののパスワードが誤っていることを示し、前述のSSHログの invalid user（多くは存在しないユーザー）と、Failed password for root（認証対象として有効なrootユーザーに対するパスワード認証の失敗。パスワード誤りのほか、rootログインの制限等でも生じる）の区別に近い考え方です。ただし invalid user はアクセス制限などでも記録されるため、0xC0000064と厳密に同じ意味ではありません。
イベントID 4624：アカウントへのログオン成功
これ自体は正常ですが、深夜帯や休日のログオン、あるいは普段使用しない管理者アカウントでのログオンは要注意です。ログオンタイプ（コンソール、ネットワーク、RDPなど）とセットで分析します。
イベントID 4688：新しいプロセスの作成
マルウェアが実行された瞬間や、攻撃者がコマンドプロンプトやPowerShellを起動した痕跡を捉えます。なお、このイベントは監査ポリシーで「プロセス作成の監査」を有効にしないと記録されず、コマンドラインの内容も「プロセス作成イベントにコマンドラインを含める」設定を有効にした場合にのみ記録されます（いずれも既定では無効）。
イベント ID: 4688
プロセス情報:
新しいプロセス名: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
作成元プロセス名: C:\Windows\System32\cmd.exe
プロセスのコマンド ライン: powershell.exe -NoProfile -ExecutionPolicy Bypass -EncodedCommand JABzACAAPQAgAE4AZQB3AC0ATwBiAGoAZQBjAHQAI...特に、PowerShellがエンコードされた長いコマンドライン引数とともに実行されている場合は、不正な実行を強く疑うべきです。-EncodedCommand オプションは、Base64でエンコード（難読化）されたコマンドを実行する際によく使われる手口で、マルウェア感染時によく見られるパターンです。ただし正規の管理ツールが使う場合もあるため、作成元プロセスや実行時間帯、実行ユーザーと合わせて判断します。
イベントID 1102：監査ログの消去
これは「証拠隠滅」のアクションであり、攻撃者が管理者権限を奪取した後に行う典型的な行動の一つです。セキュリティログの消去には（既定では管理者に付与される）「監査とセキュリティ ログの管理」権限が必要なため、正規の運用で消去した記録がないのにこれが記録されていた場合は、管理者権限が奪取されている前提で調査を進めるべきです。なお、1102はセキュリティログの消去を記録するイベントで、Systemログが消去された場合はイベントID 104が記録されます。
ログ分析における「正常性」の定義とベースライニング
異常を見つけるためには、「正常」を知らなければなりません。これを「ベースライニング」と呼びます。「普段のWebサーバーのトラフィック量はどのくらいか」「管理者がログインする時間帯はいつか」「サーバー上で通常動作しているプロセスは何か」。これらの「平時の姿」を把握していない管理者は、ログを見ても何が異常か判断できません。
例えば、定期的なバックアップ処理で深夜にCPU使用率が上がり、大量のファイルアクセスが発生するのは「正常」です。しかし、バックアップのスケジュールではない時間に同様のログが出れば、それはランサムウェアによる暗号化プロセスか、情報の持ち出し（エクスフィルトレーション）かもしれません。
ログ分析は、単なる文字列検索ではなく、システムの文脈（コンテキスト）を読み解く高度な推理ゲームなのです。
テンプレート集
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
点と線を面にする：SIEMと相関分析
単一のサーバー、単一のログファイルだけを見ていても、攻撃の全体像は見えません。攻撃者はWebサーバーを踏み台にしてデータベースサーバーへアクセスし、さらにActive Directoryへ横展開（ラテラルムーブメント）していくからです。こうした複数の機器にまたがるログを集約し、相関分析を行う仕組みが SIEM（Security Information and Event Management） です。
ログの統合管理が不可欠な理由
現代のネットワーク環境では、ファイアウォール、IDS/IPS、プロキシ、Webサーバー、DBサーバー、ADサーバーなど、多種多様な機器が稼働しています。攻撃者はこれらを縫うように移動します。
例えば、次のようなシナリオを考えてみましょう。
- ファイアウォールで特定の海外IPアドレスからのポートスキャンを検知（拒否）
- 数分後、Webサーバーで同じIPアドレスからWebアプリケーションへのアクセスがあり、200 OKが返る
- その直後、DBサーバーで大量のデータ検索クエリが発行される
- さらに数分後、ファイルサーバーから外部への大容量通信が発生する
これらを個別に見ていては、「Webへのアクセスがあった」「DBが忙しい」「ファイル転送があった」という断片的な事実に過ぎません。しかし、IPアドレスや時間軸をキーにしてこれらを相関分析すると、「ポートスキャンで入口を探られ、Webの脆弱性を突かれて侵入され、DBから情報を抜かれ、外部へ送信された」という一連の攻撃シーケンスの仮説が立ちます。ただしIPアドレスと時刻が近いだけでは因果関係は断定できないため、ホスト・アカウント・セッション・プロセスなどの情報で各イベントの関連を検証します。
SIEMの役割と相関ルールの設定
SIEMは、これらの異種混合のログを収集・正規化（フォーマットの統一）し、あらかじめ定義されたルールに基づいてリアルタイムに分析・アラート発報を行います。
重要なのは「どのようなルールを設定するか」です。「同一IPアドレスから1分間に10回以上のログイン失敗」といった単純な閾値ベースのルールから、「Webサーバーでの特定のエラー発生後、内部ネットワークへのスキャン行為を検知」といった複合的な条件設定まで様々です。
相関ルールの具体例を挙げると、以下のようなパターンが有効です。
- 「同一アカウントが5分以内に3つ以上の異なる拠点からログイン」→ アカウント情報の漏洩を示唆
- 「Webサーバーへの攻撃検知後30分以内に、同一IPから内部サーバーへの接続試行」→ 横展開の兆候
- 「深夜時間帯における特権アカウントの使用」→ 内部不正または権限窃取の可能性
また、SIEMはコンプライアンス対応やフォレンジック（事後調査）においても強力な武器となります。ログが一箇所に集約され、改ざん困難な状態で保存されていれば、万が一サーバー本体のログが攻撃者に消去されても、SIEM上のログから足取りを追うことが可能です。これをログの「保全」と言います。
ただし、SIEMは魔法の杖ではありません。導入しただけでセキュリティが強化されるわけではなく、適切なログソースの選定、ノイズ（誤検知）を減らすチューニング、そしてアラートを受け取った人間がどう動くかという運用設計があって初めて機能します。
SIEMとSOARの違い
SIEMとよく並べて語られるのが SOAR（Security Orchestration, Automation and Response）です。SIEMの中心は、ログを集約・正規化して相関分析し、アラートを上げる「検知と分析」です。これに対してSOARは、複数のセキュリティ製品やツールを連携させ、アラート受信後の調査や対応の手順をプレイブックとして自動化・効率化する「対応」側の仕組みです。例えば「不審なIPアドレスのアラートを受けたら、脅威インテリジェンスで評価を照会し、条件を満たせばファイアウォールに遮断ルールを追加してチケットを起票する」といった定型作業を自動で流します。
「ログの集約と相関分析」はSIEM、「対応手順の自動化」はSOARと区別しておくと、用語の説明を選ぶ問題で迷いにくくなります。
組織で立ち向かう：インシデントレスポンスと組織体制
ログ分析によって攻撃を検知したとき、次に求められるのは迅速かつ的確な「対応」です。ここで登場するのが CSIRT（Computer Security Incident Response Team）とSOC（Security Operations Center） です。
CSIRTとSOCの役割分担
試験や実務で混同されやすいこの二つの機能は、一般的には次のように分担します（体制は組織により異なり、両機能を同一組織が担う構成や、SOCをMSSP（マネージドセキュリティサービスプロバイダ）に委託する構成もあります）。
SOC（監視と検知のプロ）
SIEMなどの監視基盤をモニターし、ログを分析します。24時間365日体制をとることが多く、対応時間は組織や契約によって異なります。膨大なアラートの中から真の脅威を見つけ出し（トリアージ）、影響度を評価してCSIRTにエスカレーションします。彼らは「目」の役割を果たします。SOCアナリストは、誤検知（フォールスポジティブ）と真の攻撃を見分ける技術的な能力が求められます。なお、トリアージはアラートの真偽と優先度を判断する作業であり、端末の隔離などで被害の拡大を止める「封じ込め」とは別の段階です。
CSIRT（対応と調整のプロ）
SOCからのエスカレーションを受け、インシデント対応を主導します。被害拡大の防止（封じ込め）、原因究明、システムの復旧、経営層への報告、広報対応、警察やJPCERT/CCなどの外部機関との連携を行います。彼らは「脳」と「手足」の役割を果たします。技術的知識に加えて、マネジメント能力やコミュニケーション能力も不可欠です。
なお、システム停止などの判断を誰が下すか、どこまでをSOCとCSIRTが担うかといった判断権限と責任分担は、組織の規程や委託契約で事前に定めておきます。
ログ分析の結果、インシデントが確定した場合、CSIRTは事前に策定された「インシデントレスポンスフロー」に従って動きます。
インシデントレスポンスの4フェーズ
NIST（米国国立標準技術研究所）のSP 800-61 Rev.2（コンピュータセキュリティインシデント対応ガイド）が示すインシデント対応のライフサイクルは、以下の4段階で構成されます。なお、2025年4月に公開されたRev.3ではCSF 2.0の6つの機能（統治・識別・防御・検知・対応・復旧）に沿った構成へ改訂され、Rev.2は置き換えられましたが、この4段階は試験・実務の基本的な枠組みとして引き続き押さえておくべき考え方です。
1. 準備（Preparation）
平時の活動です。体制構築、連絡網の整備、ツールの導入、そして何よりログの取得設定がここに含まれます。「ログが出ていない」状態では、原因究明や影響範囲の特定が著しく困難になります。また、定期的な訓練（インシデントレスポンス演習）を実施し、手順書を最新化しておくことも準備フェーズの重要な要素です。
2. 検知と分析（Detection & Analysis）
SOCによる監視や、ユーザーからの通報によりインシデントを認知し、それが誤検知（フォールスポジティブ）でないかを確認します。影響範囲を特定するための詳細なログ分析もこのフェーズで行われます。どのシステムが侵害されたか、どのデータにアクセスされたか、現在も攻撃が進行中かを迅速に見極めます。
3. 封じ込め・根絶・復旧（Containment, Eradication, & Recovery）
被害を最小限にするための措置です。
- 封じ込め：感染端末をネットワークから切り離す、アカウントを停止する、ファイアウォールルールで通信を遮断するなど
- 根絶：マルウェアの駆除、脆弱性のパッチ適用、バックドアの削除、侵害されたアカウントの無効化
- 復旧：バックアップからのリストア、パスワードの変更、システムの再構築、業務再開
実務では、封じ込めを「短期的封じ込め」（即座にネットワークから隔離するなど、被害拡大を止める応急措置）と「長期的封じ込め」（暫定的な修正を施して業務を継続しながら、クリーンな環境の再構築を準備する）の2段階に分けて考えることもあります（SANSのインシデント対応手順などで用いられる区分です）。
4. 事後活動（Post-Incident Activity）
いわゆる「振り返り」です。なぜ起きたのか、対応は適切だったか、再発防止策は何かを議論し、プロセスを改善します。インシデント報告書を作成し、得られた教訓を組織全体で共有することで、次のインシデントへの備えを強化します。
この4段階は一方通行ではありません。検知・分析と封じ込め・根絶・復旧は行き来しながら進み（封じ込めの途中で新たな侵害が見つかれば分析に戻ります）、事後活動で得た教訓は準備へ戻されて次の対応に生かされます。
デジタルフォレンジックと証拠保全
インシデント対応において特に注意が必要なのが「証拠保全」です。慌ててサーバーを再起動したり、電源を切ったりすると、メモリ（RAM）上に残っていたマルウェアの活動痕跡や、揮発性のデータが永遠に失われてしまいます。
デジタルフォレンジックの原則は、「現状を維持すること」です。証拠は揮発性の高いもの（失われやすいもの）から順に保全します（RFC 3227）。レジスタやキャッシュ、メモリ、ネットワークの接続状態といった揮発性の高い情報を先に取得し、ディスクのような揮発性の低いものは後に回します。まずはメモリダンプを取得し、その後にディスクの複製（ビットストリームイメージ）を作成して、解析は複製データに対して行います。原本と複製のハッシュ値（現在はSHA-256などが推奨。MD5は衝突攻撃が現実的なため単独では避ける）を取得・比較して同一性を示し、原本は厳重に保管します。さらに、証拠を「いつ・誰が・どこで・何のために」取り扱い、受け渡したかを途切れなく記録します。この記録は、証拠の真正性・完全性と適切な取り扱いを説明し、法的手続で証拠として利用するための裏付けになります（証拠能力そのものは、法域のルールや収集の適法性などにも左右されます）。この取り扱い・受け渡しの記録の連鎖を「Chain of Custody（証拠の保管連鎖）」と呼びます。
ログファイルも重要な証拠です。攻撃者が侵入後にログを改ざんする可能性があるため、ログサーバーへのリアルタイム転送や、WORM（Write Once Read Many）メディアへの保存が推奨されます。また、ログには必ずタイムスタンプを記録し、時刻同期プロトコル（NTP）で全システムの時計を統一しておくことで、複数システムにまたがる攻撃シーケンスの時系列を正確に再現できます。
フォレンジック調査では、以下のような情報を収集・分析します。
- ネットワーク接続履歴（通信先IPアドレス、ポート番号、通信量）
- ファイルアクセス履歴（いつ、誰が、どのファイルに触れたか）
- レジストリの変更履歴（Windowsの場合）
- ブラウザ履歴、キャッシュ、クッキー
- 削除されたファイルの復元
これらの情報を総合的に分析することで、攻撃者の行動を時系列で再構築し、被害の全容を明らかにします。
リスクへの備え：サイバー保険という最後の砦
技術的な防御（ログ監視、SIEM、アンチウイルス等）と組織的な対応（CSIRT）を尽くしても、サイバー攻撃を100%防ぐことは不可能です。未知の脆弱性（ゼロデイ）や、従業員の些細なミスを突かれるリスクは常に残ります。
そこで、リスクマネジメントの観点から リスク移転（転嫁） の手段として検討されるのが「サイバー保険」です。
サイバー保険は、インシデント発生時の損害賠償金、調査費用（フォレンジックベンダーへの依頼費）、復旧費用、見舞金、さらには風評被害対策のコンサルティング費用などをカバーします（補償の範囲は商品・契約によります）。なお、日本の損害保険会社のサイバー保険では、ランサムウェアの被害で支払った身代金は補償の対象外です（日本損害保険協会）。海外には身代金を補償対象とする商品もありますが、身代金の支払いは攻撃者の資金源となり、支払ってもデータが戻る保証はなく、国や相手によっては支払い自体が法令上問題となる場合もあるため、慎重な検討が必要です。
しかし、保険はあくまで金銭的な補填であり、失われた社会的信用や、流出した重要データそのものが戻ってくるわけではありません。また、約款の免責事由（故意、補償項目によっては重大な過失）に当たる場合や、告知内容・加入条件を満たしていない場合には、保険金が支払われないことがあります。
保険加入時には、以下の点に注意が必要です。
- 補償範囲の確認：どのようなインシデントが対象か、免責事項は何か
- 保険料と補償額のバランス：自組織のリスクプロファイルに見合った設計か
- 保険会社の対応力：インシデント発生時のサポート体制は整っているか
- 加入条件の遵守：最低限のセキュリティ対策が実装されているか
「保険に入っているから安心」ではなく、「万全の対策をした上での最後のセーフティネット」として位置づけることが、情報セキュリティガバナンスの正しい在り方です。
SC試験での出題パターンと対策
ログ分析とインシデント対応は、科目A-2（旧午前II）では用語の区別として、科目B（旧午後）ではログを読み解く事例問題として問われます。ここでは、過去問で確認できる論点と、ログ読解問題への取り組み方を整理します。
科目A-2（旧午前II）の過去問で確認する
過去問で確認：SOARの説明
令和6年度秋期 情報処理安全確保支援士試験 午前II 問11は、SOARの説明を選ぶ問題で、正解は（ア）です。誤答の（エ）「ファイアウォール，マルウェア対策製品，侵入検知製品など複数のセキュリティ製品のログの集約及び相関分析を自動化するための専用装置」は、本文で説明したSIEMの役割に近い記述です。「ログの集約と相関分析」はSIEM、「対応手順の自動化・効率化」はSOARという区別がそのまま論点になっています。
過去問で確認：WAFのフォールスポジティブ
同じ令和6年度秋期 午前II 問12は、WAFにおけるフォールスポジティブ（偽陽性）を問う問題で、正解は（ア）です。フォールスポジティブは、正常な通信を攻撃と誤って判定してしまうことです。本文のSOCの説明で触れた「誤検知と真の攻撃を見分ける」作業や、SIEMのチューニングでノイズを減らす話は、まさにこの誤検知への対処です。反対に、攻撃を見逃すことはフォールスネガティブ（偽陰性）と呼び、両者を取り違えないようにしましょう。
過去問で確認：ディジタルフォレンジックス
平成28年度春期 情報セキュリティスペシャリスト試験 午前II 問14は、ディジタルフォレンジックスに該当するものを選ぶ問題で、正解は（エ）「犯罪に関する証拠となり得るデータを保全し，その後の訴訟などに備える」です。本文の証拠保全（揮発性の高い順の保全、ハッシュ値による同一性の確認、Chain of Custody）は、この「訴訟などに備えて証拠を保全する」目的を実現するための手順です。
科目B（旧午後）のログ読解問題の典型パターン
科目B（旧午後）では、ログを提示して攻撃の痕跡や対策を問う設問があります。設問は、おおむね次のような型に分けて考えると取り組みやすくなります。
パターン1：異常なログエントリの特定
複数のログエントリが提示され、攻撃と思われる行を指摘させる設問です。前述したSQLインジェクション、ディレクトリトラバーサル、ブルートフォース攻撃のパターンを知っていれば、該当行を見つけやすくなります。ステータスコード200だけで成功と判断せず、応答サイズや後続の行とあわせて読むのがポイントです。
パターン2：攻撃シーケンスの再構成
時系列で並んだ複数システムのログから、攻撃者がどのような手順で侵入したかを説明させる設問です。SIEMの相関分析の考え方を応用し、IPアドレスや時刻を手がかりに攻撃の流れを追跡します。
パターン3：対策の提案
検知された攻撃に対して、どのような対策を講じるべきかを記述させる設問です。技術的対策（WAF、IPS導入、パッチ適用）だけでなく、運用的対策（ログ監視強化、アカウント管理）、組織的対策（CSIRT体制整備）まで、多面的な視点が求められます。
解答作成のポイント
記述で得点につなげるためのポイントは以下の通りです。
- 具体的な根拠を示す：「不審なアクセスがある」ではなく、「同一IPから1秒間に50回のログイン試行があり、自動化されたパスワード推測攻撃が疑われる」と具体的に記述する（対象アカウントや試行パターンなども根拠にする）
- 影響範囲を明確にする：どのシステムが侵害され、どのデータが危険にさらされているかを特定する
- 優先順位を意識する：複数の対策を提案する場合、緊急度と重要度に基づいて順序付ける
- 技術用語を正確に使う：イベントID、ステータスコード、プロトコル名などを正確に記述する
実践演習：あなたならどう対応するか
ここで、インシデント対応の思考プロセスを鍛えるための演習問題を考えてみましょう。
ケーススタディ：Webサイト改ざんの通報
金曜日の夕方18時、自社の公開Webサイトが改ざんされているとの連絡が外部の取引先から入りました。あなたはCSIRTのメンバーとして、これから何をすべきでしょうか。
初動対応（最初の10分）
- 事実確認：本当に改ざんされているか、自分の目で確認する（スクリーンショット取得）
- 影響範囲の把握：どのページが改ざんされているか、ユーザー情報などの重要データは無事か
- 関係者への報告：上司、経営層、広報部門に第一報を入れる
- 証拠保全の指示：Webサーバーのログを触らないよう、運用チームに指示
- 一時的な措置：被害拡大防止のため、サイトを一時的に停止するか検討
初期調査（30分～1時間）
- ログ分析：Webサーバーのアクセスログ、エラーログを確認し、改ざん時刻を特定
- 侵入経路の推定：SQLインジェクション、アップロード機能の悪用、管理画面への不正ログインなど、可能性を洗い出す
- 他システムの確認：Webサーバー以外のシステムも侵害されていないか調査
対応方針の決定（1～2時間）
- 封じ込め：脆弱性が特定できた場合は即座に対策（アクセス制御、機能停止）
- 根絶：改ざんされたファイルや侵入経路（バックドア等）の特定と除去
- 復旧：侵入前の時点のクリーンなバックアップから復元
- 復旧計画：どの時点のバックアップを使用するか、復旧にかかる時間の見積もり
このように、インシデント発生時には冷静かつ迅速な判断が求められます。事前に手順書（プレイブック）を整備し、定期的に訓練を実施することで、本番での対応力が大きく向上します。
【演習】ログ分析とインシデント対応理解度チェック（全10問）
科目A-2（旧午前II）では、SIEMとSOARの説明の区別、WAFのフォールスポジティブ、ディジタルフォレンジックスの目的といった用語の理解が問われ、科目B（旧午後）ではログを提示して攻撃の痕跡や対策を問う設問があります。定番のひっかけは、ステータスコード200をログイン成功と読むこと、ログの集約・相関分析をSOARの役割と取り違えること、トリアージと封じ込めを混同すること、インシデント対応のフェーズを一方通行と考えることです。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ：ログから攻撃を読み解きインシデントに組織で立ち向かう
今週は、ログという「事実の記録」を起点に、検知、分析、そして組織的な対応までの一連の流れを学習しました。
重要ポイントの再確認
- ログはセキュリティの根幹：Apache、Syslog、イベントログの読み方をマスターし、正常と異常の差異を見抜く力を養う
- SIEMで点を線にする：複数のログを相関分析し、攻撃ストーリーを可視化する。単一のログでは見えない全体像を把握する
- 組織で動く：一般的にはSOCが検知・トリアージし、CSIRTが対応を主導する。体制は組織により異なるため、判断権限と責任分担を規程や契約で定め、連携を強化する
- 証拠を守る：フォレンジックの原則に従い、不用意な操作で証拠を消さない。Chain of Custodyを維持する
- リスク移転の手段：サイバー保険は最後のセーフティネットとして位置づけ、基本対策を怠らない
これらの知識は、科目B（旧午後）の記述問題でも問われる重要な領域です。「攻撃者がどの脆弱性を突き、どのログに痕跡を残し、管理者はどう対処すべきだったか」を問う問題において、具体的なログのエントリやイベントIDをイメージできるかどうかが、解答の解像度を決定づけます。
実践的な学習方法
知識を定着させるためには、実際に手を動かすことが重要です。
- 自分の環境でログを確認：お使いのWindows PCで「イベントビューアー」を開き、「Windowsログ」→「セキュリティ」を確認してください（閲覧には管理者権限、またはイベントログの閲覧を許可された権限〈Event Log Readersグループ等〉が必要です）。自分のログイン履歴（ID: 4624）を見つけられますか？
- Webサーバーのログを読む：もし開発環境やテスト環境があれば、Apacheやnginxのアクセスログを確認し、正常なアクセスパターンを把握しましょう
- SIEM製品の体験：Splunk、Elastic Security（Elastic Stack上のSIEM機能）などには無料版やトライアル版があります。実際にログを取り込んで相関ルールを設定してみると、理解が深まります
- インシデント対応演習：職場やコミュニティで、インシデントレスポンスの机上演習（テーブルトップエクササイズ）に参加してみましょう
来週への展望
来週からは、いよいよシステム運用と管理の深部へと進みます。パッチ管理、バックアップ戦略、そしてBCP（事業継続計画）。これらは「守り」の要であり、地味ながらも極めて重要な領域です。ログ分析で培った「異常に気づく力」をベースに、より堅牢なシステム運用の世界を学んでいきましょう。
週末は、ぜひご自身のPCやサーバーのログを実際に開いてみてください。そこには、教科書には載っていない「生きたシステムの声」があるはずです。その声に耳を傾け、対話する習慣をつけることが、真のセキュリティエンジニアへの第一歩となります。
[Next Step]
アクション課題
- お使いのWindows PCで「イベントビューアー」を開き、「Windowsログ」→「セキュリティ」を確認してください（閲覧には管理者権限、またはイベントログの閲覧を許可された権限〈Event Log Readersグループ等〉が必要です）。自分のログイン履歴（ID: 4624）と、もし失敗ログ（ID: 4625）があればそれも確認しましょう
- WebブラウザでF12キーを押して開発者ツールを開き、「ネットワーク」タブでHTTPリクエストとレスポンスを観察してください。ステータスコードの意味を理解できますか？
思考実験
もし今、あなたが管理しているWebサイトが改ざんされたと連絡を受けたら、最初の10分間で何をしますか？誰に連絡し、どのログを確認し、どのような一時措置を取りますか？手順を脳内でシミュレーションし、紙に書き出してみましょう。この思考訓練が、実際のインシデント発生時の冷静な判断力を養います。
本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。
参考資料
- NIST SP 800-61 Rev.2「Computer Security Incident Handling Guide」
- NIST SP 800-61 Rev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile」
- Microsoft Learn「4688(S): A new process has been created.」
- Microsoft Learn「1102(S): The audit log was cleared.」
- Microsoft Learn「4625(F): An account failed to log on.」
- RFC 5424「The Syslog Protocol」
- RFC 3227「Guidelines for Evidence Collection and Archiving」
- Apache HTTP Server Version 2.4「Log Files」
- 一般社団法人 日本損害保険協会「サイバー保険」
- IPA 令和6年度秋期 情報処理安全確保支援士試験 午前II 問題
- IPA 過去問題（平成28年度春期 情報セキュリティスペシャリスト試験 午前II を含む）
テンプレート集
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
