ログ取得～分析に向けた留意事項

最後に、本章では、取得・分析の目的設定後のステップである、ログの取得、保存・保全、点検・分析に向けて、仕様検討時における基本的な留意事項を提示する。

技術面での留意事項

ログ取得における留意事項

取得対象ログの選定

本書では取得すべきログ種類の具体例を示しているが、実際に検討する場合は、分析に必要な情報が自システムのどのコンポーネントのどのログに記録されるかを事前に把握することが不可欠である。その際、ACSCが策定し、NCO、JPCERT/CC、CISA等が共同署名して公開している「Priority Logs for SIEM Ingestion Practitioner Guidance」等の国際的なガイダンスを活用することが有効である。同ガイダンスでは、詳細なログカテゴリ、各カテゴリに含まれる情報要素、及び取得優先度が体系的に整理されており、自システムの構成に基づいて必要な情報源と取得優先順位を決定する際の指針となる。

また、システムの設計段階で定義したログが、設定ミスやシステムリソース不足等により実際には取得できていないケースや、想定した脅威を検知するために必要な情報がそもそも取得されていないケースも散見される。システム開発時、並びに導入・運用時においては、設計書に記載されたログが想定どおりに出力されているか、また出力されたログによって必要な分析が実施できるかを確実に確認することが必要である。複数システムでログを集約して分析することを想定する場合は、ログ出力形式を事前に標準化し、遵守することが望ましい。

なお、システムから取得できるログだけでは、操作者を特定できないケース（例：共有アカウントの使用、認証の安全性が疑わしい場合）も想定される。そのような場合には、分析範囲を保守・管理端末等のエンドポイントまで広げる必要が生じる可能性があるため、エンドポイントでの適切なログ出力の設定と管理を行うことも重要である。また、BYODとして私用端末を使用している場合、情報の不正な持ち出し等、セキュリティ上特に懸念があることから、MDM等の手段を用いて、操作ログを取得し、厳格に管理することが不可欠である。

時刻同期

正確に事象を追跡するためには、ログを出力する各システムの時刻が適切に同期していなくてはならない。時刻の不整合は、複数システムにまたがるセキュリティインシデントの因果関係の特定や時系列分析を困難にし、脅威の特定やインシデント対応の遅延を招くため、NTP（Network Time Protocol）等を用いた時刻同期の仕組みを導入することが必要である。また、複数システムからログを集約して横断的に分析する場合、システムによって、ローカル時間（例：JST）やUTC（協定世界時）等、採用しているタイムゾーンが異なるケースがある。このような場合、時刻の整合性が失われ、分析の精度や効率が著しく低下する。したがって、原則ログ出力時にはUTCで統一し、ログにタイムゾーン情報（例：UTCの場合末尾に「Z」）を付加した上で、分析時にローカル時間へ変換するような仕組みが望ましい。

さらに、システムによっては、事象の発生から記録媒体への保存にタイムラグが生じるケースがある。このような場合、発生時刻ではなくログの保存時刻が記録されていることがあり、正しく時系列を把握することが困難となる。このため、保存時刻ではなく、対象事象の発生時刻が正しく記録されていることを確認することも必要である。

利用者の特定

ログ分析においては、否認防止の観点から、操作主体の特定が重要である。そのため、作成した全てのアカウントの利用ユーザを一意に特定し、管理台帳等で記録・管理することが必要である。また、出力されるログには必ず操作主体を一意に識別する情報が含まれている必要があることから、共有アカウントの使用は避けるべきである。ただし、システム制約や運用上の理由により、共有アカウントの使用を避けられない場合は、個人アカウントで踏み台サーバにログインし、そこから共有アカウントを用いて対象システムにアクセスさせた上で、当該サーバ上で行われた全ての操作をログとして取得する方法や、共有アカウントの使用にあたって事前承認を求めるワークフローを策定する方法、IPアドレス制限等により接続元を制限する方法等、リスクを低減する代替策が必要である。

要機密情報の混入への対応

ログには意図せず個人情報や要機密情報が記録されるリスクが存在する。例えば、エラーログへの認証情報（例：パスワード、2要素認証コード）の混入やアプリケーションログへの個人情報（例：氏名、マイナンバー）の混入、URLパラメータに含まれるトークンの記録等が考えられる。また、ログ単体では個人情報に該当しない場合でも、複数のログを組み合わせた分析により、個人を識別可能となるケースもある。したがって、システム設計段階から、ログに個人情報や要機密情報が含まれないよう十分に配慮するとともに、混入の可能性を完全に排除できない場合は、個人情報保護法等の関連法令を遵守し、脅威の検知等の正当な目的の範囲内で、その目的達成に必要最小限の情報のみを取得する、利用目的を明示する、目的外利用を禁止する、マスキング処理を施す等の適切な安全管理措置を講じる必要がある。

ログ保存・保全における留意事項

保存期間

ログの保存期間は、統一基準が推奨する1年間以上を基準としつつ、保存コスト、情報の重要度、及び適用される法規制等を総合的に勘案して決定する必要がある。例えば、ネットワークフローログは大容量データとなるため、費用対効果を考慮して数か月から1年程度の保存とする。一方、サーバ監査ログはサービス提供及びデータ管理の根拠として重要性が高いため、1年以上の長期保存とするといった対応も考えられる。なお、高度な標的型攻撃では侵入から検知まで長期間を要する事例が存在することから、特に機密性の高い情報を扱うシステムでは保存期間の延長を検討すべきである。

また、保存コストを抑えるためには、分析目的を踏まえた最適化も必要である。具体的には、ストレージの階層化が有効である。例えば、即時に分析が必要な場合には、直近（例：3ヶ月）のログを即時検索可能な高速ストレージに保存し、一定期間経過後は長期保存に適した安価なストレージに移動する方式が推奨される。一方、フォレンジック目的のようにログへのアクセス頻度が低い用途では、保存コストが安く、アクセス速度が低速なストレージ方式を選択することで、可用性とコストのバランスを確保することができる。

改ざん防止

証跡であるログ自体が改ざんされないよう、ログは保護された場所に保存されている必要がある。具体的には、Write Once Read Many（WORM）メディアへの記録、またはログ生成元システムから独立した専用システムやストレージへの定期的な転送・保存を行うこと等が望ましい。また、改ざん検知のために、ログファイルに対するハッシュや電子署名の付与も有用である。加えて、内部不正による改ざん防止のため、最小権限の原則に基づき、システム運用者とログ管理者/アナリストの職務分離を行い、適切なアクセス制御を実現する必要がある。

暗号化

ログには個人情報や要機密情報が含まれる可能性があるため、保存時及び転送時の暗号化を実施すべきである。これにより、不正アクセスや通信路上での盗聴によるログの漏えいリスクを低減することができる。

バックアップ

ログのバックアップを定期的に取得し、災害やシステム障害時、サイバー攻撃時においてもログが失われないように、出力元のシステムとは異なるネットワーク上に保存することが望ましい。また、バックアップが利用可能であることを確認するために、分析ツールに取り込んで確認する等を行い、定期的に検証する手順を文書化する必要がある。

ログ保存の監視

ログ保存の仕組み自体が停止していることに気付かず、ログ分析が必要になった際に必要なログが存在しないという事態を避けるため、ログの保存状況及び保存期間に基づく削除の実施状況を継続的に監視する必要がある。具体的には、ログ保存プロセスの稼働状況、ログファイルの生成状況、及びストレージ容量を定期的に監視し、異常時には管理者へ自動通知する仕組み等を実装することが望ましい。

ログ点検・分析における留意事項

分析頻度

ログ分析の頻度は、目的に応じてリアルタイム分析、定期分析、及び随時分析の三種に分類される。リアルタイム分析は、不正な通信の検知やセキュリティ製品によるアラート発報等、即座に対処すべき脅威の分析を対象とする。定期分析は、特権ユーザの操作ログやシステム構成変更ログ等の監査目的の分析や、未知の脅威検出を目的として定期的に実施する能動的な分析を対象とする。随時分析は、セキュリティインシデント発生時の調査等、必要に応じて実施するものである。なお、定期分析の実施間隔は、月次から隔月程度とし、可能な限り短期間で実施することが望ましい。これは脅威の早期検知に加え、分析対象ログの蓄積量を適切な範囲に抑制する目的がある。分析間隔が長期化した場合、異常検知の遅延に加え、ログ量の肥大化による分析効率の著しい低下を招くリスクが生じる。

ログ分析に資するソリューションの活用

ログを集約・保存・分析するためのソリューションは多様に存在しており、これらを活用することで、組織が自ら詳細な分析を行わずとも、自動的に不審な事象を検知し、アラートを発報することが可能となる。ログ分析プロセスの設計にあたっては、こうしたソリューションを有効に利用することを検討することが望ましい。以下では、ログ分析に有効なソリューションの代表例を示す。

表5-1 ログ分析に有効なソリューション例

ログアナリストの不正監視

前述したとおり、ログには機密性の高い情報が含まれる場合がある。例えば、操作ログには役員が作成したファイルの名前や送信したEメールの件名等、本来非公開とすべき情報が記録されることがある。分析を担当するログアナリストは、業務上これらのログへのアクセス権限を有しているが、その権限を悪用して職務上必要な範囲を超えた情報閲覧を行うリスクが存在する。また、不必要に職員の私的内容を閲覧することは重大なプライバシーリスクになることに留意する必要がある。このような内部不正を防止・検知するためには、ログ分析にかかる運用ルールの中で禁止事項を明文化し、分析業務に従事する前に留意事項をアナリストに教育するとともに、職務やログに含まれる情報の機密度を考慮してログへのアクセス権限を適切に付与した上で、ログアナリスト自身の活動を監視する仕組みが不可欠である。具体的には、ログアナリストがログ分析システムに対して実行した検索クエリや閲覧履歴を記録した操作ログを保存し、これを定期的に調査する必要がある。

セキュリティ機能の監視

ログ分析においてはセキュリティ製品（例：EDR）やOSのセキュリティ機能が出力するログも重要な情報源となるが、攻撃者によるこれらの機能の無効化や、システム不具合による動作停止のリスクが存在する。したがって、セキュリティ機能の稼働状態をログとして取得・監視し、正常動作を確認する仕組みを自動または手動により定期的に実施することが必要である。

AIの活用

近年では、AI技術を活用したログ分析により、従来は検知が困難であった異常パターンの発見や、大量のログからの効率的な脅威抽出が可能となっている。しかし、学習データの偏りによる誤検知や、AIの判断根拠の不透明さに伴う説明責任の不履行等、AIの利用にはリスクも伴うことに注意が必要である。これらのリスクを適切に考慮した上で、AIを活用した異常検知や脅威インテリジェンスの統合等、最新技術の導入も積極的に検討することが望ましい。

体制・プロセス面での留意事項

人員確保

ログ分析を適切に行うためには、ログの取得、保存・保全といった運用管理だけでなく、ログ分析に要する工数を考慮した人員体制の確保が不可欠である。特にセキュリティインシデントが発生した際には、原因究明や影響範囲の特定のため、膨大な量のログを短時間で精査する必要が生じる。このため、各組織においては、平時から以下のような観点を踏まえた人員体制[^8]を整備する必要がある。

• ログ分析に必要なスキルを有する人材の配置

• セキュリティインシデント発生時に迅速に対応できる要員の確保

• 通常業務との兼ね合いを考慮した体制設計

また、セキュリティインシデント発生時においては、ログ分析を担当する部門とCSIRTが緊密に連携することが重要である。具体的には、以下のような役割分担と、運用ルール・プロセス（エスカレーション基準、連絡手段、情報共有の方法等）を平時から明確にしておくことが望ましい。

表5-2 一般的な役割分担例

なお、ログ分析に必要なスキルや要員数は、組織環境や脅威状況の変化によって時間経過とともに変わり得るため、契約更新等のタイミングで見直すことが望ましい。また、人員体制の確保が困難な場合は、外部の専門事業者の活用や、自動化ツールの導入による分析負荷の軽減も検討する必要がある。こういった人員やツール等の導入に必要な予算を確保するためにも、企画段階からログ分析に関する要件を検討することが肝要である。

情報共有とエスカレーション

他府省庁や民間企業も被害を受ける可能性のある攻撃やセキュリティインシデントについては、他組織での被害を未然に防ぐために、組織横断的な情報共有を行うことが望ましい。情報共有を実効的なものとするためには、各組織において他組織への情報共有方法をあらかじめ検討し、ログ保存・保全及び分析により得られた知見を、自組織に留めることなく、共有可能な形で整理しておくことが必要である。なお、迅速に情報共有を行うためには、事前に組織内ルールとして整備しておくことも必要である。[^9]

また、インシデント対応のフェーズに応じて、5W1Hの情報の優先順位は変化する。初期対応においては被害拡大の防止が最重要となるため、特にWhen（いつ）、Where（どこで）、Who（誰が）、What（何が）の特定を優先し、Why（なぜ）、How（どのように）といった原因究明に必要な情報は相対的に優先度を下げることで、分析リソースを適切に配分する必要がある。セキュリティインシデント発生時のエスカレーションフローについても、システム設計段階で定義し、関係者間で事前に合意しておく必要がある。