PCI Requirement 10 states, “Track and monitor all access to network resources and cardholder data.” Complying with PCI Requirement 10 is critical to ensuring that you know who had what access to cardholder data. For this requirement, we’ve discussed aspects of tracking and monitoring access to network resources and cardholder data, such as how to implement audit trails, what should be documented in logs, which failures you should be notified of, how long to retain audit trail history for, and more. But, as we’ve learned, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 10.9.
PCI Requirement 10.9 states, “Ensure that security policies and operational procedures monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and operational procedures need to be known and in use by all relevant parties. It is not sufficient that you generate documentation just for the sake of the audit. It is a requirement of this framework that the affected parties use the policies and procedures. Your assessor should be reading these documents, be familiarizing themselves with the policies and procedures, and be interviewing staff to make sure that anybody who is subject to the policies and operational procedures understands what they are. If PCI Requirement 10.9 is not met, your cardholder data could be left vulnerable.
PCI Requirement 10.9 is the capstone to PCI Requirement 10. Once again, policies, procedures, and standards – the assessor is going to be asking for all of that documentation. They will be reviewing it, making sure that it is in place, that you’re actually using it, that you’re managing the documentation, and that it’s known to all effected parties.
So, you’ve been alerted of failures of critical security controls…what do you do next? PCI Requirement 10.8.1 requires that you respond to failures of any critical security controls in a timely manner. If not, attacks can take the opportunity to infect your systems.
Your organization’s policies and procedures should outline the expected response to failures, which includes:
How to restore security functions
How to identify and document the duration of the security failure
How to identify and document cause(s) of failure, including root cause, and document remediation required to address root cause
How to identify and address any security issues that arose during the failure
How to perform a risk assessment to determine whether further actions are required as a result of the security failure
How to implement controls to prevent cause of failure from reoccurring
How to resume the monitoring of security controls
PCI Requirement 10.8.1 is an additional requirement for service providers only.
As part of that review, if there is a failure in any of your systems that detects that you might be hacked, it is required that you have appropriate measures in place to immediately react to that in order to bring those things back online to protect those environments. You have to have a program in place for detecting the failure of those critical systems that detect that you’ve been compromised.
Without formal processes in place to detect and alert when critical security controls have failed, failures could go undetected for extended periods of time and provide malicious individuals with opportunities to compromise your systems and obtain sensitive data from the cardholder data environment. This is why PCI Requirement 10.8 requires that service providers implement a process for the timely detection and reporting of failures of critical security control systems. This could be the failure of things like firewalls, IDS/IPS, FIM, anti-virus, physical access controls, logical access controls, audit logging mechanisms, and/or segmentation controls.
PCI Requirement 10.8 is an additional requirement for service providers only.
PCI Requirement 10.8 is another one of those requirements that is specific to service providers. If you’re a service provider and you’re providing services to other third-party organizations, you need to have a process in place that your log program and your security program is functioning as expected. PCI Requirement 10.8 calls out the requirements for monitoring programs, making sure that all of those assets are functioning, that you’re getting logs from all of those things, and that you’re reviewing them as appropriate.
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.
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.
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.