この文書は2016年以降更新されていません
ロギングに関するチートシート
|
最終改訂日 (yy/mm/dd): 2015/07/18 はじめにこのチートシートは、特にセキュリティロギングに関して、アプリケーションのロギングメカニズムを構築するための集中ガイダンスを開発者に提供することに重点を置いています。多くのシステムでは、ネットワークデバイス、オペレーティングシステム、Web サーバー、メールサーバー、およびデータベースサーバーのロギングが有効になっていますが、アプリケーションイベントのロギングが欠けていたり、無効になっていたり、適切に設定されていなかったりすることがよくあります。アプリケーションイベントのロギングでは、インフラストラクチャロギングだけの場合に比べ、はるかに多くの洞察が得られます。Web アプリケーション (Web サイト、Web サービスなど) のロギングは、拡張ログファイル形式などを使用して Web サーバーのログを有効にするよりも一段と優れています。 アプリケーションロギングは、アプリケーション内だけでなく組織のアプリケーションポートフォリオ全体を通じて一貫性を保つことが必要であり、該当する場合は業界標準規格を採用することをお勧めします。これにより、ログに記録したイベントデータを多様なシステムで使用、関連付け、管理できるようになります。 目的アプリケーションロギングには、必ずセキュリティイベントを含めます。アプリケーションログは、以下の目的にきわめて貴重なデータです。
アプリケーションロギングを使用して、上記の他に次のようなイベントも記録できます。
通常、プロセス監視、監査、トランザクションのログ / 証跡などは、セキュリティイベントロギングとは異なる目的で収集されます。したがって、多くの場合、これらのログ / 証跡は別にしておく必要があります。収集するイベントの種類と詳細は異なる傾向にあります。たとえば、PCIDSS 監査ログは活動の時系列記録を格納し、独立して検証可能な証跡を提供します。この証跡により、帰属トランザクションの元の順序を特定するための再構築、確認、調査が可能になります。 ログへの記録は、多すぎず少なすぎないことが重要です。意図する目的に応じて、何を、いつ、どれだけ記録するか判断してください。ここからは、主にセキュリティイベントのロギングについて説明します。
設計、実装、テストイベントデータのソースアプリケーション自体から、ログエントリの生成に使用される広範な情報にアクセスできます。したがって、イベントデータの一番のソースはアプリケーションコードそのものです。アプリケーションは、ユーザーに関する情報 (ID、ロール、アクセス許可) やイベントのコンテキストについての情報 (ターゲット、アクション、結果) のほとんどを把握しています。このデータは、多くの場合、インフラストラクチャデバイスからも、密接に関係する他のアプリケーションからも入手できないものです。 アプリケーションの使用状況に関する他の情報源で、検討に値するものを次に示します。
異なる信頼ゾーンに属すシステムのイベント情報を含めるときは、イベント情報の信頼度を考慮する必要があります。データが欠落、改ざん、偽造、リプレイされた可能性や、悪意のあるデータであるおそれがあります。必ず、信頼できないデータとして扱ってください。ソースを検証する方法、および完全性と否認不可を実現する方法を検討してください。 どこにイベントデータを記録するかアプリケーションは通常、イベントログデータをファイルシステムかデータベース (SQL または NoSQL) に書き込みます。デスクトップやモバイルデバイスにインストールされたアプリケーションは、ローカル記憶域とローカルデータベースを使用できるほか、データをリモート記憶域にも送信できます。選択したフレームワークによって利用できる選択肢が制限される場合もあります。どの種類のアプリケーションもイベントデータを (ローカル記憶域の代わりに、またはローカル記憶域に加えて) リモートシステムへ送信できます。これは、集中型のログ収集 / 管理システム (SIEM、SEM) でも別のアプリケーションでもかまいません。実行環境で管理できるように、アプリケーションのイベントストリームを単純にバッファリングなしで標準出力へ送信できないかどうか検討してください。
エラースタックトレースや HTTP リクエストや応答のヘッダー情報や本文といった拡張イベント情報については、別のファイル / テーブルへの保存を検討してください。 どのイベントをログに記録するかプロジェクトの要件と設計の段階で、セキュリティの監視、アラート、およびレポートのレベルと内容を設定する必要があります。また、これは情報セキュリティリスクに見合ったものであることが必要です。その後、この設定に基づいて、何をログに記録するかを定義できます。すべてに対応できる万能のソリューションは存在しません。無闇にログをとると、無用なアラームが多発し、実際の問題が見過ごされてしまいます。できる限り、以下の項目は必ずログに記録してください。
オプションとして、以下のイベントがロギング可能であるかどうか、望ましい情報であるかどうかを検討してください。
イベントの属性各ログエントリは、その後の監視や分析に必要十分な情報を含んでいる必要があります。コンテンツデータ全体でもかまいませんが、抜粋や概要プロパティだけの方が一般的です。アプリケーション ログには、"いつ、どこで、誰が、何を" をイベントごとに記録する必要があります。これらのプロパティは、アーキテクチャやアプリケーションの種類、ホストシステム / デバイスによって異なりますが、通常、以下を含みます。
加えて、以下の項目の記録も検討してください。
以上の詳細については、巻末に挙げる「その他」の関連資料を参照してください。特に、Anton Chuvakin 氏と Gunnar Peterson 氏による総合的な資料を参照してください。 注 A: "対話式操作の識別子" とは、ユーザーによる単一の対話式操作 (デスクトップアプリケーションのフォーム送信、Web ページのリクエスト、モバイルアプリのボタンクリック、Web サービスの呼び出しなど) に関連するすべてのイベントをリンクするための方法です。これらすべてのイベントが同じ対話式操作に関連していることをアプリケーションは認識しています。この情報を失うことなく記録しておけば、後で関連付け手法によって力ずくで個々のイベントを再構成せずにすみます。たとえば、1 つの SOAP リクエストに複数の入力検証エラーがあり、各エラーが短い期間にわたっている場合があります。別の例として、出力検証エラーが入力の送信からかなり後に発生することがあります。これは、実行時間の長いリクエストがアプリケーションからデータベースサーバーに送信されるためです。 注 B: 各組織は、イベントの分類 (種類、信頼度、重大度)、記述の構文、フィールドの長さとデータ型 (日時に使用する形式を含む) について、文書化された一貫したアプローチを確保する必要があります。 除外するデータ法的に認められる場合を除いては、絶対にデータをログに記録しないでください。たとえば、通信の傍受、従業員の監視、許諾なしのデータ収集は、すべて違法にあたる可能性があります。 "既知の" ユーザー (他の内部システム、"信頼できる" サードパーティ、検索エンジンロボット、可用時間 / プロセスおよびその他のリモート監視システム、侵入テスト担当者、監査担当者など) からのイベントは、絶対に除外しないでください。記録されたデータにイベントごとの分類フラグを追加したい場合があります。 一般に、以下のものはログに直接記録しないで、削除、サニタイズ、ハッシュ化、または暗号化してください。
場合によっては、以下のデータが存在してもかまいませんが、これらのデータは後の調査に役立つ一方、イベントを記録する前に特別な扱いが必要になる可能性があります。
個人の ID が必要でない場合やリスクがきわめて高いと考えられる場合は、個人データの非特定化手法 (直接および間接の識別情報の削除、スクランブリング、匿名化など) の使用を検討してください。 一部のシステムでは、ログの収集後とログの表示前にサニタイズを実行できます。 カスタマイズ可能なロギングロギングのレベル (重大度または脅威のレベル、記録する詳細の量に基づくイベントの種類) を変更できることが望ましい場合があります。これを実装する場合は、以下のことを確保してください。
イベントの収集開発フレームワークで適切なロギングメカニズムがサポートされている場合は、それを使用するか、それをもとに構築します。それ以外の場合は、他のモジュール / コンポーネントから呼び出すことができるアプリケーション全体のログハンドラーを実装します。組織固有のイベント分類と記述構文の要件を参照しながら、インターフェイスを文書化します。可能であれば、このログハンドラーは、完全なテストも、複数のアプリケーションへの展開も、承認された推奨モジュールの一覧への追加もできる標準モジュールとして作成します。
注 C: 他者の制御下にあるデバイス (個人の携帯電話、異なる社内ネットワーク上にある、リモート顧客のワークステーションなど) 上でアプリケーションが実行されている場合は、同期できないこともあります。このよう場合は、時間差を測定するか、イベントのタイムスタンプに信頼度を記録します。 できる限り標準形式でデータを記録します。または、少なくとも、業界標準形式を使用してエクスポート / ブロードキャストできるようにします。 複数のイベントが中間点でまとめて中継または収集される場合があります。後者の場合、一部のデータが集約または集計されてから、集中リポジトリおよび分析システムに転送される可能性があります。 検証ロギングの機能とシステムを、コードレビュープロセス、アプリケーションテストプロセス、およびセキュリティ検証プロセスに必ず含めます。
展開と運用リリース
運用ロギングが停止したかどうかを検出するプロセスと、改ざんまたは不正なアクセスや削除を識別するプロセスを有効にします (下記の「保護」を参照)。 保護ロギングメカニズムと収集されたイベントデータを、転送中の改ざんや保存後の不正なアクセス、変更、削除などの悪用から保護する必要があります。ログに個人その他の機密情報が含まれていたり、データにアプリケーションのコードやロジックが含まれていたりする可能性があります。また、収集された情報そのものに、(競合他社、ゴシップ屋、ジャーナリスト、活動家にとって) ビジネス上の価値がある場合があります。たとえば、収益を推測できたり、従業員の業績情報が得られたりするなどです。このデータは、端末デバイス、中間点、集中リポジトリ、アーカーブ、およびバックアップに保持されている可能性があります。調査時またはデータを取り出す時にデータの一部を除外、マスク、サニタイズ、ハッシュ化、または暗号化することを検討してください。 保存時:
転送時:
詳細なガイダンスについては、『NIST SP 800-92 Guide to Computer Security Log Management』(コンピューターセキュリティログ管理ガイド) を参照してください。 イベントの監視ログに記録されたイベントデータはレビューが可能であることが必要です。また、適切な監視、通知、レポートのためのプロセスが確立されている必要があります。
ログの廃棄ログデータ、一時デバッグログ、およびバックアップ / コピー / 抽出を、所定のデータ保持期間が経過する前に破棄してはなりません。また、この期間を超えて保持してもいけません。法律、規制、および契約上の義務がこの保持期間に影響することがあります。
関連資料OWASP ESAPI ドキュメント OWASP Logging Project IETF syslog protocol Mitre Common Event Expression (CEE) NIST SP 800-92 Guide to Computer Security Log Management PCISSC PCI DSS v2.0 要件 10 と PA-DSS v2.0 要件 4 その他 How to Do Application Logging Right、Anton Chuvakin & Gunnar Peterson、IEEE Security & Privacy Journal その他 Build Visibility In、Richard Bejtlich、TaoSecurity ブログ その他 Common Event Format (CEF)、Arcsight その他 Application Security Logging、Colin Watson、Web Security Usability and Design Blog その他 Common Log File System (CLFS)、Microsoft その他 Building Secure Applications: Consistent Logging、Rohit Sethi & Nish Bhalla、Symantec Connect
Authors and Primary ContributorsMost of the information included is based on content in the articles referenced in the text and listed above, but the following people have provided their ideas, knowledge and practical experience: Colin Watson - colin.watson[at]owasp.org Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
