Implement Policies and Procedures

PCI Requirement 11 states, “Regularly test security systems and processes.” Complying with PCI Requirement 11 is critical to ensuring that you’ve adequately secured your systems. For this requirement, we’ve discussed how to test your systems and processes, which includes vulnerability scanning, penetration testing, change-detection, 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 11.6.

PCI Requirement 11.6 states, “Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected 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 11.6 is not met, your cardholder data could be left vulnerable.

PCI Requirement 11.6 is the capstone to PCI DSS Requirement 11. PCI Requirement 11.6 requires that you maintain appropriate documentation that it is in use and known to all affected parties. The assessor is going to be asking for this documentation, they’re going to be reviewing it, they’re going to be looking at your environment, and how you’ve managed and configured it as compared to what you have implemented in your documentation. The assessor will be verifying that what you are doing is what you said you are doing.

Responding to Alerts

PCI Requirement 11.5.1 works in tandem with PCI Requirement 11.5. When your change-detection mechanism gives you an alert, you must have a process in place to respond to that. PCI Requirement 11.5.1 states, “Implement a process to respond to any alerts generated by the change-detection solution.”

During the assessment process, your staff will be interviewed to ensure that all alerts are investigated and resolved.

Keeping in mind that your file monitoring system needs to be run weekly, where your file integrity monitoring system has generated an alert or if there is an event that is created as part of your file integrity monitoring system, it needs to generate some type of log. Your staff would then need to appropriately react to that particular event.

Change-Detection Mechanisms

If change-detection mechanisms are not implemented properly, a malicious individual could take advantage and could add, remove, or alter configuration file contents, operating system programs, or application executables. This is why PCI Requirement 11.5 says, “Deploy a change-detection mechanism to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.”

During an assessment, an assessor will examine your change-detection mechanism and review the results from monitoring activities. The PCI DSS gives us a good idea of what types of files should be monitored, like system executables, application executables, configuration and parameter files, log and audit files, and any other critical files.

There are two places within the PCI DSS that talk about change control. There is PCI Requirement 10.5.5 that talks about file integrity monitoring of logging, and PCI Requirement 11.5 is the second place that we talk about that. PCI Requirement 11.5 requires that you have a file integrity monitoring system that monitors all your critical files and all of the applications files within your environment.

From an assessment perspective, your assessor is going to be pulling all the configurations from your file integrity monitoring systems and looking at what files are going to be monitored. One of the areas that we find most organizations struggle with PCI Requirement 11.5 is that they install Tripwire or OSSEC or another type of file integrity monitoring system and, by default, they will watch the operating system files. They’re pretty good about the system files; however, these applications do not have the cognitive ability to know what applications have been installed. One of the biggest areas that we see clients often struggle with PCI Requirement 11.5 is that they have not gone in and customized that file integrity monitoring solution to monitor those specific files for that specific server.

Detecting and Preventing Intrusion

Has your organization implemented intrusion-detection and/or intrusion-prevention techniques? PCI Requirement 11.4 requires that organizations implement the following:

• Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network.
• Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment.
• Alert personnel to suspected compromises.
• Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

The PCI Requirement 11.4 guidance explains that intrusion-detection and/or intrusion-prevention techniques compare the traffic coming into your network with known behaviors of compromise types (hacker tools, Trojans, and other malware) and send alerts and/or stop the attempt as it happens. Without PCI Requirement 11.4 compliance nor a proactive approach to unauthorized activity detection, attacks on or misuse of computer resources could go unnoticed in real time.

Your organization needs to implement an IDS/IPS—an intrusion detection or prevention system. This particular asset or device needs to be installed at the perimeter of your network and at the critical points or junctions within your cardholder data environment. This IDS/IPS needs to be managed, so from an assessment perspective, we need to make sure that the definitions that you are using are appropriately configured, that they are kept up-to-date, and that they are managed so identify whether one of two things are happening: that your organization is blocking those attacks, or if they are not blocking those attacks, that staff is immediately being notified and is reacting appropriately to those events.

Segmentation, Scoping, and Penetration Testing

Are you a service provider? Do you use segmentation for the purpose of PCI scope reduction? PCI Requirement 11.3.4.1 outlines new PCI penetration testing requirements and caused confusion among many service providers. PCI Requirement 11.3.4.1 states, “If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.”

PCI Requirement 11.3.4.1 requires that a penetration test, which validates the scope and effectiveness of segmentation controls, be performed every six months or after any changes to segmentation controls. The purpose of this additional penetration test is to ensure that segmentation controls continue to operate effectively throughout the year. The continual, complete isolation between CDE and non-CDE systems is key to your PCI compliance.

Our approach to compliance with PCI Requirement 11.3.4.1 involves more than simply validating segmentation controls through port scanning activities. The PCI DSS specifies that penetration testing must be performed, meaning that it is not sufficient to only perform something like nmap scans from non-CDE to CDE networks. Additional effort is required in order to meet this requirement for penetration testing, and our team of penetration testers is ready to help.

There was a new requirement introduced in PCI DSS v3.2, which is PCI Requirement 11.3.4.1. It states that if you are a service provider, you need to validate that your segmentation is in place at least bi-annually, and then after any significant changes to the environment or controls that might affect your segmentation.