Committing to the 12-Step Program of PCI DSS: Regularly Test Security

The Payment Card Industry Data Security Standard (PCI DSS) version 3.0 is now the de facto standard for measuring security programs for all merchants and service providers that participate in commerce using credit or debit cards. There are twelve major requirements in the PCI DSS; this year, the Tenable Blog will feature a series of discussions about each of the twelve requirements. The focus of these blog posts will be to provide tips and pointers, to help clarify what’s new, and to enhance understanding so that your organization can achieve a sustainable security posture that easily satisfies the PCI DSS requirements.

The PCI Security Standards Council (SSC) went to great lengths to enhance the PCI DSS in version 3 by adding an informational section called Guidance. You should always reference this section to determine the context of a requirement and to understand how the PCI SSC interprets the spirit or intent of the requirement. Understanding the intent of the requirement is critical not only to assure that you are meeting the requirement, but even more so to determine viable alternatives or compensating controls to address the requirement.

Requirement 11: “Regularly test security systems and processes”

To kick things off, I will take a look at Requirement 11: “Regularly test security systems and processes” since this requirement is where Nessus (including our ASV offering) is most directly relevant.

11.1 Wireless detection

This section has not changed much other than to explicitly allow multiple methods or technologies to achieve the intent of discovering both authorized and unauthorized wireless networks and systems.

11.2 Vulnerability scanning

Companies have often complained about the difficulty of producing a “clean” or “passing” vulnerability scan as new vulnerabilities are discovered daily and subsequently scan engines frequently update their checks. As soon as one vulnerability gets remediated, and a new scan is performed to prove the remediation, very often several new vulnerabilities are discovered.

The PCI SSC acknowledged this difficulty and added a new note to 11.2 which gives companies the opportunity to submit multiple scan reports which demonstrate that remediation processes are working on an ongoing basis, to satisfy the quarterly requirement for producing a passing result.

For example, if you scan on a monthly basis, Scan One might show 3 high risk vulnerabilities that require remediation. Scan Two would show that those 3 vulnerabilities had been addressed, but now 7 new high and 2 critical vulnerabilities were published in the past month. Remediation occurs and Scan Three proves that these vulnerabilities have been addressed, but there is 1 new high risk vulnerability that prevents a clean result. PCI SSC now says that you can submit all three monthly scans to demonstrate that your company is effectively remediating vulnerabilities as they are discovered – even if you haven’t addressed the most recent vulnerability.

Submit multiple scan reports which demonstrate that remediation processes are working on an ongoing basis

This allowance will make most companies’ vulnerability management programs operate much more efficiently and should encourage more frequent scanning of their networks – which most security professionals already recommend. This allowance applies to both internal and external vulnerability scanning efforts, so you should expect Approved Scanning Vendors (ASVs) to be updating their service offerings to accommodate this new feature.

11.3 Penetration testing

If you’re a QSA you’ve probably been confronted by clients who ask “where does it say that?” and are firmly committed to only doing what the PCI DSS says they must do. This argument was often raised by my clients when it came to the penetration testing requirement which, prior to PCI DSS v3, was quite vague. Well, those days are over; the requirement now stipulates that you must have a documented methodology for penetration testing that must be based on industry-accepted approaches and provide complete coverage – both internally and externally – of your cardholder data environment (CDE).

You must have a documented methodology for penetration testing

The Guidance section provides some much needed context at this point, stating that a penetration test attempts to “simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment.” The Guidance also stipulates that a vulnerability scan does not constitute a qualifying penetration test, but must be part of a methodology that includes attempts at exploitation of known or discovered vulnerabilities. Ask any decent pen tester and he’ll tell you this requires manual exploitation attempts, or at least a human behind the scenes who is making decisions based on available data as to what exploitation methods to attempt.

Another required element of the penetration testing methodology is to incorporate lessons learned from threats and vulnerabilities experienced in the prior twelve months (since the last pen test). What a great idea! But taking it a step further would be to incorporate threats and vulnerabilities experienced by the industry in the previous twelve months (think targeted malware attacks against POS systems).

The most important aspect of penetration testing is to understand that it is intended to test the effectiveness of every aspect of your information security program

But the most important aspect of penetration testing is to understand that it is intended to test the effectiveness of every aspect of your information security program – from system hardening to patch management to user access control to logging and monitoring. Closely related to this is the treatment or remediation of findings: if the penetration test indicates some success based on a missing patch (for example), the vulnerability is not the missing patch – it is the deficiency of the process that led to the patch not being applied to the target system. Maybe the penetration test was successful due to a misconfiguration or the presence of a default setting: the vulnerability then is the failure of the build process that put the vulnerable system into production in the first place. This point of view also applies to intrusion detection and incident response processes; if the penetration testing was not observed or detected, there is a deficiency in the process of applying and monitoring any intrusion detection technologies you have deployed and/or the process of identifying and training qualified individuals with incident detection or reporting responsibilities.

Penetration testing exercises are “live fire” tests of your entire information or data security programs, and the results should be incorporated into your ongoing data security programs including annual risk assessment.

Don’t worry – you still have a six month grace period (until July 2015) to fully document and execute your penetration testing methodology, because the PCI SSC considers this to be a “new” requirement.

11.4 IDS/IPS

There’s not a lot new in this section. The basic premise of this requirement is to locate IDS/IPS sensors at strategic locations – both on the perimeter of your network (or your CDE) and at “critical points” within the network or CDE. The Guidance section says that you should monitor the output of these devices and investigate to determine the cause and/or extent of attempted intrusions. The more layers to your network – that is the more segmentation that has been implemented to isolate your CDE – the more “critical” locations you’ve created. Keep in mind that when you isolate your CDE from any other part of your internal network you are basically declaring that the other part is untrusted – which means you have a new “perimeter” to consider for intrusion detection.

11.5 Change detection

The first and most obvious change is the language of the requirement shifting to “change detection mechanism” from the former requirement for “file-integrity monitoring tools.” The spirit of this requirement is the ability to detect changes to critical files such as operating system components, applications, libraries, or even existing security controls including log files. The most common technology to satisfy this requirement is white-listing solutions, which also help to address the anti-virus/anti-malware requirements in section. So now you have choices for addressing this requirement, and you may even get the additional benefit of covering more than one requirement with one technology solution.

11.6 Documented policies and procedures

Finally, because the old 12.1/12.1.1 requirement to “establish, publish, maintain, and disseminate a security policy that … addresses all PCI DSS requirements” apparently wasn’t clear enough, the PCI SSC added a new requirement to each section that says everything you are doing in this section must be written down in policies and procedures. So 11.6 is a new requirement that states, “Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.”

Without a written policy and documented procedures, you really don’t have a functional information security program.

Nobody likes to keep up with the documentation, but it really is a vital component to a viable information security program. Without policies and procedures you cannot demonstrate that you know what [data] you need to protect, where it is located or transmitted (data-at-rest or data-in-flight), who requires access to the data (and who doesn’t), and you can’t effectively monitor access, attempted access, or administrative activities. In short, without a written policy and documented procedures, you really don’t have a functional information security program.

As always, if you have any questions about security, compliance, or any aspect of the PCI DSS, you may contact me at [email protected] or stop by the Tenable PCI Discussion Forum Straight Talk about PCI to see what is being discussed. For more information about PCI solutions from Tenable Network Security, see our PCI industry page or the whitepaper, Security First, PCI Compliance Second.