一般来说，最保守的答案是以易于理解的形式出现，并且普通民众可以接受。

忽略这种反应的夸张，有两件事你必须真正考虑到。

1. 我应该保留哪些日志
2. 我应该将上述日志保留多长时间

日志保留

2 的答案很简单，并且由标准明确定义。日志必须保留一年，最近三个月必须易于访问。所以让我们把这个陈述翻译成我自己的建议

• 实现一个集中的日志系统，例如作为系统日志接收器的单一用途系统
• 如果存储在中央系统上可用，则将来自 PCI 范围系统的所有日志保留 1 年
• 否则，将来自 PCI 范围系统的所有日志保留在中央系统上 3 个月，将所有超过 3 个月的日志轮换到长期存储（例如磁带/VTL/纸莎草纸）。删除超过 1 年的长期存储日志。

要记录的事件

第一点的答案不太明确。该标准希望您保留所有 PCI 范围系统的事件和详细信息。因此，假设您已经确定了范围内的每个系统，唯一的问题是您要记录哪些事件。这很难回答，因为它在很大程度上取决于您的环境和正在运行的应用程序。简单的答案是询问您的 QSA。为了保守起见，我建议添加*.* @logserver到您的 syslog 配置文件中，或者执行 Windows 等效项。确保这些机器上的任何非系统日志应用程序也找到了一种方法来获取它们的日志。这将包括 Web 服务器、胖客户端等。至少要确保任何身份验证、成功且不成功，被记录下来。如果可能的话，对应用程序数据访问的完整审计日志会很好。对于 Web 应用程序，这在您的 httpd 日志中是标准的，但胖客户端可能没有那么精细。

最后，由于您的 QSA 决定您是否合规，因此它们是您回答这些问题的最佳选择。

我的经验是这取决于您的 PCI QSA（即部分主观）。尝试翻阅 Anton Chuvakin 的幻灯片以获取一些提示：

PCI DSS 和日志记录：您需要了解的内容：http :
//www.slideshare.net/anton_chuvakin/pci-dss-and-logging-what-you-need-to-know-by-dr-anton-chuvakin

从我的角度来看，您正在讨论两件事。一个是为 PCI 合规性保留哪些日志。另一个是在 Splunk 中保留多少日志。

Splunk 是一种超出 PCI 要求的报告工具。您可以减少使用 Splunk 跟踪的日志数量，以维护您的许可证并仍然按照 PCI 的要求保留日志。您可以设置一个单独的日志服务器来捕获 PCI 所需的日志，并且只向 Splunk 提供您希望它解析的日志。

这是需求文档。第 10 节是您要查找的内容。

编辑：您说您确实使用 Splunk 作为您的中央日志服务器。在这种情况下，PCI 不指定需要记录分配给用户的权限，除非跟踪具有 root/admin 访问权限的用户。

我有点讨厌回答我自己的问题，尤其是在事后很晚，但是我确实找到了一个很好的资源，可以准确地解释需要从 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 

此列表中最让我惊讶的是仅在特权使用方面的失败。当我想到它时，我们关心的特权使用 - 更改审核设置、组成员身份、更改操作系统完整性保护文件等 - 已经有自己的类别。