Significant Changes in Your Cardholder Data Environment

PCI Requirement 11.2.3 requires that any time that you have made a significant change in your environment, whether it be internal or external, you run a vulnerability scan. A significant change could be something like new system component installations, changes in network topology, firewall rule modifications, or product upgrades, but what constitutes a significant change depends on the configuration of your environment. A good baseline for what constitutes a significant change may be if the change could allow access to cardholder data or impact the security of the cardholder data environment.

The PCI DSS explains, “Scanning an environment after any significant changes are made ensures that changes were completed appropriately such that the security of the environment was not compromised as a result of the change. All system components affected by the change will need to be scanned.”

To verify compliance with PCI Requirement 11.2.3, an assessor will examine your change control documentation and compare it to your vulnerability scan reports, and also validate that your scans were performed by qualified individuals.

PCI Requirement 11.2.3 requires that any time that you have made a significant change in your environment, whether it be internal or external, you run a scan. This particular scan can be run by an internal resource, but they do have to have some organizational independence and must know what they’re doing. For example, it can be an ASV that is performing that, but it does not have to be.

What the assessors are going to be doing, or what they should be doing, is going back and asking for a series of change controls. Subsequent to that, they should be asking for the subsequent scan that represents that changes that you have made and that they did not introduce any vulnerabilities into your environment. PCI Requirement 11.2.3 is not based on quarters, it may be based on an event.

What is an ASV?

To comply with PCI Requirement 11.2.2, you must use a PCI SSC Approved Scanning Vendor (ASV). An ASV is defined as, “An organization with a set of security services and tools (‘ASV scan solution’) to conduct external vulnerability scanning services to validate adherence with the external scanning requirements of PCI DSS Requirement 11.2.2. The scanning vendor’s ASV scan solution is tested and approved by PCI SSC before an ASV is added to PCI SSC’s List of Approved Scanning Vendors.”

The second component of PCI Requirement 11.2.2 is quarterly external vulnerability scans. External networks are at such a great risk of being compromised, which is why quarterly external vulnerability scans, and rescans as needed, are vital to scanning programs.

During an assessment, your assessor will follow these testing procedures:

• Examine your four most recent quarters of external vulnerability scans and verify that four quarterly external vulnerability scans occurred in the most recent 12-month period.
• Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met.
• Review the scan reports to verify that the scans were completed by an ASV.

PCI Requirement 11.2.2 is very similar in nature to PCI Requirement 11.2.1, but PCI Requirement 11.2.2 requires that you perform external vulnerability scans. Where PCI Requirement 11.2.1 allowed an internal qualified resource to perform that activity, PCI Requirement 11.2.2 is a little different there: you must use an ASV to perform that activity on your behalf. KirkpatrickPrice would be happy to help you with that service, and we provide that service for many of our clients. There are many other organizations that can do that as well.

Nevertheless, effectively anything with the CVSS sore of 4.0 or higher needs to be addressed within that quarterly timeframe. Understand that a lot of organizations might miss a scan or forget to do it for whatever reason, and then ask us to help them define a compensating control. We’ll talk about compensating controls later, but understand that this is one of those controls that is very difficult to define, especially defining a compensating control for a failure in your program. So, understand that it is different if you identify vulnerabilities versus forgetting to scan—those are really two different conversations. Your assessor in both of these cases, for PCI Requirement 11.2.1 and PCI Requirement 11.2.2, is going to be asking for evidence of your quarterly scan and then any remediation scans that you have done to demonstrate that any vulnerabilities identified have been fixed.

Vulnerabilities and Your Risk Ranking System

PCI Requirement 11.2.1 states, “Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all ‘high risk’ vulnerabilities are resolved in accordance with the entity’s vulnerability ranking.” Remember the risk ranking system you created for PCI Requirement 6.1? This comes back into play for PCI Requirement 11.2.1. This risk ranking system gives you the ability to identify, prioritize, and address high risk vulnerabilities more quickly and reduce the likelihood that they will be exploited. The vulnerabilities that you find from vulnerability scans will also be useful information for your risk ranking system.

Vulnerability scans can be automated or manual, but they should always be performed by qualified individuals who are reasonably independent of the system components being scanned.

PCI Requirement 11.2.1 says that you have to perform quarterly vulnerability scans within your environment. These scans that are performed need to be done by somebody that has organizational independence and knows what they are doing because they have been trained on how to perform these scans. When you run these scans, it is likely that you are going to identify vulnerabilities. What we expect is that you feed that information back into PCI Requirement 6.1, which is your vulnerability identification and risk-ranking program. Where you have identified a vulnerability, you have risk-ranked it, and it is high in your environment, so we expect you to take corrective actions to fix that and address those vulnerabilities before the next scan.

Running Network Vulnerability Scans

PCI Requirement 11.2 requires that organizations run internal and external network vulnerability scans at least quarterly and also after any significant change in the network. It’s crucial that vulnerability scans are performed by qualified personnel. Vulnerability scans are a combination of automated or manual tools and techniques ran against external and internal network devices and servers and are designed to expose potential vulnerabilities that could be exploited by attackers.

PCI Requirement 11.2 has three sub-requirements, including:

• 11.2.1: Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify that all high risk vulnerabilities are resolved in accordance with the organization’s vulnerability ranking, per PCI Requirement 6.1.
• 11.2.2: Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the PCI SSC. Perform rescans as needed, until passing scans are achieved.
• 11.2.3: Perform internal and external scans, and rescans as needed, after any significant change, such as after new system component installations, changes in network topology, firewall rule modifications, product upgrades, etc.

PCI Requirement 11.2 has several requirements around vulnerability identification, and from a high-level perspective, we are going to be performing internal and external scans. We are also going to be performing scans any time that we have made a change within the environment. We’ll talk about these in detail in the next set of requirements.

Incident Response Procedures

What would your organization do if an unauthorized wireless device was detected in your environment? PCI Requirement 11.1.2 requires that you implement incident response procedures so that in the event of some type of rogue wireless device, your employees know exactly how to respond. The size and complexity of your environment will determine what your incident response procedures should be. To verify compliance with PCI Requirement 11.1.2, an assessor will ensure that incident response procedures include instructions on unauthorized wireless device situations.

We believe that there are six basic steps in effective incident response procedures:

1. Preparation – How are you currently preparing for a security incident? How are you limiting the impact of an incident? Have you tested our policies and procedures?
2. Detection and Identification – How do you detect malicious activity? Do you have an Incident Response Team?
3. Containment – Has the appropriate personnel been notified? What evidence should be collected? How can you prevent further damage?
4. Remediation – Do you have backups in place? What changes can you make to prevent a repeated incident?
5. Recovery – Have you securely restored the system? Do you have continuous monitoring to ensure problem is resolved?
6. Lessons Learned – What happened? What gaps can we now identify? Have we regained our customers’ confidence?

To learn more about effective incident response procedures for PCI Requirement 11.1.2 compliances, visit these resources:

Incident Response Planning: 6 Steps to Prepare your Organization

What Is an Incident Response Plan? The Collection and Evaluation of Evidence

Conducting Incident Response Plan Table Top Exercises

If your organization should identify that there is a rogue wireless device or a device that was not authorized to have been installed within your environment, you need to maintain those activities within your incident response program. As part of the test, your assessor is going to be asking about your incident response program. They are going to be looking to make sure that wireless has been called out and what to do as a procedure in the event that wireless has been identified.