PCI-DSSで保持するログは何ですか？

Question

Splunkを使用して、PCI-DSSのすべてのログを一元的に収集しています。ライセンス交付を受けたボリューム制限に達しました。規制遵守のために何を保持する必要があるかを正確に知る必要があります。

多数のkerberosチケットイベント、主にイベント4769を取得しています。これらを保持する必要がある特定の理由はありますか？イベント4672、新しいログオンに割り当てられた特別な特権についてはどうですか？

また、IISログを送信するWebサーバーもあります。これらのサーバーは、同じデータのより詳細なバージョンを送信するForefront TMGボックスの後ろにあります。IISログは特に保持する必要がありますか？

これらのイベントで、PCI要件が維持する必要があることを意味するものへのポインタが欲しいと思います。

Scott Pack · Accepted Answer

一般的に、最も保守的な答えは、簡単に理解でき、一般の人々が親しみやすい形をとっています。

Log Retention Recommendations

その種の応答の誇張を無視して、あなたが本当に考慮しなければならない2つのことがある。

私が保持するログすべき
上記のログを保持する期間

ログの保持

2への答えは単純で、標準によって明確に定義されています。ログmustは1年間保持され、過去3か月は簡単にアクセスできる必要があります。だから、その声明を私自身の勧告に翻訳しましょう

集中ログシステムを実装します。 syslogレシーバーとして機能する単一目的システム
中央システムでストレージが使用可能な場合、PCIスコープシステムのすべてのログを1年間保持する
それ以外の場合は、セントラルシステム上のPCIスコープシステムからのすべてのログを3か月間保持し、3か月より古いすべてのログを長期保存（テープ/ VTL/papyrusなど）にローテーションします。抹消では、1年以上経過した長期ストレージにログオンします。

ログに記録するイベント

最初のポイントへの答えは少し明確ではありません。この規格では、すべてのPCIスコープシステムのイベントと詳細を保持する必要があります。 isの範囲内にあるすべてのシステムを決定したと仮定すると、唯一の問題は、どのイベントをログに記録するかです。これは、環境や実行しているアプリケーションに大きく依存するため、答えるのがはるかに困難です。簡単な答えは、QSAに尋ねることです。控えめにするために、*.* @logserverをsyslog構成ファイルに追加するか、Windowsの同等の機能を実行します。それらのマシン上のすべての非syslogアプリケーションも、ログを取得する方法を見つけてください。これには、Webサーバー、ファットクライアントなどが含まれます。少なくとも、成功した認証および失敗した認証がログに記録されていることを確認してください。可能であれば、アプリケーションでのデータアクセスの完全な監査ログが適切です。 Webアプリの場合、これはhttpdログでは標準ですが、ファットクライアントはそれほど細かくない場合があります。

結局、QSAはあなたが準拠しているかどうかを決定するので、これらの質問に答えるための最善の策です。

Tate Hansen · Answer

これに関する私の経験は、PCI QSAに依存します（つまり、部分的に主観的です）。いくつかのヒントについては、Anton Chuvakinのスライドデッキをめくってみてください。

PCI DSS and Logging：知っておくべきこと：
http://www.slideshare.net/anton_chuvakin/pci-dss-and-logging-what-you-need-to-know-by-dr-anton-chuvakin

schroeder · Answer

私の観点から、あなたが話し合っていることは2つあります。 1つは、PCIコンプライアンスのために保持するログです。もう1つは、Splunkに保持するログの数です。

Splunkは、PCI要件外のレポートツールです。 Splunkで追跡するログの数を減らして、ライセンスを維持しながら、PCIに必要なログを保持できます。 PCIに必要なログをキャプチャする別のログサーバーを設定し、Splunkに解析したいログのみを提供することができます。

ここは要件ドキュメントです。セクション10はあなたが探しているものです。

編集：あなたは本当にあなたが中央のロギングサーバーとしてSplunkを使用していると言います。その場合、PCIは、root/adminアクセス権を持つユーザーが追跡されることを除いて、ユーザーに割り当てられた権限をログに記録する必要があることを指定しません。

Tim Brigham · Answer

私は自分の質問に答えるのが嫌いなのですが、特にこの事実の後半になっていますが、ニーズを満たすためにWindows監査から何をログに記録する必要があるかを正確に説明する素晴らしいリソースを見つけました。

Account Management Audit Application Group Management Success, Failure Audit Computer Account Management Success, Failure Audit Distribution Group Management Success, Failure Audit Security Group Management Success, Failure Audit User Account Management Success, Failure Detailed Tracking Audit DPAPI Activity No Auditing Audit Process Creation No Auditing Audit Process Termination No Auditing Audit RPC Events No Auditing DS Access Audit Directory Service Access Failure Logon/Logoff Audit Account Lockout Success, Failure Audit IPsec Extended Mode No Auditing Audit IPsec Main Mode No Auditing Audit IPsec Quick Mode No Auditing Audit Logoff Success, Failure Audit Logon Success, Failure Audit Special Logon Success, Failure Object Access Audit File System Success, Failure Audit Registry Success, Failure Policy Change Audit Audit Policy Change Success, Failure Audit Authentication Policy Change Success, Failure Audit Authorization Policy Change Success, Failure Audit Filtering Platform Policy Change Success, Failure Audit MPSSVC Rule-Level Policy Change Success, Failure Audit Other Policy Change Events Success, Failure Privilege Use Audit Sensitive Privilege Use Failure System Audit Security State Change Success, Failure Audit System Integrity Success, Failure

このリストで私を最も驚かせたのは、特権の使用のみの失敗です。私がそれについて考えるとき、私たちが心配している特権の使用-監査設定の変更、グループメンバーシップ、オペレーティングシステムの整合性保護ファイルの変更など-は、すでに独自のカテゴリを持っています。