PCI Requirement 10.6 – Review Logs and Security Events for All System Components to Identify Anomalies or Suspicious Activity
by Randy Bartels / May 1st, 2018
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.
