PCI Resources
A structured approach to the PCI standards

PCI DSS Requirement 11

Do you prefer finding that hole in your system yourself or would you prefer an attacker to do so? I certainly hope you prefer the former, and this is why testing is crucial.

Requirement 11 is all about proactively looking for vulnerabilities that often stem from a failure in IT processes. For example, did you forget to check a server that is also running XYZ software (which should be patched) and may have vulnerabilities? Your policies do mention that you can't connect an unauthorized device to the network right? Could somebody not have gotten that memo? Or not cared enough to read it?

Requirement 11 is divided in 5 themes.

The intent of the first theme is to ensure that unauthorized wireless network is not connected to your network. The way proposed in this requirement is by identifying all wireless networks and access points (AP) on a quarterly basis and comparing it to the list of authorized AP and networks. Should you identify an unauthorized network, you should treat this as an incident and follow your incident response plan. Note that if you implemented technical controls to prevent connection of unauthorized devices to the network, such as NAC, you could use this as a compensating control that is stronger than what PCI DSS requires.

For the second theme, we must perform internal and external network vulnerability scans on all in-scope systems, at least quarterly and after any significant change . This means that we need to have a process in place to manage these scans. The vulnerability scanning process must produce four (plus those for 'significant changes') 'clean' scans per year (clean means with no vulnerabilities identified, or all remediated) for all in-scope systems. This can be achieved by combining multiple scans during the quarterly period. Quarterly Internal scans can be performed by internal qualified individuals using industry recognized tools. Quarterly External scans must be performed by an Approved Scanning Vendor (ASV) . An ASV is a vendor approved by the PCI council (like for QSA companies) to perform this task. All vulnerabilities must be ranked, and 'high' or higher ranked vulnerabilities (see 6.1) must be remediated within a month. Rescans must be executed to confirm the vulnerabilities were remediated.

Vulnerability scans are mostly automated tools. As a third theme, PCI DSS also mandates annual (and after significant changes like for vulnerability assessments) external and internal penetration testing following a well-defined methodology based on industry-accepted standards. Penetration testing is a manual task performed by highly qualified individuals. A new requirement introduced in PCI DSS 3.0 is that if network segmentation is used, testing of the effectiveness of the segmentation must be performed to ensure isolation and adequate access-controls restrictions.

The previous tests are periodic, but the fourth theme PCI DSS calls for is continuous detective controls with the requirement for Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS) at the perimeter (Internet and CDE entry points) as well as other critical points in the network infrastructure. An IPS is an IDS that can also instruct some equipment to automatically block traffic that match a certain network pattern or signature (attacks). Obviously these IDS/IPS systems must be kept up-to-date and the events they generate must be logged and monitored.

A final fifth theme and detective control is the use of change-detection mechanism of modification to critical files (often of the Operating System, but also of key applications), which in previous PCI DSS versions was limited to the use of File Integrity Management (FIM) tools. Any alert must be handled through the incident response process which will confirm whether we are actually dealing with an incident.

Further Readings