ログを取るだけで攻撃に気付ける？——ログの種類・時刻・通信の監視・SIEMを午後の問われ方で読む｜支援士解説3の4

この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）

この記事で分かること：

• ログの種類ごとに分かること・分からないことと、IPアドレスから端末・アカウント・人物へたどる手順

• 時刻同期とタイムゾーン、通信の監視、SIEMと検知ルール、ログそのものの保護

• 解答欄に書く「どのログで、何を調べるか」の型

シラバスとの対応：小項目3-4「セキュリティ監視とログ分析」。攻撃の段階と痕跡は支援士解説3の2、ファイアウォール・IDS・プロキシの仕組みは支援士解説3の5、アカウントの管理と認証の仕組み（Active Directoryを含む）は支援士解説3の8、監視の体制（SOC・CSIRT）は支援士解説4の1で扱います。

午後の問題では、テーマが何であってもログが登場します。インシデント対応、マルウェア、Webアプリ、認証。どの大問でも「このログから何が分かるか」「どのログを調べるべきか」が問われます。ログを取っていても、どこで記録されたか、時刻がそろっているか、何が記録されていないかを分かっていなければ、正しく読めません。

この記事では、ログの種類と読み方、結び付け方、時刻、通信の監視、SIEMと検知ルール、ログそのものの保護の順に整理します。

1. 監視は、記録から対応までの流れ

ログ、イベント、アラートは同じではない

イベントは、ログインや設定変更など、システムで発生した事象です。ログは、その事象や動作を記録したものです。アラートは、注意が必要な条件に該当した際の警告です。

例えば、一回のログイン失敗を記録するのがログ。その失敗が短時間に繰り返されたことを検知し、担当者へ知らせるのがアラートです。一回の失敗を必ず警告する設計もあり得ますが、すべてのログが警告になるわけではありません。

アラートが出た段階でも、パスワードの入力間違いなのか、不正な試行なのかは追加確認が必要です。逆に、アラートにならなかった記録が、後日の調査で重要になることもあります。

稼働監視とセキュリティ監視

稼働監視は、サーバが応答するか、処理が遅くないか、容量が足りているかなど、サービスを正常に動かすための状態を確認します。セキュリティ監視は、不正利用、侵入の兆候、権限の悪用などを見つけることに重点があります。

両者は完全に分かれるわけではありません。急激なCPU使用率の上昇は、正常な集計でも、攻撃や不正なプログラムでも起こり得ます。監視の数値だけでは原因を決められず、実行された処理や通信などと照合します。

そして、応答が正常でも、盗まれたアカウントで情報を読み出されている可能性はあります。サービスが動いていることと、安全に使われていることは別です。正常な応答や認証の成功は、正当な利用の証明ではありません。対処には、判断権限を持つ人と手順が必要です。

監視の目的を、具体的な問いにする

最初に決めたいのは、どの製品を使うかより、何を見つけたいかです。例えば、権限のない申請閲覧、保守用アカウントの予定外利用、大量のデータ出力、ログ取得設定の無効化などです。

その問いから、必要なログ、分析条件、通知先、対応を逆算します。大量出力を検知したいのに、画面へのアクセスしか記録されず、出力件数や結果が残らないのでは判断材料が足りません。

また、すぐ通知すべき事象と、定期的にレビューすべき傾向を分けます。管理者権限の不審な付与は迅速な確認が必要でも、長期的な利用傾向は一定期間をまとめて確認する方が分かりやすい場合があります。

記述の型

• 監視の設計：「見つけたい事象から逆算して、必要なログの種類と項目、検知の条件、通知先、対応を決める」

• 足りないログへの対策：「調べたい操作（出力の件数など）を記録する項目を追加し、調査に必要な期間を保存する」

2. どのログで、何が分かるか

OSと認証のログ

OSのログには、サービスの起動・停止、システムのエラー、アカウントや監査設定の変更などが記録されます。どこまで記録されるかは、OSと監査設定によります。

認証のログでは、ログインの成功・失敗、対象アカウント、認証方法、接続元などを確認します。ただし、成功とは認証の条件を満たしたという意味であって、本人が意図した利用であることまでは証明しません。認証情報やセッションが盗まれる場合もあるからです。

特権の付与、アカウントの作成、認証要素の変更、監査機能の停止も重要です。ログインだけを見ていると、侵入後の権限昇格やログ消去の兆候を見落とします。

ファイアウォールとIDS／IPS

ファイアウォールのログは、送信元、宛先、ポート、プロトコル、許可・破棄などを記録します。通過を許可された通信であっても、その中身が無害とは限りません。業務で必要なポートを開けていれば、攻撃の通信も許可の記録として残る場合があります。

IDS／IPSの記録では、検知した規則、時刻、関係する通信、機器の動作（通知のみか遮断したか）を確認します。危険な通信を検知したという記録があっても、動作が遮断でなければ通信が通っている可能性があります。

また、ミラーポートやTAPで通信を取り込む構成では、高負荷時の取りこぼしや、暗号化された中身をそのままでは見られない制約を把握しておきます。

ファイアウォールのログで、通信の向きを読む

ファイアウォールのログでは、どちらから接続を始めたかを読みます。外から内への接続が拒否され、内から外への接続が許可されている構成なら、外で待ち受けるサーバへ内側から接続しにいく通信は通ります。例えば、マルウェアが端末でポートを開いて攻撃者からの接続を待つ方式（バインドモード）は、ファイアウォールで拒否されやすい一方、マルウェアの側から攻撃者のサーバへ接続する方式（コネクトモード）は、許可された外向きの通信として記録されます。

FTPも、向きの違いが出る例です。アクティブモードでは、データ用の接続をサーバからクライアントへ始め、パッシブモードでは、クライアントからサーバへ始めます。同じファイルの転送でも、ログに残る通信の向きが逆になります。

Web・アプリケーション・データベース

Webサーバのアクセスログの1行は、例えば次のようになっています（説明用の例）。

203.0.113.5 - - [15/Sep/2026:09:10:00 +0900] "GET /search?q=test HTTP/1.1" 200 5120

先頭から、接続元のIPアドレス、日時（末尾の+0900は、UTCより9時間進んだ日本時間）、要求の内容（メソッドとURL）、応答コード、応答したデータの大きさ（バイト）です。

Webサーバのログには、クライアントのIP、日時、要求メソッド、要求URL、応答コード、送信バイト数などが残ります。応答コード200は要求が処理されたことを示しますが、業務として成功したか、エラー画面を正常に返しただけなのかは、中身やアプリケーションの記録を見ないと分からない場合があります。

アプリケーションのログでは、誰が、どのデータに対して、どんな処理（照会、更新、削除、出力）を行ったかを記録します。機密情報を扱う業務では、画面アクセスだけでなく、検索条件や出力件数、完了結果を残すことが重要です。

データベースの監査ログでは、実行されたSQLや接続元を追跡できます。Webシステムでは、共通のアカウントで接続プールを使う構成が多く、データベース側の記録だけでは画面を操作した個別利用者を特定しにくいことがあります。アプリケーション側で一意の処理識別子を渡すなどの工夫が必要です。

ログに残らないものを知る

Webサーバのアクセスログには、通常、要求のURLは残りますが、POSTメソッドで送られた本文（ボディ）は残りません。URLのパラメータに攻撃の文字列があれば記録されますが、POSTの本文に入れられた攻撃の内容は、アクセスログだけでは分かりません。調べたいことに対して、どのログのどの項目が必要かを、前もって決めておく理由です。

プロキシ・DNS・DHCP

プロキシのログは、外部へのWebアクセスのURL、時刻、認証アカウントなどを記録します。暗号化通信の復号を行わない構成では、ドメイン名や宛先IPは分かっても、細かなパスや送信データが見えない場合があります。

DNSのログは、名前解決の要求と応答を記録します。不審な接続先を探す手がかりになりますが、名前解決の成功は、その後のHTTP通信などの成立そのものとは別です。

DHCPのログは、どの機器に、いつ、どのIPアドレスが割り当てられたかを記録します。プライベートIPアドレスから端末をたどる際に不可欠です。

Windowsのイベントログ

Windowsでは、ログオンの成功・失敗、アカウントの作成や権限の変更、監査ポリシーの変更、ログの消去などが、イベントIDとともにセキュリティログに記録されます。ログオンの記録には、対話的なログオンか、ネットワーク経由か、リモートデスクトップ（RDP）か、といったログオンの種類も残ります。ドメインの環境では、ドメインコントローラに認証の記録が集まるので、多くの端末へのRDP接続の試行のような横展開の痕跡を、一か所で探せます。

プロセスの起動を記録する設定にしておけば、どのプロセスが、どの親プロセスから起動されたかも追えます。不審なプロセスを調べるときは、起動の順番だけでなく、親子関係を見ます。

特権の操作を記録する

サーバの管理者や保守員の操作は、ログインの記録だけでは中身が分かりません。踏み台サーバを経由させ、そこで操作を記録する方法があります。記録の対象は、ログインした利用者の画面、実行したコマンド、キーボードの入力などです。操作ログは、操作される側ではなく別の場所に保存し、操作した本人が消せないようにします（特権IDの管理は支援士解説3の8）。

クラウド・メール・エンドポイント（EDR）

クラウドサービスでは、管理操作、外部共有、データダウンロードなどが監査ログとして残ります。サービスごとに取得可能な項目や保存期間が異なるため、重要な記録をどう保全するかをあらかじめ確認します。

メールサーバのログでは、送受信の経路、アドレス、配送結果などが分かります。メールが届いた記録は、利用者が添付ファイルを開いたりリンクをクリックしたりした証拠とは別です。

端末の監視では、EDRなどからプロセス、ファイル操作、通信等を確認できる場合があります。ネットワーク側で不審な接続を見つけ、端末側でどのプログラムが行ったかを調べる、というつなぎ方ができます。ここまでの各ログは、それぞれ一部しか見ていません。通信許可はルール上の判断、通信成立と業務の成功は別、検知の記録と遮断結果も別に読みます。中継通信の記録、クラウドの取得範囲と契約条件、権限変更の記録も確認し、一つのログの結果を業務全体の成功や安全へ広げないようにします。

午後での問われ方

• 令和6年度秋期 午後問1：端末のログ（ファイル、サービス、通信、認証）とプロキシサービスのログから、マルウェアの動きを追う問題でした。認証の記録には、ドメインのアカウントやローカルの管理者アカウントで、ほかの端末へRDP接続を試みて失敗・成功した記録が並びます。

• 令和4年度春期 午後I問2：ネットワーク機器のWeb管理機能に、POSTメソッドでOSコマンドを送り込まれた事案が題材でした。実行されたOSコマンドの内容がアクセスログから分からなかった理由として、解答例は「POSTメソッドで送信したボディがアクセスログに残っていなかったから」です。

• 令和5年度春期 午後I問2：Webアプリのライブラリの脆弱性に起因する不正アクセスの調査が題材でした。FTPのデータ用の接続がファイアウォールのログにどう残るかを読ませ、解答は「パッシブ」モードです。また、マルウェアが自ら待ち受けるバインドモードの通信はファイアウォールで拒否されていた一方、内側から接続を始めるコネクトモードの通信は許可されていたことを、プロセスの起動、ポートの利用、ファイアウォールの記録を組み合わせて読み取らせています。

• 平成30年度春期 午後II問1：セキュリティ対策の評価が題材で、踏み台サーバの操作記録機能によって記録する内容として、解答例は「ログインした利用者のデスクトップ画面、実行したコマンド、及びキーボード入力」です。

• 令和4年度秋期 午後I問2：不審なプロセスを調べる設問で、解答例は「runプロセスの親プロセスがTソフトのプロセスであるから」です。

採点講評で指摘されたつまずき

• 令和5年度春期 午後I問2では、FTPのアクティブモードとパッシブモードのデータ用の接続が、ファイアウォールのログにどう記録されるかを問う設問の正答率が低かったとされています。アクティブモードはサーバからクライアントへ、パッシブモードはクライアントからサーバへ接続するので、記録される向きが逆になります。

• 令和4年度秋期 午後I問2では、プロセスの起動の順序を説明する解答が散見され、不審なプロセスの調査では親子関係を調べる必要性も認識してほしいとされています。

• 令和6年度秋期 午後問1では、マルウェアの活動を検出する仕組みを問う設問で、どのログを確認するかの記述がない解答が多かったと指摘されています。マルウェアの動作によって、どのログに何が記録されるかを考えて、検知の仕組みを設計します。

記述の型

• 検知の仕組み：「（どのログ）から、（どの動作）をした端末を検出する」と、ログの種類まで書く

• アクセスログの限界：「POSTメソッドの本文は、アクセスログに記録されない」

• 不審なプロセスの調査：「親プロセスを確認し、何をきっかけに起動したかを調べる」

3. 誰の操作かを結び付ける：IPアドレスだけで決めない

共通して残したい項目

記録する項目は、目的とシステムの特性に応じて決めます。基本となるのは、いつ、どこで、どの主体が、何に対して、何を行い、結果はどうだったかです。

例えば、申請データの出力であれば、発生時刻、システム名、利用者の識別子、出力対象の識別子や範囲、操作名、件数、成功・失敗、要求IDなどが候補になります。

氏名や申請本文を丸ごと記録する必要があるとは限りません。調査に必要な識別子で対応付け、内容自体へのアクセスは別に制御する設計も考えられます。どこまで残すかは、後で調べたいことと情報管理上のリスクの両面から判断します。

アカウント、端末、人物を分けて考える

IPアドレスが分かったことと、誰が操作したかが分かったことは同じではありません。DHCP・NAT・VPNなどを経由すると、記録される接続元の意味が変わります。中継経路と業務操作の記録まで照合して、ようやく人物の確定に近づきます。

• アカウント：ログインに使われたID。盗難や共用の可能性を考慮します。

• 端末：IPアドレスやMACアドレス。DHCPやNATにより、時刻によって機器が変わることがあります。

• 人物：実際に操作した職員。端末の利用記録、座席、入退室の記録などで確認します。

例えば、ある内部IPアドレスからの通信があった場合、その日時にそのIPアドレスがどの端末に割り当てられていたかをDHCPのログで確かめます。さらに、その端末に誰がログインしていたか、その時間帯に本人が在席していたかを確認して、はじめて人物につながります。

中継機器を挟むときの送信元情報

リバースプロキシやロードバランサを挟むと、後段のWebサーバから見た接続元が中継機器のIPアドレスになる場合があります。これでは、本当の接続元が分かりません。

このため、X-Forwarded-ForなどのHTTPヘッダを利用し、元のクライアントIPを中継機器から後段へ渡す構成がよく使われます。

ただし、このヘッダはクライアント側が自由に設定して送信することも可能です。外部からの入力をそのまま信じると、偽のIPアドレスを記録させられるおそれがあります。信頼できる自組織のリバースプロキシだけがこのヘッダを設定・追加する構成にし、外部からの直接アクセスは遮断するなどの設計が必要です。MDN「X-Forwarded-For」、Security and privacy concerns

要求IDで、一連の処理を結ぶ

画面の表示からデータベース照会まで、複数のサーバを経由して処理が進む構成では、各サーバのログを突き合わせるのが難しくなります。

入り口で一意の要求ID（リクエストID）を発行し、後段の処理やデータベースアクセスにも引き継いで記録すると、一連の処理を追いやすくなります。

外部から渡されたIDを使う場合には、形式や長さを確認し、重複や偽装があり得ることも考慮します。認証に使うセッショントークンそのものをログに出すことと、調査用の識別子を記録することは別です。

午後での問われ方

• 平成28年度秋期 午後I問3（情報セキュリティスペシャリスト試験）：プロキシサーバを2段にした構成で、外側のプロキシのログだけでは送信元のPCを特定できない理由として、解答例は「送信元IPアドレスがプロキシ1のIPアドレスとなるので」です。対策として、内側のプロキシで送信元を示すHTTPヘッダを付け、外側のプロキシでそれをログに出力する設定にしています。

• 令和7年度秋期 午後問3：リモートワーク環境の導入が題材でした。古い版のOSを使い続けている社有PCへの対応として、解答例は「Kサービス接続時のログからOSがバージョンXの社有PCを抽出し、アカウント名から利用者を特定後、利用者の所属する部の情報セキュリティ推進者に報告し、バージョンYへの移行を促してもらう」です。接続のログから端末を抽出し、アカウントから利用者へたどり、対応する担当者へつなぐ流れが、そのまま答えになっています。

採点講評で指摘されたつまずき

• 平成28年度秋期 午後I問3では、ログから送信元のPCを特定できない理由と、プロキシサーバが処理するHTTPヘッダを問う設問の正答率が、いずれも低かったとされています。

記述の型

• 社内IPアドレスから端末を特定する：「DHCPのログで、その時刻の割当てを確認する」

• 中継機器を挟むときの接続元：「信頼できる自組織の中継機器が付けたヘッダの値だけを使う」

4. 時刻同期とタイムゾーン：時間の順番を間違えない

NTPは時計を合わせる仕組み

NTPはNetwork Time Protocol、機器間で時刻を同期するためのプロトコルです。NTPv4の基本仕様はRFC 5905で定義され、NTPサービスは通常UDPの123番ポートを使います。RFC 5905、NTPv4

複数機器の時計がずれていると、先に起きた操作が後に見えたり、同じ処理を別の事象と誤認したりします。相関分析の前提として、同期先、許容するずれ、同期不能時の通知を決めておきます。

NTPを設定しただけで、常に正確な時刻を使えると考えるのも危険です。同期先へ到達できない、端末の時刻が手動変更された、同期先の状態がおかしい、といった可能性があります。同期の状態と時計のずれを監視します。

通信相手の認証や改ざんへの対策も検討対象です。NTPの通信を保護する仕様としてNTSがRFC 8915に定められています。ただし、実際の対応状況を確認して設計するもので、すべてのNTP通信が自動的にこの保護を受けるわけではありません。RFC 8915、Network Time Security

UTCとJSTは、時計の故障ではない

UTCは協定世界時、JSTは日本標準時です。JSTはUTCより9時間進んでいます。

例えば、次の二つは同じ瞬間です。

2026-09-15T00:10:00Z
2026-09-15T09:10:00+09:00

この表記のZはUTCを表し、+09:00はUTCから9時間進んでいることを表します。どちらかの時計が9時間ずれているのではありません。比較時に同じ基準へ変換します。

日付も注意が必要です。9月14日の18時30分UTCは、JSTでは9月15日の3時30分です。時刻だけを変換して日付を据え置くと、一日違う出来事になってしまいます。

記録にタイムゾーンがなければ、機器の設定やログ仕様を確認します。見た目から日本の機器だからJSTだろうと推測してはいけません。

時刻を補正する実例

プロキシのログ（日本時間）に、不審な通信が次のように記録されていたとします。一方、DHCPのログはUTCで記録されています。

プロキシ：2026-09-15 09:10  10.20.5.18 → 不審なサイト
DHCP    ：2026-09-15T00:05:00Z  10.20.5.18 を PC-X に割当て

DHCPのログのZはUTCを表します。日本時間に直すと9時間を足して9時5分なので、不審な通信の5分前に、そのIPアドレスがPC-Xに割り当てられていたことになります。補正せずに比べると、プロキシのログが9時間後の出来事に見え、結び付けられません。次に、9時10分ごろにPC-Xでログオンしていたアカウントを、ログオンの記録で調べます。

発生時刻と収集時刻を分ける

9時10分に発生したイベントが、転送遅延のため9時15分に監視基盤へ届くこともあります。受信順が発生順と一致するとは限りません。

イベントの発生時刻と収集・取込み時刻を別に持つと、調査と転送遅延の把握に役立ちます。タイムゾーンをそろえても、元の時計自体のずれは解消しないことにも注意してください。

既にずれがあるログを調べるときは、元の記録を残したうえで、補正の根拠と不確かさを明記します。ずれが2秒程度あり得るのに、1秒差の記録から厳密な前後関係を断定するのは避けます。原本の時刻を上書きしてしまうと、後から補正の妥当性を確認しにくくなります。

午後での問われ方

• 平成30年度秋期 午後II問2：インシデント対応の準備として、ログの管理方針が問われました。取得するログについて決める事項は「ログを取得する機器」「取得するログの種類」「保存期間」、各機器のログに記録する時刻情報については「タイムゾーン」を「統一」することが、解答例に示されています。

採点講評で指摘されたつまずき

• 平成30年度秋期 午後II問2では、タイムゾーンを問う設問の正答率が低かったとされています。インシデントの発覚時には、様々な機器のログを見比べて経緯を調べます。各ログの時刻が正しく、タイムゾーンが同じであることが重要で、タイムゾーンが違うと、認識の違いで調査が難航する場合があります。

記述の型

• 時刻の前提：「各機器の時刻をNTPで同期し、ログに記録するタイムゾーンを統一する」

• 比較するとき：「UTCとJSTの9時間の差を補正し、日付も合わせて比較する」

5. 通信の監視：流れ・中身・量を見る

フロー情報とパケットキャプチャ

ネットワークの通信を監視する方法には、主に二つあります。

• フロー情報：通信ごとに、開始の日時、送信元と宛先のIPアドレス・ポート番号、プロトコル、通信量などのヘッダの情報を記録する。中身は残らないが、データ量が小さく、長い期間を保存しやすい

• パケットキャプチャ：通信のパケットそのものを記録する。中身まで調べられるが、データ量が大きい。暗号化された通信の中身は、そのままでは読めない

スイッチのミラーポートやTAPで通信を取り込み、IDSやネットワークの監視装置（NSMのセンサ）に送る構成がよく使われます。

見えない範囲を知る

監視の装置は、通った通信しか見えません。

• 同じスイッチにつながった端末同士の通信は、上位に置いたセンサを通らない。同じセグメントの中だけをスキャンするワームは、そこでは見つからない

• 暗号化された通信の中身は、復号しなければ検査できない

• 監視の装置が高負荷で取りこぼした通信は、記録に残らない

普段の量と比べる

通常時の通信量や、日・週・月・年の中での推移（通常時のプロファイル）を把握しておくと、それとの比較で異常に気付けます。夜間の大量の送信や、普段通信しない宛先への通信は、手掛かりになります。

中身の特徴と、時間の並びを見る

• HTTPのヘッダ：プロキシのログに残るUser-Agentヘッダの値は、ブラウザの種類を示す。ただし、マルウェアが組織で使っているブラウザと同じ値を名乗れば、その値だけでは見分けられない

• 規則正しい間隔：同じ宛先への通信が、ほぼ一定の間隔で記録されていれば、人の操作ではなく、マルウェアが定期的に外部へ接続している疑いがある（支援士解説3の2）

プロキシを迂回する通信を探す

プロキシのログだけを見ていると、プロキシを通らない通信を見落とします。マルウェアがプロキシ認証に失敗した後で、IPアドレスを直接指定してインターネットへ接続したり、組織外のパブリックDNSサービスへ問い合わせたりすることがあります。こうした通信は、ファイアウォールのログに残ります。端末からの直接の通信を禁止していても、許可・拒否の記録を確かめます。特定のドメインへの大量のDNSの問合せは、DNSを悪用した通信の兆候です。

午後での問われ方

• 平成30年度秋期 午後I問2：ワームの感染を題材に、シグネチャ型のIDSの機能と、ネットワークフロー情報（コネクションの開始日時、送信元・宛先のIPアドレスなど）を記録する機能を持つNSMのセンサが登場しました。感染したPCと同じセグメントだけをスキャンする動きが、センサの記録で上位に出てこない理由として、解答例は「パケットがNSMセンサの監視対象外であるため」です。

• 平成30年度秋期 午後II問2（4.と同じ問題）：取得した通常時のプロファイル（ネットワークトラフィック量やその推移）の利用方法として、解答例は「ネットワークトラフィック量と比較して異常を検知する」です。

• 令和元年度秋期 午後II問2：工場のランサムウェアの感染が題材でした。プロキシのログに記録されたUser-Agentヘッダの値から、マルウェアによる通信だと判定しにくいケースとして、解答例は「User-Agentヘッダフィールドの値がA社で利用しているWebブラウザを示す値であるケース」です。

• 令和元年度秋期 午後I問2：脅威インテリジェンスの活用とC&C通信への対策が題材でした。マルウェアのHTTP通信が外へ出られなかった理由は「プロキシ認証に失敗したから」です。そのうえで調べるべきログとして、「グローバルIPアドレスMへのHTTP通信成功のログ」と「パブリックDNSサービスLへのDNS通信成功のログ」が、解答例に示されています。

• 令和6年度秋期 午後問1（2.と同じ問題）：プロキシのログに、同じ接続先への通信がほぼ1時間おきに記録されており、拒否されると別の接続先へ切り替えていました。

採点講評で指摘されたつまずき

• 平成30年度秋期 午後I問2では、同じセグメントの中をスキャンする場合に、ネットワークの構成上、NSMではパケットを取得できないことを正しく理解していない解答が多かったとされています。

• 令和元年度秋期 午後I問2では、調べるべきログを問う設問の正答率が低く、具体性が不十分な解答が多かったとされています。「どの機器の、どの宛先への、どの通信の成功ログか」まで書きます。

• 令和元年度秋期 午後II問2では、社外とやり取りされるHTTPのメッセージを監視してマルウェアを発見する手法について、正答率が低く、HTTPメッセージの構造やヘッダフィールドの理解を深めてほしいとされています。

記述の型

• 監視で見えない理由：「その通信が、センサの監視対象の経路を通らないため」

• 通常時の通信量を把握する目的：「通常時と比較して、異常を検知するため」

• 規則正しい間隔の通信：「マルウェアが定期的に外部へ接続している疑いがある」

6. SIEM・SOC・SOAR：道具と運用体制を分ける

SIEMは、複数のログを分析する基盤

SIEMはSecurity Information and Event Managementの略です。さまざまな機器・サービスからログを集め、検索・分析し、条件に応じて警告するための基盤です。

集めるだけでは、各ログの項目名や時刻表現が異なるため、まとめて扱いにくいことがあります。そこで、データから項目を取り出すパース、同じ意味の項目を共通の形にそろえる正規化、複数の記録の関係を見る相関分析などを行います。

例えば、あるログの「src_ip」と別のログの「sourceAddress」が同じ意味なら、共通の項目として扱えます。ただし、片方が接続元IP、もう片方が中継装置のIPなら、項目名をそろえただけで同じ意味にはなりません。

正規化と相関分析の基本は、NIST SP 800-92（2006年）の3.2節でも説明されています。本稿では基礎概念の参照として用い、当時の製品機能や推奨設定を現在へそのまま当てはめるものではありません。NIST SP 800-92、3.2節

SIEMに集める前に決めること

SIEMを入れても、集めるログが決まっていなければ、見つけたいことは見つかりません。次を前もって決めます。

• 何を見つけたいかから逆算した、集めるログと項目

• 時刻の基準：発生時刻とタイムゾーンをそろえ、取込みの時刻も別に持つ

• 項目の意味：接続元のIPアドレスが、本当の利用者のものか、中継機器のものか

• 保存と検索の期間：調査に必要な期間を、すぐ検索できる状態で残せるか

• 警告の行き先：誰が受け取り、どこまで調べ、誰へ引き継ぐか

SOCは、監視と分析を担う組織・機能

SOCはSecurity Operations Centerの略です。セキュリティ監視、警告の確認、ログ分析などを担う組織や機能を指します。自組織で持つ場合も、外部サービスを利用する場合もあります。

SIEMを導入することは、SOCの担当者や対応権限を用意することではありません。逆に、SOCがあっても、契約対象外のサービスや未接続の機器のログは見えない可能性があります。

CSIRTは、インシデント対応を進めるためのチームです。SOCが検知・分析した内容をCSIRTへ引き継ぎ、関係部署や事業者との調整、被害拡大防止、復旧などにつなぐ構成が考えられます。ただし、組織ごとに役割は重なるため、名称より実際の責任分担を確認します。

SOARは、対応手順を連携・自動化する

SOARはSecurity Orchestration, Automation and Responseの略です。製品間の連携や、情報収集、通知、承認、対処などの手順を自動化・効率化する仕組みです。あらかじめ定めたワークフローをプレイブックと呼ぶことがあります。

例えば、警告を受けて関連ログと資産情報を収集し、担当者へ確認を求め、承認後に対象端末を隔離する、といった流れです。すべてを無人で決めることが必須ではありません。

自動化するなら、何を根拠に動作するか、誰の権限で実行するか、誤った場合にどう戻すか、実行結果をどう確認するかを決めます。端末隔離を要求できたことと、端末が実際に隔離されたことは違います。

実製品ではSIEMとSOARの機能が一体になっていたり、SIEMから対処できたりする場合もあります。名称だけで機能を排他的に分けず、収集・判断・実行・確認のどこを担うかで整理してください。

午後での問われ方

• 令和7年度春期 午後問2：公開サイトの脆弱性管理が題材でした。サーバへの攻撃に早く気付くための運用として、解答例は「OpenSSHのログに認証タイムアウトのメッセージの出力が多数あったらサイト担当者に電子メールでアラートを送る」です。どのログの、どのメッセージが、どれだけ出たら、誰に、どう知らせるか、という形で書かれていることに注目します。

記述の型

• アラートの条件：「（どのログ）に（どのメッセージ）が（多数・しきい値を超えて）出力されたら、（誰）に（どの手段で）アラートを送る」

• SIEMの役割：「複数の機器のログを集めて正規化し、相関分析して、条件に応じて警告する」

• SOARの役割：「情報の収集、通知、端末の隔離などの対応手順を、プレイブックに沿って連携・自動化する」

• SIEMとSOCの違い：「SIEMは分析の道具、SOCは監視と分析を担う人と体制」

7. 架空のログを突き合わせてみる

まず、分かっている条件をそろえる

職員のアカウントから申請データが大量に出力された、という場面（1.で、見つけたいことの例に挙げたもの）を、もう少し具体的に考えます。以下は説明用に作成した架空のログです。製品固有の形式ではありません。時刻同期が正常で、時刻の精度は秒単位、要求IDはこの例の対象内で一意とします。

認証サービスはUTC、アプリケーションとDHCPサーバはJSTで記録しています。接続元のIPアドレスは、信頼する経路で記録されているものとします。

認証ログ
2026-09-15T00:10:00Z
user=u041  source_ip=10.20.5.18  result=success

DHCPログ
2026-09-15T08:00:00+09:00
ip=10.20.5.18  device=PC-23  lease_end=17:00:00+09:00

アプリケーションログ
2026-09-15T09:12:00+09:00
user=u041  source_ip=10.20.5.18  request_id=r801
action=export_complete  records=4800  result=success

ダウンロード監査ログ
2026-09-15T09:13:00+09:00
user=u041  request_id=r801  action=download_complete
result=success

この例では、該当時間中に別の割当てへ変わった記録はなく、端末の識別情報も資産台帳と照合できたものとします。

一つずつ、証拠をつなぐ

認証ログの0時10分UTCは、JSTでは9時10分です。したがって、認証成功の2分後に4,800件の出力が完了し、その1分後に同じ要求IDに関係するダウンロード完了が記録された、と整理できます。

DHCPの割当てと照合すると、その時刻の10.20.5.18はPC-23に対応します。さらにアカウントと要求IDから、出力とダウンロードの記録をつなげられます。

ここまでは、取得した記録と設問の前提から確認できる事実です。

一方で、u041の本人が操作したか、承認された集計だったか、ダウンロード後に外部へ渡したかは、この四つだけでは分かりません。操作の予定、本人への確認、端末の状況、必要な外部通信等の記録と照合します。

時系列に並べると、認証成功の2分後に出力完了、その1分後に取得完了という流れが見えます。ただし、時刻の近さは因果関係の証明ではなく、取得後の持出しの有無も不明のままです。相関分析の価値は、一つの記録だけでは分からなかった流れを見つけることです。不正だと早く決めつけることではありません。

同じIPだから同じ操作、とは限らない

仮にアプリケーションログに要求IDがなく、全アクセスが中継サーバのIPで記録されていたら、同時刻の別利用者の処理が混ざる可能性があります。

また、ダウンロードの記録が単にHTTP 200だった場合、ここで示したアプリケーション上のダウンロード完了とは意味が異なります。何をもって完了としているログなのかを確認します。完了が記録されても、利用者が内容を読んだことまでは分かりません。

欠けた材料があるときは、結論を強くするのではなく、何がまだ分からないかを示します。その不足は、次の監視設計やログ項目の見直しにも使えます。

午後で、ログの表を読むときの手順

問題文にログの表が示されたら、次の順で読むと、取り違えを防げます。

1. 時刻の基準を確かめる：表ごとのタイムゾーンと、時計の同期の前提を確認する

2. 列の意味を確かめる：接続元は端末か中継機器か、「成功」は何の成功か

3. 同じ値で行をつなぐ：IPアドレス、アカウント、要求ID、ファイル名など

4. 並びの規則性を見る：一定の間隔、短時間の集中、業務時間外

5. 欠けている記録に気付く：記録されない項目や期間を、「何もなかった」と読み替えない

記述の型

• ログから言えること：「記録から確認できる事実と、まだ分からないこと（本人の操作か、持ち出したか）を分けて書く」

• 一連の処理をつなぐ：「入口で発行した要求IDを、後段の処理のログにも記録する」

8. 検知ルールと誤検知：警告の数だけを減らさない

条件で見つける方法と、普段との違いで見つける方法

あらかじめ決めた条件に合う事象を検知する方法があります。例えば、一定時間内の認証失敗、管理者権限の付与、禁止された設定変更などです。既知の攻撃の特徴に照合するシグネチャ型も、この学習で押さえたい考え方です。

一方、普段の状態を基準に、そこからの逸脱を見つけるのがアノマリ検知です。利用者や端末の行動を分析するUEBAは、User and Entity Behavior Analyticsの略です。通常と異なる利用時間やアクセス量などを検知する機能に使われます。

異常は、不正と同義ではありません。初めての担当業務、繁忙期、システム移行で普段と違う操作が生じることもあります。学習の基準に既に不正な状態が含まれていれば、その影響も考える必要があります。

偽陽性と偽陰性

正常な事象を不正なものとして警告するのが偽陽性、いわゆる誤検知です。不正な事象を検知できないのが偽陰性、いわゆる見逃しです。

例えば、5分間に10回失敗したら警告するルールがあるとします。これは学習用の仮のしきい値です。警告が多いから100回へ引き上げれば、件数は減るかもしれません。しかし、少ない回数の不正な試行も見逃しやすくなります。

しきい値だけで解決しようとせず、対象が一つのアカウントか多数のアカウントか、同じ接続元か分散しているか、成功へ変わったか、正規の処理に伴う失敗かといった条件を組み合わせます。

除外は、理由と期限を持たせる

月次集計による大量出力を警告対象から除外するなら、集計担当者、対象システム、時期、件数の範囲などを限定します。そのアカウントからの操作は全部除外、という設定では、アカウントが悪用されたときも見逃すおそれがあります。

除外は担当者の記憶に頼らず、理由、承認者、対象、期限を残します。期限が来たときや業務が変わったときに見直します。警告が減ったことだけで改善とせず、正規作業と不正な模擬イベントの両方で確認します。

重大度と対応優先度

製品の重大度は、技術的な特徴に基づく評価です。実際の対応優先度には、対象資産の重要性、成功した可能性、被害の進行、外部公開の有無、他の警告との関連も加えます。

例えば、同じ検知名でも、既に遮断された検証環境の通信と、重要なサーバで実行後に検知された事象では、次に確認すべきことが違います。

評価の結果、緊急性が低いとしても、判断した根拠を記録します。後から関連する警告が出たとき、以前の記録を見直せるようにするためです。

午後での問われ方

• 令和3年度秋期 午後II問1：クラウドサービスへの不正アクセスを、SIEMでログから検知する方法の検討が題材でした。利用者IDを固定してパスワードを総当たりする攻撃は、一定時間当たりの「同一利用者IDでのログイン失敗」の回数がしきい値を超えたら検知します。少数のパスワードで利用者IDを総当たりする攻撃を、同一のIPアドレスからの失敗の回数で検知するルールは、ゆっくり実行された場合に加え、「アクセス元IPアドレスを変えながら、不正アクセスを続けた場合」に見逃すことが示されています。

記述の型

• 検知ルールの限界：「ゆっくり実行された場合や、アクセス元を変えながら続けられた場合に見逃す」

• しきい値を上げることの問題：「誤検知は減るが、見逃しが増える」

9. 脅威インテリジェンスとSTIX／TAXII

外部の情報を、自組織の観測へつなぐ

脅威インテリジェンスは、脅威に関する情報を分析・整理し、判断に使える形にしたものです。攻撃で使われたドメインやファイルの特徴だけでなく、攻撃者の手口、狙われる対象、活動の時期なども含まれます。

IoCはIndicator of Compromise、侵害の痕跡を示す指標です。不審なIPアドレス、ドメイン、ファイルのハッシュ値などが例です。TTPは戦術・技術・手順を指し、攻撃者がどう活動するかに着目します。

IoCとの一致を過去のログから探せば、当時は警告されなかった通信を再調査できることがあります。こうした調査には、検索可能な期間と、保持しているログ項目が影響します。

一致したから即遮断、でよいのか

不審なIPアドレスの情報があっても、現在は別の利用者に再割当てされていたり、正規サービスの共有基盤と共用されていたりする事情があり得ます。情報の出所、観測時期、有効な期間、確度、対象の範囲を確認します。

一致しなかったから安全、ということにもなりません。攻撃者が接続先やファイルを変えれば、既知の指標では検出できない場合があります。具体的な指標と、行動の特徴を組み合わせて考えます。

STIXは、脅威情報を表現する

STIXはStructured Threat Information Expressionの略です。脅威情報や観測情報を、共通の構造で表現するための言語です。例えば、マルウェア、指標、攻撃手法、それらの関係などを機械的に扱いやすくします。OASIS「STIX Version 2.1」、2021年、Abstract・Introduction

単なる危険なIPアドレスの一覧というより、情報の種類と関係を表現できるところに意味があります。

TAXIIは、脅威情報を交換する

TAXIIはTrusted Automated Exchange of Intelligence Informationの略です。脅威情報を交換するためのアプリケーション層のプロトコルで、TAXII 2.1ではHTTPSを使うAPI等が定義されています。OASIS「TAXII Version 2.1」、2021年、Introduction・Architecture

STIXが情報をどう表すか、TAXIIが情報をどうやり取りするか。まずはこの役割の違いを押さえます。両方とも、受け取った情報を無条件に正しいと認定する仕組みではありません。

例えば、共有された指標を取得し、有効性や自組織への関係を確認してから、SIEMの検索や検知条件へ反映し、結果を分析する、という流れになります。更新・取り消し・期限切れの扱いも必要です。

共有する側にも注意があります。内部IPなどの内部情報、個人情報、業務名などを、そのまま外部へ送ってよいとは限りません。提供範囲を決めて共有します。共有先、利用目的、情報の区分、再共有の条件を確認し、必要な範囲に整理して提供します。

記述の型

• IoCの使い方：「共有されたIoC（IPアドレス・ドメイン・ハッシュ値）で、過去のログを検索する」

• IoCの限界：「一致しないことは、侵害がないことの証明にならない」

• STIXとTAXII：「STIXは脅威情報を表現する形式、TAXIIはそれを交換するプロトコル」

10. ログそのものを守る：集める仕組みも攻撃対象

発生元とは別に保存する

攻撃者がサーバを侵害すると、活動を隠すためにログを消したり、取得を停止したりする可能性があります。発生元にしかログがないと、その機器と一緒に証跡を失うおそれがあります。

集中保管は、このリスクを減らす手段です。ただし、本番の管理者権限で集中保管先まで削除できるなら、分離の効果は限定的です。送信、閲覧、設定変更、削除などの権限を分け、保存先自体の管理操作も記録します。

WORMなど変更制限のある保存方式や、改ざん検知も検討します。WORMはWrite Once Read Manyの略で、一度書いた情報を繰り返し読み出す考え方です。ハッシュ値を使う場合は、その基準値も保護してください。攻撃者がログとハッシュ値の両方を書き換えられれば、単純な比較では気付けません。

暗号化だけで改ざんや削除をすべて防げるわけでもありません。機密性・完全性・可用性を、生成から保管・利用・廃棄までの経路全体で考えます。機密性を守る処理と、完全性の確認、アクセス制御を役割ごとに考えます。

収集・転送で落とさない

Syslogは、ログメッセージの形式や転送に関連する標準的な仕組みです。従来のUDPによる転送は配送を保証せず、そのままでは通信内容の暗号化もされません。Syslogだから必ず安全に届く、と考えないようにします。

SyslogをTLSで転送する方式はRFC 5425で定義されています。採用する際は、送信先の認証、証明書、転送経路を確認します。安全な通信路を使うことと、発生した全ログが確実に保存されることは別です。RFC 5425、TLS Transport Mapping for Syslog

ネットワーク停止中にどれだけ一時保存できるか、再送するか、重複をどう扱うか、容量を超えたら何をするかも設計します。クラウドのAPI収集では、取得権限の失効、呼出し回数制限、続きのページの取り忘れなども欠落の原因になります。

取込みエラーだけでなく、普段は記録が出る機器から急に届かなくなったことや、発生時刻から取込みまでの遅延も監視します。ログがない理由は、正常でイベントが発生していない場合と、観測できなくなった場合に分かれるからです。

秘密情報を集めすぎない

パスワード、アクセストークン、暗号鍵などをそのままログへ出すと、ログの閲覧権限が別の攻撃の入口になり得ます。申請本文や添付書類などの機微な情報も、調査に必要な範囲と保護を考えます。

OWASPのLogging Cheat Sheetは、直接記録しない方がよいデータや、改行等によるログインジェクションへの対処を整理しています。ログインジェクションは、外部入力を通じて偽の記録を混ぜたり、記録の構造を壊したりする攻撃です。構造化した形式や適切なエスケープを用い、記録に使う値も無条件に信用しません。OWASP Logging Cheat Sheet、Data to exclude・Event collection

ログを外部の分析サービスへ送る場合も、送信範囲、保存場所、事業者のアクセス、再委託、契約終了時の扱いを確認します。監視のためなら何を送ってもよいわけではありません。

保存期間と検索できる期間

保存期間は、業務上の必要、規程や契約、想定する調査、容量などに応じて決めます。この回で参照する一般的な国・自治体の規定から、すべてのログに共通する年数が一つに決まるわけではありません。

すぐ検索できる期間と、保管庫から取り出せば調べられる期間を分けて設計することもあります。長く保存されていても、取出しに数日かかれば、緊急の調査ではその制約が影響します。

例えば、平均1,000件／秒、1件500バイトなら、1日分の生データは43.2GBです。十進単位で、1,000×500×86,400を計算しています。30日なら約1.3TBですが、これは単純な概算です。検索用の索引、複製、圧縮、ピーク時の増加は別に見積もります。

ローテーションで古いログを順に削除するなら、保存対象が上書き前に転送されているかも確認します。調査対象になった期間のログは、通常の削除予定から外して保全する必要が生じる場合があります。誰がその判断をし、いつ解除するかを手順にします。

原本と分析結果を区別する

正規化後のログは検索しやすい一方、変換時に項目が落ちたり、誤解釈されたりする可能性があります。必要に応じて元の記録も保持し、どの変換を行ったか追えるようにします。

調査用のコピーを作る際は、取得元、取得日時、担当者、対象期間、取得方法、完全性確認の結果、受渡しなどを記録します。これを残しただけで法的な証拠価値が自動的に保証されるわけではありませんが、取扱いを後から説明するための材料になります。

午後での問われ方

• 令和3年度秋期 午後II問2：テレワークに伴うインシデントが題材で、一部の業務PCでは、全てのイベントログが消去された痕跡がありました。消去の後に記録されていたものとして、解答例は「イベントログの消去を示すログ」です。ログを消しても、消したこと自体が記録に残る場合があります。

記述の型

• ログの消去への対策：「ログを別のサーバに転送して保存し、保存先の削除権限を発生元の管理者と分ける」

• ログがないとき：「イベントが発生していないのか、観測できなくなったのかを分ける」

• 記録しないもの：「パスワードやアクセストークンなどの秘密情報は、ログに出力しない」

11. 警告から対応へ：誰が何を決めるか

一次確認で、事実と推測を分ける

警告を受けたら、対象機器・アカウント、発生時刻、検知理由、成功・遮断等の結果、関連する記録を確認します。その際、検知した事実と、まだ仮説にとどまる被害を区別します。

例えば、大量出力の警告があっても、外部への漏えいまで断定しません。ただし、被害が進んでいる可能性が高ければ、すべての調査結果を待たずに、事前手順に沿って拡大防止を進める必要があります。

報告では、確認済みの事実、想定される影響、未確認の点、次に必要な判断をまとめます。「不審でした」だけでは、責任者がサービス停止やアカウント制限を判断できません。

夜間の連絡と権限

24時間監視を委託していても、夜間に自治体側の判断者へ連絡できない場合があります。事業者が通知するところまでなのか、対象の調査や隔離までできるのかを明確にします。

連絡先、応答がない場合の順序、緊急時に実施してよい措置、業務担当者との調整、解除条件を決めておきます。メールを送ったことと、担当者が受け取って対応を始めたことは別です。

対応した後も、結果を確かめる

遮断やアカウント制限を実行したら、対象に適用されたか、別の接続やセッションが残っていないか、業務に想定外の影響がないかを確認します。解除も、警告が消えたことだけで判断しません。

一件が解決した後は、検知できた理由、分からなかったこと、連絡や作業の遅れを振り返ります。ログ項目や監視対象、プレイブックを改善し、必要なテストで確認します。

インシデント対応の進め方は支援士解説4の3、証拠の保全は支援士解説4の4で扱います。制御システムやIoT機器の監視では、監視のための問合せやスキャンが機器の動作に影響することもあるので、受動的な観測を中心に考えます（支援士解説2の3）。

午後での問われ方

• 令和元年度秋期 午後I問3：外部の監視サービスが、ファイアウォールのログを分析してC&Cサーバへの通信を検知すると、接続日時、送信元のIPアドレス、宛先のC&CサーバのIPアドレス、ポート、データサイズの五つを通知する仕組みが題材でした。通知を受けた担当者は、IPアドレスの管理台帳でPCを特定し、データサイズから情報漏えいのおそれを判断し、EDRの記録でマルウェアを特定します。通知の項目が、次の判断に使えるように決められていることに注目します。

記述の型

• 一次確認：「対象の機器・アカウント、発生時刻、検知理由、遮断などの結果、関連する記録を確認する」

• 報告の書き方：「確認済みの事実、想定される影響、未確認の点、次に必要な判断を分けて伝える」

• 対処後の確認：「対象に適用されたか、別の接続やセッションが残っていないかを確かめる」

12. 午前II（科目A-2）で正誤を見分けるポイント

• 「認証ログにログイン成功が記録されていれば、本人が操作したと判断できる」→ 誤り。盗まれた認証情報の可能性がある

• 「ファイアウォールのログで許可された通信は、中身も安全である」→ 誤り。許可はルール上の判断にすぎない

• 「IDSが攻撃を検知した記録があれば、その通信は遮断されている」→ 誤り。通知だけの動作なら通信は通っている

• 「JSTはUTCより9時間進んでいる」→ 正しい

• 「NTPは、ログの改ざんを検知するためのプロトコルである」→ 誤り。時刻を同期するプロトコル

• 「SIEMは、複数の機器のログを集め、相関分析して警告する」→ 正しい

• 「SOARは、対応の手順を連携・自動化する仕組みである」→ 正しい

• 「STIXは脅威情報を交換するためのプロトコルである」→ 誤り。STIXは表現の形式で、交換のプロトコルはTAXII

• 「X-Forwarded-Forヘッダの値は、常に本当の接続元を示す」→ 誤り。利用者側でも偽装できる

• 「従来のUDPによるSyslogは、配送の確認と暗号化を備えている」→ 誤り。どちらもない

• 「フロー情報には、通信の中身（ペイロード）が記録される」→ 誤り。ヘッダの情報と通信量が中心

• 「Webサーバのアクセスログの応答コード200は、業務処理が成功したことを示す」→ 誤り。要求を処理して応答を返しただけ

• 「アノマリ型の検知は、普段の状態からの逸脱を見つける」→ 正しい

• 「ログを集中保管すれば、本番の管理者が保存先のログを削除できても問題ない」→ 誤り。削除権限を分ける

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　端末の特定

プロキシのログに、社内のIPアドレス10.20.5.18から不審なサイトへの通信が、日本時間の9時10分に記録されていた。DHCPのログはUTCで記録されている。この通信を行った端末を特定する方法として、最も適切なものはどれか。

• ア：DHCPのログで、UTCの9時10分ごろの10.20.5.18の割当てを調べる

• イ：DHCPのログで、UTCの0時10分ごろの10.20.5.18の割当てを調べる

• ウ：IPアドレスが固定なので、DHCPのログは調べなくてよい

• エ：IPアドレスから、すぐに職員を特定する

正解：イ。日本時間の9時10分は、UTCの0時10分です。タイムゾーンをそろえてから、割当てを照合します。エは、端末・アカウント・人物を区別していません。

問2　アクセスログの限界

Webサーバのアクセスログから、攻撃者が送り込んだOSコマンドを調べようとしたが、見つからなかった。攻撃はPOSTメソッドで行われていた。最も考えられる理由はどれか。

• ア：応答コードが200だったから

• イ：POSTメソッドで送信された本文は、アクセスログに記録されないから

• ウ：時刻同期が行われていなかったから

• エ：接続元のIPアドレスが記録されていなかったから

正解：イ。アクセスログに残るのは、通常、要求のURLなどです。本文を調べたいなら、アプリケーションのログなど、別の記録を用意します。

問3　通信の監視

同じスイッチにつながったPC同士でワームが広がっていたが、ネットワークの監視装置では検知できなかった。最も考えられる理由と対策の組合せはどれか。

• ア：シグネチャが古いので、更新すれば必ず検知できる

• イ：PC同士の通信が監視装置を通らないので、VLANでPC間の通信を禁止する

• ウ：通信が暗号化されていたので、パスワードを変更する

• エ：監視装置の時刻がずれていたので、NTPを設定する

正解：イ。監視の装置は、通った通信しか見えません。見えない範囲を把握し、構成の側で対策します。

問4　検知ルール

「同じIPアドレスから、5分間に異なる利用者IDでのログイン失敗が10回を超えたら警告する」というルールで、見逃すおそれが最も大きいのはどれか。

• ア：一つのIPアドレスから、短時間に多数の利用者IDを試す攻撃

• イ：アクセス元のIPアドレスを変えながら、ゆっくり続ける攻撃

• ウ：正しいIDとパスワードでの通常のログイン

• エ：管理者による設定変更

正解：イ。条件の外で行われる攻撃は検知できません。しきい値だけでなく、複数の条件を組み合わせます。

問5　ログの保護

攻撃者がサーバに侵入し、ログを消去した。今後に備える対策として、最も適切なものはどれか。

• ア：ログの保存期間を長くする

• イ：ログを別のサーバへ転送して保存し、保存先の削除権限をサーバの管理者と分ける

• ウ：ログに、利用者のパスワードも記録する

• エ：ログの出力を止めて、容量を節約する

正解：イ。発生元にしかログがなければ、一緒に消されます。保存先を分けるだけでなく、権限も分けます。ウは、ログが新たな漏えい元になります。

実務と国・自治体では

実務では、「ログを取得すること」と仕様書に書くだけでは、見つけたいことは見つかりません。見つけたい事象（申請データの予定外の出力、保守アカウントの予定外の利用、ログ取得設定の無効化など）ごとに、必要なログ、項目、時刻の基準、収集の頻度と遅延、保存と検索の期間、通知先と対応を結び付けます。監視を委託するなら、対象外の機器とその理由、ログが届かなくなったときの通知、夜間に実施してよい措置まで決め、導入時に模擬のイベントで通知と受領の確認までを試します。

政府機関等の統一基準は、目的に応じたログの取得、保存期間と取扱いの管理、定期的な点検・分析を求めています。自治体向けのガイドラインも、ログの取得・保存・点検、ログを取得できなくなった場合の対処、監視と時刻の同期を例文で示しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• ログは、記録された場所で分かることが違う。 1種類で結論を出さず、突き合わせる。記録されないもの（POSTの本文など）も知っておく。

• IPアドレスは人物ではない。 時刻をそろえ、DHCP → 端末 → アカウント → 人物の順でたどる。中継機器のヘッダは、信頼できるものだけを使う。

• 通信の監視には見えない範囲がある。 同じセグメントの中、暗号化された中身、取りこぼし。通常時の量と比べ、規則正しい間隔の通信を疑う。

• 検知ルールは、条件の外を見逃す。 「どのログの、何が、どれだけ出たら、誰に知らせるか」で書く。

• ログそのものを守る。 別の場所に転送し、権限を分け、届かなくなったことも監視する。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• IoCを含む脅威情報を、ログの分析や検知にどう生かすかを学べる

関連記事

• 前提：ウイルス対策ソフトだけで防げるのか｜支援士解説3の2（攻撃の段階と痕跡）

• あわせて読む：ネットワークを分ければ安全になる？｜支援士解説3の5（ファイアウォール・IDS・プロキシ）

• 次に読む：インシデントから復旧したら、もう安全？｜支援士解説4の3（インシデント対応）

• 次に読む：コピーしたら、証拠になる？｜支援士解説4の4（証拠保全とフォレンジック）

2026年10月改訂：午後の出題例と記述の型を加え、通信の監視、Windowsのイベントログ、ログに残らないものの節を補い、制御システムの監視は支援士解説2の3へ移して、構成を見直しました。