Things not to overlook in the new PCI DSS 3.0
November 7th is tricky. Some years it rings of election news (at least in the US), while in others it has brought devastating earthquakes to places like Guatemala. Considerably less dramatic, this year it brought us the final version of PCI-DSS: the long-awaited 3.0. For a complete list of all changes in the new DSS, I recommend downloading and reviewing the PCI DSS 3.0 Summary of Changes which will take you through everything you need to know. I will limit my post to highlighting some of the most significant, noteworthy, and understated.
Having reviewed all the changes in detail, I am fairly convinced that majority of the pains in adopting the new 3.0 will come from items marked as a “Clarification”, rather than any new or “Evolving” requirements. I anticipate none more than the added clarification on Scoping.
PCI Scope Determination
The updated “Scope of PCI DSS Requirements” section now explicitly talks about the scope being defined not only by the segmented network, but also extending to “all system components included in or connected to the cardholder data environment”. In addition, the new DSS goes on to instruct that the scope is also defined by any system that may “impact the security of (for example, name resolution or web redirection servers) the CDE”. Considering inherent risks of all systems connected to one another, one might interpret this in a way which would include the entire Internet in scope. However, a more sensible approach should revolve around performing a risk-based analysis around those systems connected to the CDE to determine whether the scope is limited to the connected systems or should be extended to the logical network. This is a topic worthy of a whole separate post… or a white-paper… or a book. In the meantime, be sure to fully document your scope and challenge your assumptions to help you identify systems that may impact security of the CDE. Remember that these may include systems that you have previously left off the PCI compliance radar because they were on different logical and physical networks.
Relationship Between PCI DSS and PA-DSS
The clarification offered in the new DSS will mostly impact smaller organizations, and those that felt that they “outsourced” PCI compliance by using an application that had gone through the PA-DSS certification. All systems that process, store, and transmit CHD are in-scope, even if PA-DSS certified. The certification means the application can be implemented in a PCI DSS compliant configuration if installed in accordance with the Implementation Guide provided by the software vendor. This should be validated during the assessment and should not be taken for granted.
Best Practices for Implementing PCI DSS into Business-as-Usual Processes
This section is new in the PCI DSS 3.0 and helps reaffirm the need for a viable security program. While nothing new to security professionals, this section should be reviewed by all organizations, especially those that do not have a well-defined Information Security team. Recommendations offered clearly state that expectation of information security becoming a concern throughout the year, not only during the PCI assessment.
Sampling
The new “Sampling of Business Facilities/System Components” section covers something all QSA’s already worked with for years. While the new DSS calls it out as something for Assessors, I would recommend everyone read it and make a note of the things you can do to reduce the number of systems that need to get reviewed during the assessment. It’s simple: the more standards are followed during deployment and maintenance, the smaller the sample size. In addition to significantly reducing the amount of work that needs to be performed during the assessment, this has the added benefit of actually improving system management and security.
Understanding the Intent of Each Requirement
PCISSC has published several guidelines to help assessors, merchants, and service providers better understand the intent behind each requirement. These guidelines remained best-kept secrets and were seldom used, in spite of containing essential information for interpreting requirements where they didn’t apply verbatim. In the new DSS, these guidelines have been incorporated into the standard, which will help reduce the number of misunderstandings between assessing and assessed parties. Perhaps even higher value, it will help reduce differences of opinion between assessors, which generally drive merchant and service provider companies crazy with frustration.
Documented and Implemented…
Several changes in the new DSS have to do with re-enforcing the concept that controls must be documented and implemented in accordance with the documentation. While common-sense to most, this may be a good wakeup call to organizations whose policies are several years ahead of the controls that are actually implemented.
Specific Requirements
Requirement 1.1.3 – Current diagram that shows all cardholder data flows across systems and networks
In my experience as an assessor, I seldom find companies that do this well. Most diagrams are either too high-level (bordering on conceptual) or go to a level of detail that could be used to troubleshoot routing tables. This new requirement now requires diagrams that show where CHD is processed, transmitted, and stored. A side benefit – doing this well will also help critically evaluate the current scope of the CDE and identify opportunities for reducing the scope.
Requirement 2.4 – Maintain an inventory of system components that are in scope for PCI DSS
I don’t know why, but this has been a pain-point of most of the assessments I performed over the past years. System inventories either don’t identify whether the system is in scope for PCI or simply don’t exist. This always created many problems when attempting to select an appropriate sample size and I am happy about this being made into a requirement in the new DSS.
Requirement 3.5.2 and 3.5.3 – Key Storage
Over the years, I have seen many creative solutions for secure storage of data-encryption keys and key-encryption keys. Many met requirements but just as many were too big on creativity and somewhat light on security. Clarifications added in these two requirements help provide better guidance on how keys are to be stored and should be reviewed to ensure that key storage conforms to the new information.
Requirement 5 – Protect all systems against malware and regularly update anti-virus software or programs
No more picking on Windows; now all operating systems are in-scope for anti-virus software. The new and updated requirements still offer some flexibility in which systems get the anti-virus software installed on them, but the process needs to clearly show that anti-malware was a consideration for all platforms.
Requirement 6.6 – For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks
I am not too happy about one of the changes in this requirement . Specifically, you no longer have to run your Web Application Firewall (WAF) in ‘deny’ mode, as ‘detect-only’ is sufficient to meet this requirement. The requirement actually states that the solution will meet the requirement if it is “configured to either block web-based attacks, or generate an alert”. I have some hope that it’s a type-o, because within the same requirement the Guidance section offers: “Web-application firewalls filter and block non-essential traffic at the application layer”. Otherwise, this would be a change that would allow a weaker security configuration than what was required in 2.0.
Requirement 8.5.1 – Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer
This is one of my favorite additions to the PCI DSS, even though I know how much pain this will cause the majority of the service providers. The time-honored practice of using the same password for all customers has been a silent danger for a long time, and I am happy it’s now officially prohibited by the DSS. The small silver-lining here for service providers is that it’s not mandatory until June 30, 2015, so you have a little over a year and a half to propagate this change throughout your organization.
Requirement 9.9 – Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution
Applicable to anyone who uses physical devices for capturing CHD, this new requirement will introduce a number of items that should be considered. First, it requires that the company maintain a full inventory of all devices deployed in the field. Considering the number of retail locations or CHD capture devices deployed in many hospital systems, this alone could provide a challenge for some organizations. The inventory must contain the relevant device information, as well as information about the location of the device. The other two sub-requirements deal with the need to provide periodic training on spotting device tampering, as well as actually performing periodic audits of all devices. While seemingly simple, I anticipate this requirement to create a lot of headaches. At least as with all other new requirements, this one is not required until June 30th, 2015.
Requirement 10.2 5 – Use of and changes to identification and authentication mechanisms…
This requirement enhances mandatory logging settings to include each use of authentication mechanisms and all possible changes to user account permissions and settings. While this is supported by most enterprise-level operating systems, it’s rarely the default configuration and will require changes across a large number of systems. However, custom-written applications may require some additional and enhanced logging triggers to be developed. The same will apply for custom software that does not support logging ‘pausing’ events, as required by 10.2.6.
Requirement 11.2 – Run internal and external network vulnerability scans at least quarterly and after any significant change in the network…
This requirement is certainly not new. However, the council has added a lot of guidance, specifying that a report showing “high” or “critical” vulnerabilities is not acceptable as a quarterly report. This means that in order to meet the quarterly scanning obligations, organizations will need to scan, remediate, rescan, and then save reports. The requirement now specifically talks about combining multiple reports that show a single quarter’s attestation of compliance with this requirement.
Requirement 11.3 – Implement a methodology for penetration testing…
In the past, the requirement on penetration testing loosely stated that the methodology should be documented to reflect application and network level testing. Now, the DSS has added a relatively large description of all the requirements behind an acceptable penetration testing methodology. For companies that do their own penetration testing, they will not be able to simply rely on a pen-testing tool to meet this requirement; they will need to ensure the penetration testing process is a considerable undertaking, not limited to running automated tools on the network. For companies that perform penetration testing for PCI, this means updating or improving their reporting to demonstrate their methodology meets all the requirements stated in 11.3.
Related is the new requirement 11.3.4, which requires that penetration testing include verifying the effectiveness of any network segmentation that is used to safeguard CDEs. Depending on the number of non-CDE networks, this may mean significant changes in scope for penetration testing efforts, particularly for large, global enterprises.
Requirement 12.2 – Implement a risk-assessment process
Love Risk Assessments? So does the PCI council! The standard de-facto risk-assessment requirement has been updated to require repeating them after significant changes, in addition to having to perform them on an annual basis. At least the definition of a significant change has been expanded from adding a new web server to things like relocation or mergers and acquisitions.
Requirement 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
Few things caused merchants and service providers to hit the brakes in the middle of a PCI assessment like the discovery that your PCI-compliant service provider does less for you than you originally anticipated. Statements like “We fully outsource all server-related things to so and so” turned into vendors doing nothing more than providing space, power, and data. In order to help level the playing field, this new requirement requires maintaining a detailed list of all PCI requirements the vendors are covering as part of their service / attestation. This will certainly help everyone get on the same page about how much of the PCI attestation may depend on the PCI AOC provider by a vendor or a service provider.
As reinforced through 12.9, contracts should be updated to include information related to the scope of the PCI attestation included as part of the contract but, like all other new requirements, this is not mandatory until June 30, 2015. During the last North America community meeting, someone asked the council whether this would necessitate all contracts to be re-negotiated immediately in order to meet this requirement. The council replied that that won’t be necessary, as long as contracts get updated as they expire or as part of new contract negotiations.
Summary
Once again, this is not a complete recap of all that is new and updated, just those items I feel people need to pay close attention to. The new requirements are probably not significant for a large number of organizations. However, I can definitely see how some companies with smaller and less rigorous information security teams may struggle to meet some of the new and updated requirements.