ログ

Logging Cheat Sheet

原典: Logging Cheat Sheet（OWASP Cheat Sheet Series）
原文: GitHub 上の Markdown
底本: bac04fb5（2026-07-29 時点）
ライセンス: CC BY-SA 4.0（原典と同一。訳文も同ライセンスで再配布できます）

はじめに

このチートシートは、アプリケーションのログの仕組みを構築するための指針、とくに安全性に関わるログについての指針を開発者へ集約して示すことに主眼を置いている。

多くのシステムでネットワーク機器、OS、Web サーバー、メールサーバー、データベースサーバーのログは有効になっているが、アプリケーション独自の事象のログは欠けていたり、無効になっていたり、設定が不十分だったりすることが多い。それは基盤のログだけの場合よりはるかに深い洞察を与える。 Web アプリケーション（サイトや Web サービス）のログは、Web サーバーのログを有効にしておくこと（Extended Log File Format を使うなど）よりはるかに広い営みである。

アプリケーションのログは、そのアプリケーション内で一貫し、組織のアプリケーション群をまたいでも一貫し、関係する場面では業界の標準を使うべきである。そうすれば記録した事象のデータを、多様なシステムによって取り込み、相関させ、分析し、管理できる。

目的

アプリケーションのログには、安全性に関わる事象を必ず含めるべきである。アプリケーションのログは、安全性の用途にも運用の用途にも貴重なデータである。

運用の用途

一般的な不具合の調査
基準値の確立
業務プロセスの監視（販売プロセスの離脱、取引、接続など）
問題や異常な状態についての情報の提供
性能の監視（データの読み込み時間、ページのタイムアウトなど）
その他の業務固有の要件

安全性の用途

アプリケーションのログは、次のような他の種類の事象の記録にも使われうる。

自動化への対抗の監視
セキュリティ事故の特定
方針違反の監視
否認防止の対策の補助（ただしログの信頼性は、記録する側が適切に監査されていることに依拠することが多く、デジタル署名のような仕組みをここで活用するのは難しいため、否認防止という性質をログで達成することは難しい）
監査の記録（データの追加、変更、削除、データの持ち出しなど）
法令遵守の監視
その後の情報開示の要求（本人によるデータ開示請求、情報公開請求、訴訟、警察やその他の規制当局の調査など）のためのデータ
法的に認められたデータの傍受（アプリケーション層での通信の傍受など）
他のログの情報源では欠けている、事故調査のためのアプリケーション固有のデータの提供
攻撃の検知を通じて、脆弱性の特定と悪用に対する防御を助けること

プロセスの監視、監査、取引のログや記録などは、通常は安全性に関わる事象のログとは異なる目的で収集される。そのため、しばしばそれらは分けて保持するべきである。

収集する事象の種類と詳細も異なるものになる。

たとえば PCI DSS の監査ログは、帰属可能な取引の元来の順序を判定するための再構成、確認、検査を可能にする、独立に検証可能な記録を提供するために、活動の時系列の記録を含む。記録が多すぎても少なすぎてもいけない。

何を、いつ、どれだけ記録するかは、意図した目的についての理解を手引きとする。このチートシートの残りは、主に安全性に関わる事象のログを論じる。

設計、実装、テスト

事象データの情報源

アプリケーション自身が、ログの項目を生成するために使うべき幅広い情報の事象にアクセスできる。したがって主要な事象データの情報源は、アプリケーションのコード自身である。

アプリケーションは、利用者について（身元、役割、権限など）と、事象の文脈について（対象、動作、結果）最も多くの情報を持つ。そしてこのデータは、基盤の機器や、密接に関係するアプリケーションでも得られないことが多い。

アプリケーションの利用についての情報源として、他に検討できるものを挙げる。

クライアントのソフトウェア（デスクトップのソフトウェアやモバイル端末での動作をローカルのログに記録する、あるいはメッセージングの技術を使う。AJAX 経由の JavaScript の例外ハンドラ、Content Security Policy（CSP）の報告の仕組みを使うブラウザなど）
埋め込まれた計測のコード
ネットワークのファイアウォール
ネットワークとホストの侵入検知システム（NIDS と HIDS）
密接に関係するアプリケーション（Web サーバーソフトウェアに組み込まれたフィルタ、独自のエラーページやハンドラへの Web サーバーのリダイレクトや書き換えなど）
アプリケーションのファイアウォール（フィルタ、ガード、XML ゲートウェイ、データベースファイアウォール、Web アプリケーションファイアウォール（WAF）など）
データベースのアプリケーション（自動の監査記録、トリガーに基づく動作など）
評判の監視サービス（稼働状況やマルウェアの監視など）
他のアプリケーション（不正監視、CRM など）
OS（モバイルのプラットフォームなど）

異なる信頼の領域にあるシステムから事象データを取り込むときは、その事象の情報に対する確度を考慮しなければならない。データは欠けている、改変されている、偽造されている、再送されている、そして悪意あるものである可能性があり、常に信頼できないデータとして扱わなければならない。

その情報源をどう検証できるか、完全性と否認防止をどう強制できるかを検討する。

事象データをどこに記録するか

アプリケーションは一般に、事象のログのデータをファイルシステムかデータベース（SQL または NoSQL）に書き込む。デスクトップやモバイル端末に導入されたアプリケーションは、ローカルの記憶領域とローカルのデータベースを使うことも、リモートの記憶領域へデータを送ることもある。

選んだフレームワークによって選択肢は限られうる。どの種類のアプリケーションも、（よりローカルな保存の代わりに、あるいはそれに加えて）リモートのシステムへ事象データを送りうる。

その送り先は、ログを集約して管理するシステム（SIEM や SEM など）や、別の場所にある他のアプリケーションでありうる。実行環境が管理できるよう、アプリケーションが事象のストリームをバッファせずに単に標準出力へ送れるかも検討する。

ファイルシステムを使う場合、OS や他のアプリケーションのファイル、利用者が生成したコンテンツが使うものとは別のパーティションを使うのが望ましい
- ファイルに基づくログでは、どの利用者がそのディレクトリにアクセスできるか、およびディレクトリ内のファイルの権限について、厳しい権限を適用する
- Web アプリケーションでは、ログを Web からアクセスできる場所に露出させるべきではない。そうする場合はアクセスを制限し、（HTML ではなく）平文の MIME タイプで設定する
データベースを使う場合、ログデータの書き込みにのみ使う専用のデータベースアカウントを用い、データベース、テーブル、関数、コマンドの権限を非常に厳しく制限するのが望ましい
事象データやログファイルを他のシステムへ記録し送るには、標準の形式を安全なプロトコルの上で使う（syslog 上の Common Log File System（CLFS）や Common Event Format（CEF）など）。標準の形式は集約されたログのサービスとの統合を容易にする

エラーのスタックトレースや HTTP のリクエストと応答のヘッダおよび本体の記録のような、拡張された事象の情報には別のファイルやテーブルを使うことを検討する。

どの事象を記録するか

安全性の監視、警報、報告の水準と内容は、プロジェクトの要件と設計の段階で定める必要があり、情報セキュリティのリスクに見合ったものであるべきである。それを踏まえて、何を記録すべきかを定義できる。

万能の解決策はない。機械的なチェックリストの方法は不必要な「警報の霧」を招き、本当の問題が検出されないままになりうる。

可能なかぎり、常に次を記録する。

入力検証の失敗（プロトコルの違反、受け入れられないエンコーディング、不正なパラメータ名と値など）
- 離散的で有限な正当な値の一覧（ドロップダウンから選ぶ国名など）に対する検証の失敗には、専用の事象を設ける。これは攻撃の活動でしかありえないので、重大な安全上の事象である。たとえば input_validation_fail[:field,userid] のようにする。
出力検証の失敗（データベースのレコード集合の不一致、不正なデータのエンコーディングなど）
認証の成功と失敗認証の失敗した試行は、総当たり、クレデンシャルスタッフィング、パスワードスプレーのような資格情報に関する攻撃の重要な早期の兆候になる。同じアカウントに対する繰り返しの失敗、複数の IP アドレスからの失敗、短時間に集中したログイン試行を監視すれば、アカウント乗っ取りの試みが成功する前に検知できる。これは「認証の成功と失敗」を常に記録しなければならないという本チートシートの指針に沿う。これらの事象はセキュリティ事故の特定と事故調査の支えに不可欠である。認証の失敗のログの要件は OWASP ASVS 7.1.1 を参照する。
認可（アクセス制御）の失敗
セッション管理の失敗（Cookie のセッション識別値の改変、JWT の検証の疑わしい失敗など）
アプリケーションのエラーとシステムの事象（構文と実行時のエラー、接続の問題、性能の問題、サードパーティのサービスのエラーメッセージ、ファイルシステムのエラー、アップロードされたファイルのウイルス検出、設定の変更など）
アプリケーションおよび関連システムの起動と停止、ログの初期化（開始、停止、一時停止）
より高いリスクを伴う機能の利用。次を含む。
- 利用者管理の操作（利用者の追加や削除、権限の変更、利用者へのトークンの割り当て、トークンの追加や削除など）
- システム管理者の権限の使用、あるいはアプリケーションの管理者によるアクセス。それらの利用者によるすべての動作を含む
- 既定のアカウント、共有アカウント、緊急時用のアカウントの使用
- 決済カード会員データのような機微なデータへのアクセス
- 暗号鍵の使用やローテーションのような暗号に関わる活動
- システム水準のオブジェクトの作成と削除
- データの取り込みと持ち出し（画面上の帳票を含む）
- 利用者が生成したコンテンツの投稿と処理。とくにファイルのアップロード
- デシリアライズの失敗
- ネットワークの接続と関連する失敗（バックエンドの TLS の失敗（証明書の検証の失敗を含む）、想定外の HTTP メソッドによるリクエストなど）
法的なものやその他の同意（モバイル端末の機能の許可、利用規約、規約と条件、個人データ利用の同意、マーケティングの連絡を受ける許可など）
疑わしい業務ロジックの活動。次のようなもの。
- 一連の動作を順序を外れて行おうとする、あるいは流れの制御を回避しようとする試み
- 業務上の文脈で意味をなさない動作
- 特定の動作の制限を超えようとする試み

次の事象を記録できるか、またそれが望ましい情報かを任意で検討する。

順序の失敗
過剰な利用
データの変更
不正やその他の犯罪的な活動
疑わしい、受け入れられない、想定外の振る舞い
設定への変更
アプリケーションのコードのファイルやメモリの変更

事象の属性

各ログの項目には、その後に意図される監視と分析に十分な情報を含める必要がある。それは完全な内容のデータでもありうるが、抜粋か要約された属性であることのほうが多い。

アプリケーションのログは、各事象について「いつ、どこで、誰が、何を」を記録しなければならない。

これらの属性はアーキテクチャ、アプリケーションの分類、ホストのシステムや機器によって異なるが、しばしば次のものを含む。

いつ
- 記録の日時（国際的な形式）
- 事象の日時。事象のタイムスタンプは記録の時刻と異なりうる。クライアントのアプリケーションが、周期的あるいは断続的にしかオンラインにならないリモートの機器で動いている場合のサーバー側の記録など
- 対話の識別子（注記 A）
どこで
- アプリケーションの識別子（名前とバージョンなど）
- アプリケーションのアドレス（クラスタ名やホスト名、サーバーの IPv4 または IPv6 アドレスとポート番号、ワークステーションの識別、ローカルの機器の識別子など）
- サービス（名前とプロトコルなど）
- 地理的な位置
- ウィンドウ、フォーム、ページ（Web アプリケーションであれば入口の URL と HTTP メソッド、ダイアログボックスの名前など）
- コードの位置（スクリプト名、モジュール名など）
誰が（人間または機械の利用者）
- 送信元アドレス（利用者の機器の識別子、利用者の IP アドレス、基地局の ID、携帯電話番号など）
- 利用者の身元（認証済みか他の方法でわかっている場合。利用者のデータベースのテーブルの主キーの値、ユーザー名、免許番号など）
何を
- 事象の種類（注記 B）
- 事象の深刻度（注記 B）。{0=emergency, 1=alert, ..., 7=debug}、{fatal, error, warning, info, debug, trace} など
- 安全性に関わる事象であることの標識（ログに安全性以外の事象のデータも含む場合）
- 説明

加えて、次の記録も検討する。

副次的な時刻の源（GPS など）による事象の日時
動作。そのリクエストの元来の意図された目的（ログイン、セッション ID の更新、ログアウト、プロフィールの更新など）
対象。影響を受けた構成要素やその他の対象（利用者アカウント、データのリソース、ファイル）。URL、セッション ID、利用者アカウント、ファイルなど
結果の状態。対象に対する動作が成功したかどうか（成功、失敗、保留など）
理由。上記の状態がなぜ生じたか（データベースの確認で利用者が認証されなかった、資格情報が誤っていたなど）
HTTP のステータスコード（Web アプリケーションのみ）。利用者に返されたステータスコード（多くは 200 か 301）
リクエストの HTTP ヘッダまたは HTTP の User Agent（Web アプリケーションのみ）
利用者の種類の分類（公開、認証済みの利用者、CMS の利用者、検索エンジン、認可されたペネトレーションテストの担当者、稼働監視など。後述の「除外すべきデータ」を参照）
事象の検知に対する分析上の確度（注記 B）。低、中、高、あるいは数値
利用者が見た応答、あるいはアプリケーションが採った対応（ステータスコード、独自のテキストメッセージ、セッションの終了、管理者への警報など）
拡張された詳細（スタックトレース、システムのエラーメッセージ、デバッグの情報、HTTP のリクエスト本体、HTTP の応答のヘッダと本体など）
内部の分類（責任、法令遵守の参照など）
外部の分類（NIST の Security Content Automation Protocol（SCAP）、MITRE の Common Attack Pattern Enumeration and Classification（CAPEC）など）

これらについてさらに詳しくは、末尾に挙げた「その他」の関連資料、とくに Anton Chuvakin と Gunnar Peterson による網羅的な記事を参照する。

注記 A：「対話の識別子」は、単一の利用者の対話（デスクトップアプリケーションのフォーム送信、ページの要求、モバイルアプリのボタン押下、Web サービスの呼び出しなど）に関わる（関連する）すべての事象を結びつける方法である。アプリケーションはこれらの事象がすべて同じ対話に関係することを知っているので、その情報を失って後の相関の手法に個々の事象の再構成を強いるのではなく、それを記録すべきである。たとえば単一の SOAP リクエストが複数の入力検証の失敗を持ち、それが少しずつ異なる時刻にまたがることがある。別の例として、アプリケーションからデータベースサーバーへ送られた長時間の「サーガ要求」では、出力検証の失敗が入力の投入よりはるかに後に起こりうる。

注記 B：各組織は、事象の分類（種類、確度、深刻度）、説明の構文、日時の形式を含む項目の長さとデータ型について、一貫した文書化された方針を持つべきである。

除外すべきデータ

法的に認められていないデータは決して記録しない。たとえば一部の通信の傍受、従業員の監視、同意のないデータの収集は、いずれも違法でありうる。

他の内部のシステム、「信頼できる」サードパーティ、検索エンジンのロボット、稼働やプロセスの監視やその他のリモート監視のシステム、ペネトレーションテストの担当者、監査担当者といった「既知の」利用者の事象を除外してはならない。ただし、記録するデータにそれぞれの分類の標識を含めたいことはあるだろう。

次のものは通常、ログに直接記録するべきではなく、除去、マスク、サニタイズ、ハッシュ化、暗号化するべきである。

アプリケーションのソースコード
セッション識別値（セッション固有の事象を追跡する必要があれば、ハッシュ値への置き換えを検討する）
アクセストークン
機微な個人データ、および一部の形態の個人を特定できる情報（健康、政府発行の識別子、弱い立場にある人々に関するものなど）
認証のパスワード
データベースの接続文字列
暗号鍵とその他の主要なシークレット
銀行口座や決済カード会員のデータ
ログのシステムに保存が許されている水準より高い機密区分のデータ
商業上機微な情報
該当する法域で収集が違法な情報
利用者が収集を拒否した、あるいは同意していない情報（トラッキング拒否の指定、収集の同意が失効している場合など）

次のデータも存在することがあり、その後の調査には有用であるものの、事象を記録する前に何らかの特別な扱いを必要とすることがある。

ファイルのパス
データベースの接続文字列
内部のネットワークの名前とアドレス
機微でない個人データ（氏名、電話番号、メールアドレスなど）

個人の身元が必要でない場合、あるいはリスクが大きすぎるとみなされる場合は、直接および間接の識別子の削除、撹乱、仮名化のような個人データの非識別化の手法を使うことを検討する。

システムによっては、ログの収集後、表示の前にサニタイズを行える。

設定可能なログ

ログの水準（深刻度や脅威の水準に基づく事象の種類、記録する詳細の量）を変えられるようにすることが望ましい場合もある。これを実装する場合は、次を満たす状態にする。

既定の水準が業務上の必要に十分な詳細を与える
アプリケーションのログ、あるいは法令遵守の要件に必要な事象のログを完全に無効化できないようにする
ログの水準や範囲の変更は、アプリケーションに内在するものである（承認されたアルゴリズムに基づいてアプリケーションが自動的に行う）か、変更管理の手続きに従う（設定データの変更、ソースコードの修正など）
ログの水準を定期的に検証する

事象の収集

開発のフレームワークが適切なログの仕組みに対応しているなら、それを使うか土台にする。そうでなければ、他のモジュールや構成要素から呼び出せるアプリケーション全体のログハンドラを実装する。

組織固有の事象の分類と説明の構文の要件を参照する形で、そのインタフェースを文書化する。

可能であれば、このログハンドラを徹底的にテストでき、複数のアプリケーションに配備でき、承認済みで推奨されるモジュールの一覧に加えられる標準のモジュールとして作る。

他の信頼の領域から来る事象データには入力検証を行い、正しい形式であることを確かめる（入力検証が失敗した場合は、記録せずに警報を出すことも検討する）
ログインジェクション攻撃を防ぐため、すべての事象データにサニタイズを行う（復帰（CR）、改行（LF）、区切り文字など。任意で機微なデータの除去も行う）
出力（記録）の形式に合わせてデータを正しくエンコードする
データベースへ書き込む場合は、SQL インジェクションのチートシートを読み、理解し、適用する
ログの処理やシステムの失敗が、アプリケーションのその他の動作を妨げたり、情報の漏出を許したりしない状態にする
すべてのサーバーと機器で時刻を同期する（注記 C）

注記 C：アプリケーションが他者の管理下にある機器（個人の携帯電話、別の企業ネットワーク上にあるリモートの顧客のワークステーションなど）で動いている場合、これは常に可能とはいえない。その場合は時刻のずれを測るか、事象のタイムスタンプに対する確度を記録することを試みる。

可能であれば標準の形式でデータを記録し、少なくとも業界標準の形式で持ち出しや配信ができる状態にする。

場合によっては、事象が中間の地点で中継されたり集約されたりする。後者では、中央の保管と分析のシステムへ転送する前に、一部のデータが集計または要約されることがある。

検証

ログの機能とシステムは、コードレビュー、アプリケーションのテスト、安全性の検証の手続きに含めなければならない。

ログが正しく、仕様どおりに動いていることを確かめる
事象が一貫して分類され、項目名、型、長さが合意された標準に対して正しく定義されていることを確認する
アプリケーションのセキュリティテスト、ファジング、ペネトレーションテスト、性能テストの最中にログが実装され有効になっている状態にする
その仕組みがインジェクション攻撃を受けないことを検査する
ログが行われるときに望まない副作用がない状態にする
外部のネットワーク接続が失われたとき（通常それが必要な場合）のログの仕組みへの影響を確認する
ログがシステムの資源を枯渇させるのに使えない状態にする。たとえばディスク領域を埋めたり、データベースのトランザクションログの領域を超えたりしてサービス妨害に至らないようにする
データベースの接続の喪失の模倣、ファイルシステムの領域不足、ファイルシステムへの書き込み権限の欠如、ログのモジュール自体の実行時エラーといったログの失敗が、アプリケーションに与える影響を検査する
事象のログのデータに対するアクセス制御を検証する
ログのデータが利用者に対する何らかの措置（アクセスの遮断、アカウントのロックアウトなど）に使われる場合、それが他の利用者へのサービス妨害（DoS）を引き起こすのに使えない状態にする

ネットワークのアーキテクチャ

例として、以下の図は顧客へ業務機能を提供するサービスを示す。ログを収集する集約されたシステムを作ることを推奨する。そうしたサービスは多数ありうるが、そのすべてが集約されたシステムへ安全にログを収集しなければならない。

この業務サービスのアプリケーションは、次のネットワークの区画に置かれる。

FRONTEND 1（DMZ、UI）
MIDDLEWARE 1（業務アプリケーション。サービスの中核）
BACKEND 1（サービスのデータベース）

安全性に関わる事象を含む IT の事象の収集を担うサービスは、次の区画に置かれる。

BACKEND 2（ログの保管）
MIDDLEWARE 3。二つのアプリケーション
- 保管領域からログを取得し、前処理して UI へ転送するログ読み込みのアプリケーション
- 業務アプリケーション、その他の基盤、クラウドのアプリケーションからログを受け取り、ログの保管領域へ保存するログ収集器
FRONTEND 2（業務サービスの事象のログを閲覧する UI）
FRONTEND 3（クラウドのアプリケーションからログを受け取り、ログ収集器へ転送するアプリケーション）
- 二つのアプリケーションの機能を一つにまとめてもよい

たとえば利用者からの外部のリクエストはすべて API 管理のサービスを経由する。 MIDDLEWARE 2 の区画のアプリケーションを参照する。

ログのネットワーク構成

上の図に見られるように、ネットワークの水準では、ログの保存と取得の処理は異なるネットワークのアクセス（ポート）を開けることを要し、矢印が異なる色で示されている。また保存と取得は異なるアプリケーションによって行われる。

sergiomarotco によるネットワーク分割の完全なチートシートはこちらにある。

配備と運用

リリース

ログの仕組みについての詳細をリリースの文書に加え、安全性の設定情報を提供する
アプリケーションやプロセスの所有者に、アプリケーションのログの仕組みを説明する
監視（後述）の出力が事故対応の手続きと統合されている状態にする

運用

ログが止まっていないかを検出し、改ざんや不正なアクセスと削除を特定する手続きを整える（後述の保護を参照）。

保護

ログの仕組みと収集した事象のデータは、転送中の改ざん、および保存後の不正なアクセス、変更、削除といった濫用から保護しなければならない。ログは個人情報やその他の機微な情報を含みうるし、そのデータはアプリケーションのコードとロジックに関する情報を含みうる。

加えて、ログに収集された情報そのものが（競合他社、噂を広める者、報道関係者、活動家にとって）事業上の価値を持つことがある。収益の推定を可能にする、あるいは従業員の業績についての情報を与えるといった形である。

このデータは端末、中間の地点、集約された保管領域、そして書庫やバックアップに保持されうる。

調査や抽出の際に、データの一部を除外、マスク、サニタイズ、ハッシュ化、暗号化する必要があるかを検討する。

保存時

改ざんの検出を組み込み、レコードが変更または削除されたかがわかる状態にする
ログのデータをできるだけ早く読み取り専用の媒体へ保存または複製する
ログへのすべてのアクセスを記録し監視しなければならない（事前の承認が必要な場合もある）
ログのデータを読む権限は制限し、定期的に見直すべきである

転送時

ログのデータを信頼できないネットワーク上で送る場合（収集のため、他所への転送のため、分析のため、報告のためなど）は、安全な転送プロトコルを使う
事象データの出所を検証する必要があるかを検討する
事象データをサードパーティへ送る前に、（規制と安全性の）相当な注意による確認を行う

さらに詳しい指針は NIST SP 800-92 Guide to Computer Security Log Management を参照する。

事象の監視

記録した事象のデータは確認できる状態にする必要があり、適切な監視、警報、報告の手続きが整っている必要がある。

アプリケーションのログを既存のログ管理のシステムや基盤（集約されたログと分析のシステムなど）に組み込む
事象の情報が適切なチームに届く状態にする
警報を有効にし、より深刻な事象については責任を持つチームへ直ちに知らせる
関連する事象の情報を他の検知システム、関係する組織、集約された情報収集と共有のシステムと共有する

ログの廃棄

ログのデータ、一時的なデバッグのログ、そしてバックアップ、複製、抽出物は、必要なデータ保持期間が終わる前に破棄してはならず、その期間を超えて保持してもならない。

法的、規制上、契約上の義務がこれらの期間に影響しうる。

ログに対する攻撃

ログは防御として有用であるがゆえに、攻撃の標的になりうる。 OWASP の Log Injection と CWE-117 も参照する。

機密性

誰が何を読めるべきか。機密性への攻撃は、認可されていない者がログに保存された機微な情報へアクセスすることを可能にする。

ログが利用者の個人情報を含む。攻撃者は個人情報を集め、それを公開するか、その利用者へのさらなる攻撃の足がかりにする。
ログがパスワードのような技術的なシークレットを含む。攻撃者はそれをより深い攻撃の足がかりにする。

完全性

どの情報を誰が変更できるべきか。

ログへの読み取りアクセスを持つ攻撃者が、それを使ってシークレットを持ち出す。
攻撃がログを足がかりに、ログのプラットフォームの悪用可能な側面へつながる。たとえば領域外書き込みを引き起こすために syslog 経由でペイロードを送り込む。

可用性

どれだけの停止が許容されるか。

攻撃者がログのファイルを溢れさせ、ログ以外のシステムの機能が使えるディスク領域を枯渇させる。たとえばログファイルに使われているのと同じディスクが、アプリケーションのデータの SQL の保管に使われていることがある。
攻撃者がログのファイルを溢れさせ、以後のログのためのディスク領域を枯渇させる。
攻撃者が一つのログの項目を使って他のログの項目を破壊する。
攻撃者がログのコードの性能の悪さを利用して、アプリケーションの性能を落とす。

責任の追跡

誰が害に対して責任を負うのか。

攻撃者が痕跡を隠すために書き込みを妨げる。
攻撃者が痕跡を隠すためにログを破損させる。
攻撃者が責任を負う者を隠すために、誤った身元を記録させる。