What logs to retain for PCI-DSS?

Question

I am using Splunk to centrally collect all of my logs for PCI-DSS. I'm running into my licensed volume limit and I need to know exactly what needs to be retained for regulatory compliance.

I am picking up a bunch of kerberos ticket events, mostly event 4769. Is there a specific reason these need to be retained? What about event 4672, special privileges assigned to a new logon?

I also have web servers which send in their IIS logs. These servers are sitting behind a Forefront TMG box which sends a more detailed version of the same data. Is there any reason that the IIS logs specifically need to be retained?

I would love some pointers on these events to what PCI requirement means they need to be maintained.

Answer 1

Generally, the most conservative answer comes in the form of something easily understood, and approachable by the general populous.

Ignoring the hyperbole of that kind of response, there are two things you must really take into account.

1. What logs should I retain
2. How long should I retain said logs

Log Retention

The answer to 2 is simple and well defined by the standard. Logs must be retained for one year and the last three months must be easily accessible. So let's translate that statement into my own recommendation

• Implement a centralized logging system, e.g. a single purpose system acting as a syslog receiver
• If storage is available on central system, then retain all logs from PCI scoped systems for 1 year
• Otherwise retain all logs from PCI scoped systems on central system for 3 months, rotate all logs older than 3 months to long term storage (such as tape/VTL/papyrus). Expunge logs on long term storage that are older than 1 year.

Events to Log

The answer to the first point is a little less well defined. The standard wants you to keep events and details for all PCI scoped systems. So assuming you have determined every system that is in scope, the only question is what what events you want to log. This is much harder to answer, because it would largely depend on your environment and what applications are running. The easy answer is to ask your QSA. To be conservative I would recommend adding *.* @logserver to your syslog config files, or perform the Windows equivalent. Make sure that any non-syslog applications on those machines also find a way to get their logs out. This would include web server, fat clients, etc. At minimum make sure any authentications, successful and unsuccessful, are logged. If possible full audit logs of data access on applications would be nice. For web apps, this would be standard in your httpd logs, but fat clients may not be as granular.

In the end, since your QSA decides whether or not you are compliant, they are your best bet for answering these questions.

Answer 2

My experience with this is it depends on your PCI QSA (i.e. it's partially subjective). Try flipping through Anton Chuvakin's slidedeck for some tips:

PCI DSS and Logging: What you need to know:
http://www.slideshare.net/anton_chuvakin/pci-dss-and-logging-what-you-need-to-know-by-dr-anton-chuvakin

Answer 3

There are 2 things you are discussing, from my point of view. One is which logs to keep for PCI compliance. The other is how many logs to keep in Splunk.

Splunk is a reporting tool which is outside of the PCI requirements. You can reduce the number of logs you track with Splunk to maintain your license and still keep the logs as required for PCI. You could set up a separate logging server to capture the logs you need for PCI, and only feed Splunk with the logs you want it to parse.

Here is the requirement doc. Section 10 is what you are looking for.

Edit: you say that you indeed use Splunk as your central logging server. In that case, PCI doesn't specify that the permissions assigned to a user need to be logged, except that users with root/admin access be tracked.

Answer 4

I kind of hate answering my own question especially this late after the fact however I did find a great resource that explains exactly what needs to be logged from the windows auditing to meet our needs.

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 

The one that surprised me the most off this list is the failure only on the privilege use. When I think about it the privilege use that we're concerned about - changing auditing settings, group memberships, changing operating system integrity protected files, etc - already have their own categories.