その警告、本当に事故？——事実の整理・影響範囲・評価の更新｜支援士解説4の2

この記事の重要度：Cランク（主に午前II（科目A-2）で問われる論点。午後では問題文の前提として読めれば十分）

この記事で分かること：

• 事象・アラート・インシデントの区別と、誤検知・見逃しの意味
• 事実・仮説・未確認事項・判断を分け、時刻と対象を正しく整理する方法
• 影響範囲の見積もり方と、評価を新しい事実で更新する考え方

シラバスとの対応：小項目4-2「情報セキュリティ事象の評価」。体制は支援士解説4の1、トリアージと対応の進め方は支援士解説4の3、ログの読み方は支援士解説3の4で扱います。

---

監視の仕組みが「大量のファイル取得」を警告した。担当課に聞くと「昨夜はデータ移行の作業があった」と言う。では、この警告は誤検知として閉じてよいでしょうか。

インシデントの初動とトリアージ（何から対応するかの判断）は、午後で繰り返し問われる重要な分野で、支援士解説4の3で詳しく扱います。この記事では、その手前にある「手元の記録から、何が言えて、何が言えないか」の評価に絞ります。午後でも、記録から言えることの範囲が問われることがあります。

1. 事象・アラート・インシデントを分ける

• 情報セキュリティ事象：情報セキュリティ方針への違反や管理策の不具合の可能性を示す出来事（ログインの失敗、権限の変更、ファイルの取得など）。通常の業務でも起きるので、記録があるだけで不正とは限らない
• アラート：監視の仕組みが、決めた条件に当てはまったと知らせる警告。検知したのは「条件への該当」であって、不正そのものとは限らない
• インシデント：情報や業務の安全を脅かし、組織として対応が必要な事態。被害が確定したものだけでなく、侵害のおそれがあるものも含めて、組織の基準に照らして判断する

一つの不正な操作が、端末・認証・ネットワーク・クラウドの複数の監視で警告されることがあります。警告の件数と事案の件数は一致しません。関連する警告は一つの事案にまとめて追います。ただし、同じ送信元IPアドレスや同じ時刻というだけで、無関係な事象を一つにまとめないようにします。

職員が「事故かどうか」を自分で判定する必要はありません。報告すべき現象を具体例で示し、評価する担当（CSIRTなど）へつなぐ仕組みにします（支援士解説4の1）。

受け付けた担当は、評価に入る前に、最初の情報を次の項目で整理します。原因を突き止めることより、次の確認と行動へつなぐことを優先します。

• 誰が、いつ、何に気付いたか（報告者、気付いた時刻、きっかけ）
• 対象は何か（端末、アカウント、システム、扱う情報）
• 何が起きているか（画面の表示、警告の内容、身に覚えのない通知）
• すでに何をしたか（再起動した、ファイルを開いた、ケーブルを抜いた）
• 今も続いているか

報告者に追加の操作を頼む前に、何を残すべきかを伝えます。確かめるつもりの再実行や削除で、証拠が失われることがあります。

2. 誤検知と見逃し、そして「正当な操作」

監視の判定には、二つの誤りがあります。

• 誤検知（フォールスポジティブ、偽陽性）：正常なものを異常と判断する誤り
• 見逃し（フォールスネガティブ、偽陰性）：異常なものを正常と判断する誤り

ただし、大量取得の警告が出て、後から承認された作業だと分かった場合を、いつも「監視の誤り」とするのは不正確です。大量取得は実際に起きており、検知の条件は正しく働いています。確かめるべきことは二段階に分かれます。

1. 検知の確認：本当にその操作が起きたか。記録や集計の誤りはないか
2. 業務上の確認：その操作は、許可された対象・時間・方法によるものか

二つの誤りは、検知の条件の厳しさで入れ替わる関係にあります。条件を緩めて誤検知を減らすと見逃しが増え、厳しくして見逃しを減らすと誤検知が増えます。検知した通信を自動で遮断する設定なら、誤検知は正常な業務を止めることになります。条件を見直すときは、どちらの誤りをどこまで許せるかを、守る対象に合わせて決めます。

現場では、正当な操作による警告も広く「誤検知」と呼ぶことがあります。その場合でも、記録には「承認済みの移行作業と、アカウント・時刻・対象が一致した」のように、判断の理由を書きます。

遮断された攻撃の記録も、確認が要らないとは限りません。同じ相手から試行が繰り返されている、重要な認証情報が狙われている、ほかの資産にも同じ試行が届いている、といった場合は、追加の確認や注意喚起が必要です。一方、外部からの試行を一件見つけるたびにシステムを止めるのも適切ではありません。検知の結果と、対象の資産の状況を合わせて判断します。

反対に、アラートが出ていないことは、安全を確かめたことにはなりません。監視していないクラウドサービス、記録していない操作、検知条件に当てはまらない手口があるからです。攻撃を遮断した記録が一件あっても、分かるのは「その装置が、その通信を止めた」ことまでです。同じ端末が別の宛先や経路で通信していないかは、別に確かめます。

3. 事実と、そこから考えたことを分ける

評価の記録では、次の四つを分けて書きます（図1）。

• 事実：確認した記録や観測。どの情報源の、いつ時点の情報かも付ける
• 仮説：事実を説明する候補。一つに決め付けず、複数を並べる
• 未確認事項：まだ分からないこと
• 判断：今、何をするか。その理由、必要な承認、担当、次に確かめる時刻

架空の例：深夜1時すぎ、職員のアカウントu042で、相談記録のフォルダを一括で出力し、1,240個のファイルをダウンロードした記録が見つかりました。担当課は「昨夜は移行作業があった」と言います。ところが、承認された作業計画では、移行は0時から0時40分に、移行専用のアカウントで、公開資料のフォルダを対象に行う予定でした。アカウント・時刻・対象が一致しません。移行作業があったという事実だけでは、今回の取得を正当とは説明できません。

このとき、次のように整理します。

• 事実：u042のセッションで、相談記録フォルダの出力とダウンロードの完了が記録されている。本人に確かめると「その時間は操作していない」と回答があった
• 仮説：予定外の正当な作業、誤操作、アカウントの不正な利用
• 未確認：実際に操作した人と端末、ファイルに含まれる情報の内容、ほかの取得や共有の有無
• 判断：相談記録という情報の性質と、予定との食い違いから、不正利用の疑いとして優先して確かめる。同じセッションで操作が続いていれば、権限を持つ人の承認を得て、アカウントとセッションの利用を制限する

事実には、情報源と確認した時点を付け、その情報源の限界も残します。たとえばこの例のサービスで、出力データの作成とダウンロードの完了が別の記録として残る仕様なら、「ダウンロードが完了した」とまでは言えます。しかし、取得したファイルをどこへ保存したか、さらに第三者へ送ったかは、その記録からは分かりません。記録が何を意味するかは、サービスの仕様で確かめます。

本人の「操作していない」という回答も大切な情報ですが、回答を得たことと、不正な利用を技術的に確かめたことは別です。また、1,240はファイルの数で、相談者が1,240人とは限りません。件数の単位を、被害の人数へ飛躍させないようにします。

時刻と対象の整理にも注意します。

• 発生・検知・受付の時刻を分ける。深夜1時の操作を朝8時に検知し、8時10分に受け付けた、というように別々に記録する。報告の期限や影響の期間は、どの時刻から数えるかで変わる
• タイムゾーンをそろえる。日本標準時は協定世界時より9時間進んでいる。両方の形式のログが混ざっていると、時系列を取り違える
• 端末・アカウント・人物を区別する。アカウントやIPアドレスの記録だけで、操作した人物を確定しない
• 記録がない理由を確かめる。「ログに見当たらない」には、操作がなかった場合と、そもそも記録されない・残っていない場合がある

【図1】事実と、そこから考えたことを分ける

午後で出てくる場面

記録から言えることの範囲は、午後でも問われてきました（ログの時刻の整理と、監視の見え方の論点は支援士解説3の4でも扱います）。

• 令和3年度春期 午後II問1：通販サイトへの不正ログインの調査で、提供されたログの大半は日本標準時で記録されていたが、協定世界時で記録されたログや、タイムゾーンを示す情報がないログも混ざっていて、分析に誤解が生じた。空欄として、タイムゾーンと、時差の9時間が問われた
• 平成30年度秋期 午後I問2：ワームの感染で、監視装置の集計の上位に、ワームのスキャンが現れない理由が問われた。同じセグメント内へのスキャンは、監視装置へミラーリングしている経路を通らず、監視の対象外だった。もう一方の広い範囲へのスキャンは、同じIPアドレスへの回数が少なかった。「集計に出てこない」ことが「起きていない」ことではない例

4. 影響範囲を、確認の状態ごとに分ける

最初に見つかった一台、一つのアカウントで範囲を確定しないようにします。影響範囲は、次の三つに分けて管理します。

• 確認済み：調べて、影響あり（又はなし）と確かめた範囲
• 確認対象：これから調べる範囲。担当と期限を付ける
• 未調査：まだ手を付けていない範囲。「影響なし」に含めない

範囲は、技術と業務の両面で見ます。技術的には、同じ認証情報が使われたほかのシステム、同じ脆弱性を持つほかの機器、連携先です。業務的には、そのデータを使う業務、関係する住民・顧客、委託先です。

先ほどのu042の例なら、次のように確かめる範囲を広げます。

• 同じアカウントでの、ほかの日時の操作と、ほかのフォルダへの操作
• 同じ認証情報（パスワードの使い回しを含む）で入れる、ほかのシステム
• 不審なセッションの接続元からの、ほかのアカウントへのログイン
• 攻撃者が戻るための仕掛け：新しく作られた共有リンク、メールの自動転送の設定、追加された権限やアカウント
• 取得されたファイルに含まれる情報と、関係する人の数（業務の担当と確かめる）

被害は件数だけでなく、情報の性質（個人情報か、要配慮の情報か）、業務への影響、取り戻せるかどうかも合わせて表します。

原因についても、最初の説明を唯一の原因にしません。初動の段階の原因分析（今の被害を止めるために何が起きたかを知る）と、根本原因の究明（なぜその弱点が生じたかを知る）は、目的と時期が違います。根本原因の分析は支援士解説4の3で扱います。

5. トリアージは、評価と行動をつなぐ

トリアージは、受け付けた事案を評価し、対応が必要か、どれを優先するか、誰が担当するかを決めることです。詳しくは支援士解説4の3で扱うので、ここでは要点だけ押さえます。

• 優先度は、影響（どの情報と業務に、どんな被害か）、緊急性（被害が進んでいるか、広がっているか）、確度（見立てを支える情報の確かさ）を分けて考える
• 確度がまだ低くても、影響が大きければ急いで確かめる。管理者アカウントの不正利用の疑いなど
• 監視製品が付ける重大度（Criticalなど）や、脆弱性のCVSSの値は、そのまま組織の対応の優先度ではない
• 判断は、分類のラベルを付けるだけで終わらせない。担当、次の行動、次に見直す時刻とセットにする
• 判断の基準は、起きてから考えるのではなく、事前にできるだけ具体的に決めておく

暫定の措置にも、利点と影響の両方があります。アカウントの停止は不正な利用を止めますが、本人の業務も止まり、攻撃者に気付かれて手口を変えられることもあります。システムの停止は被害の拡大を防ぎますが、利用者へのサービスも止まり、メモリ上の情報など調査に必要な記録が失われることがあります。誰がどの条件で実施できるかを事前に決めておき、実施したら効果を確かめます。「作業を依頼した」と「措置が有効になった」は別です。

6. 報告と、評価の更新

初報は、完成した調査報告書ではありません。分かっている事実、分かっていないこと、取った措置、次の報告の予定を、判断する相手に早く届けます。調べ終わるまで報告を待つと、権限を持つ人の判断が遅れます。

初報では、たとえば次の項目を伝えます。

• 事案の概要と、確認した時点
• 確認した事実（情報源付き）と、まだ分からないこと
• 取った暫定措置と、その結果
• 判断してほしい事項と、その期限
• 次に報告する予定の時刻

相手によって必要な情報は違います。技術担当には確かめる記録と範囲を、管理職には業務への影響と判断してほしい事項を、業務担当には止める範囲と代わりの業務を伝えます。委託先には「何か問題はありますか」ではなく、調べてほしい対象、期間、記録を具体的に伝えます。委託先から「攻撃の形跡はない」と回答があれば、確認した対象、期間、ログ、確認できなかった範囲も受け取ります。

技術的な相談と、法令に基づく報告は、別の経路として扱います。個人データの漏えいのおそれがあれば、個人情報保護委員会への報告と本人への通知が必要かを、担当部署が期限を意識して確かめます（支援士解説3の11）。評価の途中でも、必要な担当へ早めに知らせます。

評価は、新しい事実が分かるたびに更新します。

• 最初の評価に固執しない。別のアカウントへの権限の付与や外部への共有が見つかれば、範囲を広げる
• 反対に、承認された作業だったという説明が新たに出ても、実際の操作の対象と方法まで照合する。説明が一つ増えただけで、それまでの記録を消して閉じない
• いつ評価を見直すかを決めておく。措置の後に警告が止まっても、別の経路で活動が続いていないかの確認は残る
• 誤検知と判断して閉じるときも、その根拠を残す。後で同じ警告が出たときに、比べられるようにする
• 調査や対応の担当へ引き継ぐときは、現在地（確認済み、確認中、未調査、取った措置）を渡す

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

• 「アラートが出たので、インシデントと確定した」→ 誤り。アラートは条件への該当。事実を組織の基準に照らして判断する
• 「アラートが出ていないので、攻撃は受けていない」→ 誤り。監視の範囲外や、記録されない操作がある
• 「フォールスネガティブとは、正常なアクセスを異常と判断する誤りである」→ 誤り。それはフォールスポジティブ（誤検知）。フォールスネガティブは異常を見逃す誤り
• 「承認された作業が同じ日にあったので、警告は正当な操作による」→ 誤り。アカウント・時刻・対象が一致するかを照合する
• 「利用者IDの操作記録があるので、その利用者本人が操作した」→ 誤り。アカウントと人物は別。認証情報の不正な利用もある
• 「1,000件のファイルが取得されたので、被害者は1,000人である」→ 誤り。件数の単位を確かめる
• 「初報は、原因と影響範囲を確定してから行う」→ 誤り。分かっている範囲で早く報告し、更新する
• 「監視製品の重大度がCriticalなら、組織の対応の優先度も最高になる」→ 誤り。影響・緊急性・確度で組織が判断する
• 「最初に評価した優先度は、対応が終わるまで変えない」→ 誤り。新しい事実で見直す

理解度チェック

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

問1　承認された作業との照合

深夜のファイル大量取得の警告について、担当課から「昨夜は移行作業があった」と説明を受けた。次に行うこととして、最も適切なものはどれか。

• ア：説明があったので、誤検知として閉じる
• イ：承認された作業計画と、警告の対象のアカウント・時刻・対象フォルダが一致するかを照合する
• ウ：移行作業の担当者を処分する
• エ：説明の真偽にかかわらず、全システムを停止する

正解：イ。作業があったことと、今回の操作がその作業であることは別です。アは照合を省いています。ウとエは、確かめる前に結論を出しています。

問2　ログが見つからない

ある端末から外部への通信のログが見つからなかった。この結果の扱いとして、最も適切なものはどれか。

• ア：通信はなかったと判断し、報告書に記載する
• イ：その通信が記録される条件（監視の範囲、記録の設定、保存期間）を確かめてから判断する
• ウ：ログが見つからないのは改ざんの証拠なので、攻撃を受けたと判断する
• エ：別の端末のログで代わりに判断する

正解：イ。記録がないことには、通信がなかった場合と、記録されない・残っていない場合があります。アとウは一方に決め付け、エは対象を取り違えています。

問3　時刻の整理

複数の機器のログを並べたところ、同じ操作が9時間ずれて記録されているように見えた。最初に確かめることとして、最も適切なものはどれか。

• ア：攻撃者が時刻を改ざんしたと判断する
• イ：各ログのタイムゾーン（日本標準時か協定世界時か）と、機器の時刻の同期の状態を確かめる
• ウ：時刻が早い方のログだけを使う
• エ：時刻を無視して、件数だけで判断する

正解：イ。日本標準時は協定世界時より9時間進んでいます。形式の違いを確かめずに、改ざん（ア）や取捨（ウ、エ）を判断しません。

問4　評価の更新

アカウントの利用を制限した後、監視の警告が止まった。この時点の判断として、最も適切なものはどれか。

• ア：警告が止まったので、事案は解決したとして閉じる
• イ：制限が有効になったことを確かめ、ほかのアカウントや経路で活動が続いていないか、すでに取得された情報の影響を引き続き確かめる
• ウ：制限を解除して、警告が再び出るかを試す
• エ：警告が止まったので、取得されたファイルの内容は確かめなくてよい

正解：イ。初動の措置が効いたことと、事案全体が解決したことは別です。アとエは確認を打ち切り、ウは被害を再び広げるおそれがあります。

実務と国・自治体では

• 政府機関等の統一基準：職員などがインシデントの「可能性」を認知したら窓口へ報告し、CSIRTが状況を確かめてインシデントかどうかを評価する、と役割を分けている。ほかのシステムで同様の事案が起きていないかの検討や、対処の記録も扱う。政府機関等向けの基準なので、自治体や企業の直接の義務として読み替えない
• 自治体向けガイドライン：総務省のガイドラインは、緊急時対応計画の報告事項として、事案の状況、原因として想定される行為、確認した被害・影響範囲、インシデントに当たるかの判断結果などを挙げている。「想定される原因」を確定した原因と混同しないことが大切
• 海外の参考資料：NISTのSP 800-61 Rev.3（2025年4月）は、分析した事象に定めた基準を当てはめてインシデントとして扱うかを判断することを、検知の活動の一つとして示している。参考の推奨事項で、国内の組織に直接の義務を課すものではない
• 委託先との取決め：事故のときに、どの記録を、誰が、どの期間内に提供できるかを契約で決めておく。初報に必要な最低限の情報と、詳しい調査に必要な情報を分けて合意しておくと、全件の調査を待って連絡が止まることを防げる

まとめ

• アラートは条件への該当、インシデントは組織の基準での判断。 アラートがないことは安全の確認ではない。
• 事実・仮説・未確認・判断を分ける。 時刻は発生・検知・受付とタイムゾーンを、対象は端末・アカウント・人物を区別する。
• 影響範囲は確認済み・確認対象・未調査に分ける。 未調査を「影響なし」に含めない。
• 初報は早く、評価は新しい事実で更新する。 トリアージの詳細は4の3で。

関連記事

• 前提：CSIRTがあれば、インシデントに対応できる？｜支援士解説4の1（報告を受ける体制）
• 次に読む：インシデントから復旧したら、もう安全？｜支援士解説4の3（トリアージ・初動・封じ込め）
• あわせて読む：ログを取るだけで攻撃に気付ける？｜支援士解説3の4（時刻同期・タイムゾーン・ログの分析）

2026年10月改訂：記録から言えることと言えないことの評価に絞り、トリアージと初動の詳細は4の3へまとめました。