PCI Compliance Every Day – Requirement 10

Track and Monitor all Access to Network Resources and Cardholder Data

When people think of PCI business as usual (BAU) they do not typically see the requirements in section 10 as having much of anything to do with BAU. However, there are a lot of things that need to be monitored. The requirement almost everyone remembers in this section with an explicit BAU is 10.6.1 which states:

Review the following at least daily:

• All security events.
• Logs of all system components that store, process, or transmit CHD [cardholder data] and/or SAD [sensitive authentication data], or that could impact the security of CHD and/or SAD.
• Logs of all critical system components.
• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

However, there are a few more requirements in 10 that also need to be addressed daily. Those requirements are 10.2.5.c (administrator account management), 10.5.3 (log data sent to remote log collection device) and 10.6.3.b (exceptions/anomalies researched).

For almost all organizations, the requirements in 10 are met with the use of a security information and event management (SIEM) solution. The reason is that once you get beyond two or three devices/systems, the ability to truly review log information for all of the conditions necessary cannot be done accurately on a daily basis (with the expectation of identifying a compromise or intrusion). With the introduction of a SIEM solution, organizations should be monitoring log data on an almost real-time basis, which means the organization is going “above and beyond” the PCI DSS requirement of “daily.” This “above and beyond” control can be very useful when developing controls for a compensating control worksheet (CCW) as those must go “above and beyond.”

The most significant issue we encounter with SIEM solutions is what devices are sending their log data to the SIEM. Since SIEMs are typically licensed on the number of IP addresses sending log data to them, companies only purchase enough licenses for the devices that need to be monitored for PCI compliance. As a result, if there is any change in PCI scope (i.e., more devices are determined to be in-scope for PCI), devices end up not sending their log data to the SIEM and therefore are not meeting the daily log review requirement.

This situation leads to one of the most frustrating parts of the whole discussion surrounding SIEM solutions. For a SIEM to be truly effective, every device needs to send its log data to the SIEM, not just those that are in-scope for PCI compliance. Time and again, we run into organizations that have been penny-wise but pound-foolish with their SIEM. To save money, they have ignored the organization’s overall security and operational requirements when everything should be sending its log data to the SIEM. As a result, attackers could be everywhere but the PCI in-scope environment, however, the organization would never know that fact because those PCI out of scope devices’ log data are not monitored.  

A SIEM can do so much more than just security monitoring. It is also a critical tool for identifying operational issues such as failed backups and failed applications/services. Read any of the breach analysis reports and you will find that one of the biggest tells about a breach or compromise is the fact that an organization is encountering mysterious operational issues. If an organization did not fully implement their SIEM, they likely are missing that critical piece of analysis and therefore have no idea that they should be further investigating their operational issues.

Because everyone had their blinders on for PCI and therefore only wanted to tie the expenditure to PCI, they neglect the bigger picture of what a SIEM can do and only purchase enough licenses to cover their PCI compliance requirements. Great for PCI compliance, lousy for the organization as a whole.

But that is not the only place where SIEM solutions typically go sideways.

SIEM implementations also go wrong with the configuration of their monitoring and alerting functionality. Depending on the SIEM vendor, solutions can come with pre-built or pre-configured monitoring rules that generate alerts for common conditions such as failed logon attempts, failed services/tasks/applications, failed systems/devices, starting/stopping of logging systems and similar conditions that are all required to be monitored by the PCI DSS. Over the years it has become clear that the cost of a SIEM solution is directly proportional to how many “canned” monitoring rules and alerts ship with the solution. The more canned rules, the easier and quicker the solution is to get up and running, but it comes at a higher price.

Because of this, we encounter another big problem with SIEM implementations during assessments. We review the monitoring rules and find that only the basic rules that shipped with the SIEM have been applied. Worse yet, if the organization has devices/OSes that are not widely implemented, older devices/OSes, etc., we will find that even basic conditions are not monitored correctly because not all the log messages that need to be looked at are being examined by the SIEM. Since there are no canned rules/alerts for these situations, there is no monitoring of those devices/systems. In the end, we find that even some basic conditions are not being fully and properly monitored.

Adding insult to injury in this whole situation is the fact that a lot of organizations implement a SIEM solution with only basic monitoring being performed, nothing more. Anything more than looking for failed logons or failed services is nowhere to be found. This becomes very important for situations when a CCW is needed as 90% of the time, one of the key compensating controls to be used is the near real-time log monitoring and alerting by the SIEM. But thanks to a partial implementation, the ability to rely on the SIEM for a compensating control is not possible.

Finally, after all of the years that SIEM solutions have been around, it is still amazing the number of people that tell you that they ignore alerts. You would think the days of “oh, that is a false positive” would be long gone, but they are not. We still encounter that refrain more than we would like when observing and interviewing SIEM personnel. After 10 years of PCI compliance, you would have thought that organizations would have tuned their SIEM to minimize false positive results, but that is not the case.  

My personal favorite though is from some years back. I was conducting the observations of an organization’s SIEM and the person giving me the demonstration was so proud of the fact that their false positive rate had dropped by a phenomenal 90% and proudly displayed the chart proving that fact. I asked the person to explain how they had been able to get such a reduction, but all I got were vague answers and responses. I found out why a few weeks later as I reviewed the samples of log data I had been given for their assessment and noted that none of the organization’s devices at their new data center were having their log data fed into the SIEM. Oops!

At the end of the day, the only way requirement 10 can be met in all but the very, very smallest of organizations is through the use of a SIEM. It is important that the SIEM gets completely implemented and that its rules and alerts are regularly reviewed and updated (more often than just when your QSA comes through for the annual PCI assessment). Your SIEM’s monitoring and alerting is a very critical control in identifying situations that could be a compromise. But without diligence in maintaining the accuracy in that monitoring, the SIEM will quickly become an ignored and untrusted source of information.