Implementing PCI Requirement 10

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.

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

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.

[/av_toggle]

[/av_toggle_container]

Responding Failures

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.

[/av_toggle]

[/av_toggle_container]

Monitoring Failures

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.

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

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.

[/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.