PCI Compliance and Audit Trail History

Now that you’ve implemented logging, what do you to them? PCI Requirement 10.7 asks that you retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. A year is the recommended length of time because it may take a few months to notice a compromise. A year’s worth of audit trail history can be very helpful during analysis.

The PCI DSS guidance also states, “By having a minimum of three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.”

The assessment process for PCI Requirement 10.7 is pretty simple: examine policies and procedures and audit logs to verify that audit logs have been kept for at least one year.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

There are two places within the PCI DSS that call out log retention. Back in PCI Requirement 5, it says that your antivirus system needs to be retaining logs in accordance with PCI Requirement 10.7. PCI Requirement 10.7 has a couple of requirements, one of which is that you retain the logs at least for one year regardless of how they’re retained. However, at least three months of those logs need to be immediately available. From an assessment perspective, we’re going to ask you to roll back your log server or your logs or pull backs the logs that you might have on tape backup, and we’re going to look to see that you have at least one year’s worth of logs stored and at least three months made available for review.

[/av_toggle]

[/av_toggle_container]

Follow Up

Once an organization has completed log review, they must follow up exceptions and anomalies identified during the review process. The purpose of PCI Requirement 10.6.3 is a little obvious, right? If exceptions and anomalies are not investigated, then what’s the point of the log review process? The follow up process helps make organizations aware of unauthorized activities occurring in their network.

During an assessment, policies and procedures and risk assessment documentation will be examined to verify that follow up is happening on exemptions and anomalies identified during the review process.

PCI Requirement 10.6.3 talks about the need to follow up to any anomaly. Anytime that you have a log, you should set up alarms and mailings that identify an anomaly. Your assessors, from a technology perspective, should look at how you are alerted that that there’s an anomaly within your environment. They’ll also be looking for specific evidence that you’ve followed up to these specific incidents within your environment. It’s not enough to just log these events; it’s also required that you follow up and take appropriate actions to any of these incidents that might be impacting to your cardholder data environment.

How to Prioritize Log Review

PCI Requirement 10.6.1 requires daily review of logs of system components that store, process, or transmit cardholder data, logs of all critical system components, and logs of all servers and system components that perform security functions. But what about all other system components? PCI Requirement 10.6.2 addresses this and requires that organizations review logs of all other system components periodically based on the organization’s policies and risk management strategy. PCI Requirement 10.6.2 allows you to prioritize your log review program and apply log review in an appropriate way.

How do you determine what are “all other” system components? Based on your organization’s annual risk assessment, you’ll be able to determine which logs should reviewed on a periodic basis. For example, if you have a receptionist’s workstation that is in scope because of connectivity and a database that has millions of credit card numbers, you’re going to want to prioritize reviewing database logs. Going through an annual risk assessment will help determine which components should or should not be prioritized for log review.

PCI Requirement 10.6.2 is another one of these requirements that is new to the standard. What it says is that you can review all other logs on a periodic basis. We go back to PCI Requirement 6.1, and the requirements there talk about reviewing the logs for all systems that store, process, transmit, and provide security services. One of the things that it allows you to do is to prioritize your log review program. For example, if you have an administrator that has access to a database, you’re going to want to look at that database logs pretty much every day. But if you have a receptionist whose work station is in scope just because of connectivity, are you going to want to spend the same level of diligence around the receptionist’s desktop as you do the database that might contain a million credit card numbers? Probably not. So, PCI Requirement 10.6.2 recognizes that and it allows you to apply your log review resources in the most appropriate way. If you as an organization are going to be looking at these other logs on a periodic basis, you’ll need to do a risk analysis to define when and how often we’re going to be reviewing these and, once again, make sure that where there’s items identified, you’re following up with those as appropriate.

Daily Review

By reviewing logs daily, organizations can maximize their security efforts and minimize the exposure to potential breaches. PCI Requirement 10.6.1 requires that organizations review the following at least daily:

  • All security events
  • Logs of all system components that store, process, or transmit cardholder data
  • Logs of all critical system components
  • Logs of all servers and system components that perform security functions

From many breaches that have recently occurred, we see “log fatigue.” The information to identify a breach was there, but staff didn’t react appropriately. This may be because their job is to sit and review logs for hours and hours, and they eventually suffer from “log fatigue.” Employees are your first line of defense, so give them the tools they need to identify anomalies.

Other elements of PCI Requirement 10.6.1 to consider:

  • The definition of a “security event” will vary from organization to organization based on types of technology, location, scope, etc.
  • Organizations should establish a baseline of “normal” traffic to help better identify anomalies or suspicious behavior.

During an assessment, an assessor should examine policies and procedures and observe personnel to ensure that all security events, logs of all system components that store, process, or transmit cardholder data, logs of all critical system components, and logs of all servers and system components that perform security functions are under review at least daily.

To comply with PCI Requirement 10.6.1, we’re going to be reviewing all our logs at least daily, and this would include all the logs from anything that’s in scope for your PCI assessment. We will be looking at any security log or any log from any security-related device. When individuals are looking at these logs, be cognizant of what I call “log fatigue.” These people are going to be sitting there for eight or nine hours a day and watching the matrix waterfall, so help them, train them, and give them tools to help to identify out of this haystack, what the needle is that they need to be looking for. A lot of the breaches that have occurred as of late, the information was there; it was available for them to of identified that they had been breached, but staff, for whatever reason, didn’t react appropriately. This is one of the first lines of defense that you have, monitoring these logs for anomalies and acting and reacting appropriately.

Log Review

Many breaches occur over a period of time before being detected. That’s why it’s not enough for you to just create logs, you also have to create a process for reviewing them. How could you ever spot a pattern of suspicious activity if you don’t review your logs? PCI Requirement 10.6 requires that organizations review logs and security events for all system components to identify anomalies or suspicious activity. You could meet PCI Requirement 10.6 through manual methods, such as your staff being trained on how to review logs and identify suspicious activity. Other options are automated methods such as log harvesting, parsing, and alerting tools.

Meeting PCI Requirement 10.6 is a proactive way to protect the cardholder data environment and should tie into your overall risk management program.

It’s not enough within your environment just to create these logs. It’s necessary that you spend the time to train your staff, or that you have competent staff, outsource your staff, or outsource your log review program to competent individuals. One of the things that I’ve found interesting about the breaches that have occurred as of late is that these logs machines, central logging servers, and solutions were all logging and they were hacked, yet they were ignored or they were found to be false positives. I never got my hands around why they were ignored to the extent that they were. But effectively, PCI Requirement 10.6 says that we have to have a program in place for monitoring these logs. Your assessor is going to be working with you and looking at your log monitoring solution ad your log monitoring methodologies, making sure that you’re looking at the log, monitoring these logs, for any unauthorized events. Assessors will look at where there’s unauthorized events or where there’s an anomaly and that you’re following up with that. But, who’s to define what an anomaly is? What’s interesting about this is that this should really be a cue into your risk management program and to determine, from a technology perspective, what do we consider an anomaly and what do we do from an incident response program in the event that one of these things should show up in our logs.