セキュリティ事故の時系列整理｜ログの時刻差・欠落・推定を分ける方法

情報セキュリティ事故の調査では、認証基盤、端末、ネットワーク、クラウドサービスなど、複数の場所に記録が残ります。各ログの時刻を並べるだけでは、事故が起きた順番や影響範囲を正しく説明できません。記録された時刻がどのタイムゾーンなのか、機器の時計がどれだけずれていたのか、記録が収集基盤へ届くまでにどれだけ遅れたのかを分けて扱う必要があります。

ログや端末の取得、原本の保護、取得者と受渡しの記録は、時系列を組み立てる前提です。そこを整える手順は情報セキュリティ事故の証拠保全で扱っています。ここでは、保全済みのデータを使ってイベントを相関し、確認できた事実と、欠落を補うための推定を別々に記録する方法を説明します。

先に結論：事故の時系列は、各記録の原文と取得条件を残したまま、時刻をUTCなど一つの基準へ正規化し、タイムゾーン、時計のずれ、収集・取込の遅延を別の列で管理します。複数の記録はイベント時刻だけでなく、ユーザーIDや端末ID、セッションIDなどの相関キーと時間の不確実性を照合したうえで根拠として示し、ログが存在しない区間は「発生していない」と断定せず、監視範囲・保持期間・収集状態を確認できた範囲と、残った仮説を分けて報告します。

---

本記事のポイント

1. 時系列の基準は原文の時刻を消さずにUTCとオフセットを併記し、イベント時刻・観測時刻・取込時刻を分けて持つ。
2. タイムゾーンの表記差、機器の時計のずれ、収集基盤への取込遅延は原因が異なるため、同じ「時刻差」として補正しない。
3. ログの欠落は活動がなかった証拠ではなく、確認できた事実・技術的な空白・補助的な仮説を根拠と信頼度付きで報告する。

---

1. 時系列を作る前に、記録の単位と根拠を揃える

最初に決めるのは、どの出来事を「時系列の1行」として扱うかです。ログの1行をそのまま1イベントと数えると、同じ通信を複数の監視装置が記録した場合に重複し、逆に一つの認証処理が開始・成功・トークン発行に分かれている場合は流れを見失います。調査対象の期間、対象資産、事故の起点と考える観測点を先に書き、同じ取引やセッションを結び付ける識別子を決めます。

表にする前の原記録には、少なくとも次の項目を残します。表示用に整形した時刻だけを保存すると、後で変換式や丸めを再確認できません。

項目	記録する内容	確認できること
証拠ID・原記録	取得元、ファイル名やイベントID、原文、ハッシュ、取得日時	どのデータを根拠にしたかを再現できる
イベント時刻	発生元が記録した時刻、タイムゾーン、UTCオフセット、精度	出来事が起きたと解釈する基準
観測・取込時刻	センサー、エージェント、SIEM、APIが受け取った時刻	伝送・収集の遅れと到着順
時計の状態	NTP同期の有無、基準時計との差、測定時点、許容誤差	イベント時刻の不確かさ
相関キー	ユーザー、端末、IP、セッション、リクエスト、クラウドイベントID	別の記録が同じ活動を指すか

証拠の取得・複製・保管の手順と、時系列上の意味付けは分けます。前者を変更すると原本の完全性や受渡しの説明が壊れるため、分析は作業用コピーで行い、変換後の表から原記録へ戻れる証拠IDを付けます。NIST SP 800-86は、分析を複数のデータ源の相関によって進める一方、法的または懲戒上の利用があり得る場合は、発見事項と実施した手順を慎重に記録するよう示しています（3.3、pp.3-6）。

2. タイムゾーン、時計のずれ、取込遅延を別の列で扱う

「ログAがログBより5分早い」という結果だけでは、補正方法を決められません。日本時間とUTCの表示差なら、オフセットを適用すれば同じ瞬間になります。端末の時計が進んでいれば、基準時計との差を使ってイベント時刻の推定範囲を示します。収集基盤に届くまでの遅延なら、発生時刻を変えずに到着時刻との差として記録します。

実務では、原文を raw_time として保存し、次の列を用意します。event_time_utc は発生元が記録した時刻をオフセット付きでUTCへ直した値、clock_delta は基準時計からのずれ、ingest_time_utc は収集基盤が受け取った時刻です。clock_delta が測定できていないときはゼロを入れず、「未確認」とします。分単位でしか記録しないログに秒を補ってはならず、秒まで表示されるログでも時計の正確さは別途確認します。

次の表は、時系列整理で使える記録例です。NISTがこの列名や表形式を要求しているという意味ではなく、元の値、補正の根拠、解釈の留保を同時に残すための実務上の例です。

例	原文	正規化・補正	時系列での意味
タイムゾーンの差	IdPのイベント 2026-09-12 09:00:00 JST（+09:00）	2026-09-12 00:00:00 UTC（元のJST表記とオフセットを保持）	時計がずれたとはいえず、表記の基準を揃えただけ
時計のずれ	端末 2026-09-12 00:10:00 UTC、事故時点にも有効と確認できる基準時計より90秒進み、測定誤差は±10秒	推定 2026-09-12 00:08:30 UTC（おおむね00:08:20–00:08:40）、測定時点を併記	発生時刻の補正。事後の一回測定だけでは事故時点へ遡及できない
取込遅延	イベント 00:12:00 UTC、SIEM受信 00:17:30 UTC	eventは00:12:00、ingestは00:17:30、遅延5分30秒	到着順は遅れ得る。発生した瞬間を00:17:30へ移さない
時刻情報の不足	クラウド出力に受信日だけがあり、発生元時刻がない	受信日時は記録し、発生時刻は「確認不能」	受信日時から発生時刻を逆算しない

日本時間の午前0時をまたぐ事案では、UTCへ変換した後に日付が前日になることがあります。夏時間を採用する地域のログでは、地域名やオフセットを残し、固定の「8時間差」などを一律適用しません。オフセットの根拠がログにない場合は、管理設定やサービスの仕様を確認した結果を別の証拠IDで記録します。

NIST SP 800-86 は、ファイル時刻が正確でない理由として、コンピューターの時計が正しくないこと、記録精度が粗いこと、攻撃者が時刻を変更した可能性を挙げています（4.2.3、pp.4-9）。また、システム時刻・日付・タイムゾーンを把握すると、異なるシステム間の相関に役立ち、NTPによる同期は時刻の測定をおおむね正確に保つと説明しています（4.4、pp.4-14–4-15）。これは時刻を無条件に正しいとみなす根拠ではなく、補正の根拠と誤差を記録する理由です。

3. アンカーと相関キーを決め、イベントの順番を組み立てる

時系列は、最初に確認できた観測点をアンカーにして作ります。たとえば不審なサインインの成功記録が起点なら、その前後の認証失敗、端末のプロセス起動、API呼び出し、権限変更、データアクセスを候補として集めます。アンカーより前の期間も、認証情報の窃取や設定変更がないか確認するために確保します。期間を狭くしすぎると、直前の準備活動を見落とします。

1. 調査対象の資産、期間、アンカーとなるイベントを決め、対象外の範囲も明記する。
2. 各データ源から原記録を取得し、証拠ID、取得条件、保持期間、欠落を記録する。
3. タイムゾーンを正規化し、時計のずれと取込遅延を別列へ入れる。
4. ユーザーID、端末ID、IP、セッションID、リクエストIDなどを使い、同一活動の候補を結び付ける。
5. 前後の順序、重複、矛盾を確認し、各行に「直接確認」「補助確認」「推定」を付ける。
6. 結論を書く前に、別の説明が成り立つ記録や、未確認のデータ源を一覧にする。

相関キーが同じでも、同一人物や同一攻撃者を意味するとは限りません。共有アカウント、NAT配下のIP、プロキシ、再利用されたセッションIDでは、複数の主体が一つの値を共有します。逆にIDが違って見えても、端末交換やサービス間のID変換で同じ活動が分断されることがあります。キーは「同一と断定する条件」ではなく、追加確認を探すための入口として使います。

時計の補正誤差やログの精度から求めた時間区間が重なる場合、表示上の順番だけで前後関係を確定しません。たとえばAが00:08:20–00:08:40、Bが00:08:35–00:08:55なら、Aが先に起きた可能性はあっても、区間だけでは順序を確定できません。「AとBはこの区間で観測され、順序は未確定」と記録し、独立した記録や因果を示す属性を追加で確認します。時間の近さは、原因や実行者を証明しません。

時刻（UTC）	記録	相関キー	判定	根拠・留保
00:08:30（推定）	端末で認証情報を使うプロセスを確認	端末ID・ユーザーID	補助確認	時計が90秒進んでいた測定結果に基づく
00:09:12	IdPでサインイン失敗	ユーザーID・送信元IP	直接確認	IdP原記録、時刻の精度は1秒
00:10:04	IdPでサインイン成功	ユーザーID・送信元IP・セッションID	直接確認	成功記録とセッション発行記録が一致
00:15:34	SIEMに権限変更イベントが到着	セッションID	取込確認	発生元イベント時刻は00:11:02、取込遅延4分32秒

この表から「00:08:30に侵入した」と直ちに結論づけることはできません。端末のプロセスは正規の管理作業かもしれず、時計補正にも測定誤差があります。認証成功、権限変更、データアクセスが同じユーザー・端末・セッションに結び付くかを追加で確かめ、直接確認できる行と仮説の行を区別します。NIST SP 800-61 Rev.3 の RS.AN-03 は、事故中に起きたイベントの順序と各イベントに関与した資産・リソースを特定し、脆弱性、脅威、脅威行為者、根本原因を分析することを推奨しています。

委託先やSaaSのログが含まれる場合、発見時刻、通知時刻、更新時刻を混同しないことも重要です。契約上の初報や更新を時系列へ追加するときは、技術イベントの発生時刻と、委託先が通知した時刻を別行として残します。通知の期限や最低限の項目を整理する場合は、SaaS委託先の事故通知条項の考え方も参考になります。

4. 欠落したログを「発生していない」と解釈しない

ある時刻に記録がないことは、その活動がなかったことと同じではありません。監視対象外のネットワークを通った、ログ保持期間が過ぎた、フィルターで除外された、転送や収集が止まった、サービス側の出力にそのイベント種別が含まれない、といった理由で記録が残らない可能性があります。欠落の理由が分からない場合は、空白を埋める推測をせず、「このデータ源では確認できない」と書きます。

空白の種類	確認すること	報告上の表現
監視範囲の外	対象サブネット、端末、アカウント、サービスが収集対象だったか	「対象範囲外のため確認できない」
保持・検索の制約	保持期限、検索時間範囲、アーカイブ、削除ポリシー	「保持期間を超え、存在を判断できない」
転送・取込の失敗	エージェント状態、キュー、取込エラー、欠損率、停止時間	「収集状態に空白があり、発生有無は未確認」
記録仕様の違い	成功だけを記録するか、失敗・読み取り・管理操作も記録するか	「仕様上、この活動を直接確認できない」
消去・改変の可能性	管理者操作、侵害後の削除、保存先の完全性、複製の差分	「欠落理由の候補として調査継続」

NIST SP 800-86 は、利用できるネットワークデータが包括的でないことが多く、失われたデータがある場合でも、利用可能なデータと技術的知識に基づく欠落データへの仮定を使って、方法論的に結論を組み立てる必要があると説明しています（6.4.3、pp.6-14–6-15）。同じ節は、すべてのデータ源を探し、事故を再構成し、重大性と影響を判断できるだけのデータを検証・分析するよう求めています。ここでの「仮定」は証拠ではないため、証拠IDを持つ事実の欄へ混ぜません。

たとえば、00:10から00:20まで端末ログがなく、00:14にIdPの認証成功、00:18にクラウドのデータアクセスがある場合、端末ログの空白を理由に端末活動がなかったとは言えません。端末が監視対象外だったのか、エージェントが停止していたのか、保持処理に失敗したのかを確認し、分からなければ「00:10–00:20は端末側の活動を確認できない」と報告します。クラウドアクセスが端末から直接行われたという説明は、送信元IPやデバイス情報など別の根拠がある場合に限って仮説として示します。

5. 事実・推定・結論を分けて報告する

最終報告には、単一のきれいなストーリーではなく、根拠と不確実性が追える時系列を載せます。各行に証拠ID、原記録、正規化後のイベント時刻、時計の補正、取込遅延、信頼度、確認できない点を入れます。信頼度は「高・中・低」のようなラベルだけにせず、直接記録なのか、複数の独立した記録が一致したのか、推定誤差がどれだけあるのかを短く添えます。

区分	書き方の例	次に確認すること
確認済みの事実	00:10:04 UTCにIdPがユーザーUのサインイン成功を記録した。証拠ID I-014。	原記録、オフセット、セッション発行記録を照合
合理的な推定	端末の時計補正後、00:08:30 UTC頃に認証情報を使うプロセスが起動した可能性がある。	プロセスの署名、端末の別ログ、補正誤差を確認
未確認の空白	00:10–00:20 UTCの端末ログは収集状態を確認できず、活動の有無を判断できない。	エージェント、キュー、保持先、対象範囲を確認
結論の範囲	Uのセッションで権限変更が行われたことは確認できるが、実行者本人や最初の侵入口は確定できない。	追加の認証要素、端末、委託先記録を調査

「最も早い記録」を「最初の活動」と呼ばないことも大切です。記録が遅れて届いた、監視していない活動が先にあった、攻撃者が時刻や記録を変更した、という可能性があります。報告書の冒頭に対象期間とデータ源の範囲、末尾に未解決の仮説と追加調査の条件を置くと、後から新しいログが見つかった際に結論を更新しやすくなります。

事故が顧客や利用者へ影響した場合、技術的な発生時刻と、サービスの障害・影響を告知した時刻は別の時計です。影響範囲が確定していない段階では、確認済みの事実、調査中の範囲、次回更新予定を分けて表現します。顧客向けの初報と復旧後報告の構成は、SaaS障害告知の書き方のように、更新時刻と復旧判定を技術イベントの時刻から分離して設計します。

NIST SP 800-61 Rev.3 は、調査中に判明した事実と対応行動の記録、その記録の完全性・来歴の保持を RS.AN-06 で示し、RS.AN-07 ではインシデントデータとメタデータを収集し、その完全性と来歴を保つことを求めています（pp.28–29）。時系列表は結論を飾る図ではなく、どのデータをいつの基準で読み、どこから先が推定なのかを説明する監査可能な記録として扱います。

よくある質問

タイムゾーンの違いと、端末の時計のずれは同じですか？

同じではありません。タイムゾーンの違いは、同じ瞬間を別のオフセットで表示している差です。端末の時計のずれは、同じタイムゾーンへ直しても機器の表示自体が基準時計から進んだり遅れたりしている差です。前者はオフセットを保存してUTCへ変換し、後者は基準時計との差と誤差を測定して別に記録します。

取込が遅れたログは、発生時刻を取込時刻へ置き換えますか？

置き換えません。発生元が記録したイベント時刻と、SIEMやAPIが受信した取込時刻を別列で保持します。取込遅延が分かれば差を記録し、発生元時刻がない場合は受信時刻から発生時刻を逆算せず、確認不能と表示します。

ログがない区間は、攻撃や操作がなかったと判断できますか？

できません。監視範囲外、保持期限、フィルター、転送停止、仕様上の未記録など、複数の理由があります。欠落理由を確認できないときは「このデータ源では確認できない」とし、別のデータ源から裏付けが得られた場合だけ、限定した推定を示します。

イベントの時刻を秒単位で確定できない場合はどうしますか？

ログの精度に合わせて、分単位や時間帯として示します。秒まで表示されていても、時計のずれや記録精度を確認できなければ、秒単位の確実性を主張しません。時刻の範囲、根拠、誤差の理由を併記します。

SIEMが作ったタイムラインをそのまま報告に使えますか？

SIEMの相関結果は調査を速める補助資料です。原記録、変換規則、相関キー、取込遅延、重複除去の条件を確認し、必要な行は元のデータ源へ戻って照合します。表示順が正しいことだけで、発生順や原因まで証明したことにはなりません。

証拠保全と時系列整理は、どこまで同じ作業ですか？

証拠保全は原本を変更せず、取得者・取得時刻・ハッシュ・保管・受渡しを追跡できる状態にする作業です。時系列整理は、その保全済みデータを読み、時刻を正規化し、イベントを相関し、事実と推定を分ける分析です。前者の手順や記録は、後者の根拠を守るために必要ですが、目的は異なります。

参考情報

• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response（3.3、4.2.3、4.4、6.4.3、8.2）
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management（RS.AN-03、RS.AN-06、RS.AN-07）