PCI-DSS Version 3.0 First Look at Impact
As PCI-QSA’s, we receive a great deal of questions from our clients on the specific changes that affect merchants with the introduction of PCI-DSS 3.0. While most organizations would be comforted to know that version 3.0 provides clarity and supplemental guidance for its predecessor, there are some new requirements that should garnish some added attention and due diligence.
Without performing a deep-dive into every change included with PCI-DSS version 3.0, we have attempted to shed some light on three areas that should prove beneficial to the majority of merchants faced with tackling these requirements.
Requirement 5.1.2 now requires merchants to: “identify and evaluate evolving malware threats” for “systems considered to be not commonly affected by malicious software.” Essentially, this now brings systems such as Unix Servers, MacOS, and Mainframe into the same processes and procedures your organization currently uses for malware detection and potential emergence of malware for those various platforms. Additionally, Requirement 5.3 now mandates specific authorization from management to disable or alter the operation of antivirus mechanisms, and any such disabling, be time-limited.
How does something seemingly simple in context affect your organization? With PCI-DSS Version 2.0, the standard specified only that there be antivirus software in place, that it be operational, that it be updated or current, and that it have the ability to generate logs. This is in essence the default install for most popular tools. However, you are now required to maintain an antimalware system capable of locking out the user from disabling it (think specific configuration) and ensure it makes use of that capability. This may require enterprise-level planning to accomplish and an implementation strategy to verify this capability throughout the entire Cardholder Data Environment (CDE).
One change that captured our attention initially is the updates applied to penetration testing requirements (11.3), including the requirement (11.3.4) to verify methods used to segment the cardholder data environment (CDE) from other areas. The full scope of this change has been discussed in other coverage, but one portion of the update that’s likely to be particularly challenging for merchants to meet is the requirement that penetration testing activities (internal and external) now follow an “industry-accepted penetration testing methodology,” such as the specifically referenced NIST SP 800-115, Technical Guide to Information Security Testing and Assessment.
One bit of refreshing news is that the requirement 11.3 update is considered only a best practice until June 30, 2015, giving merchants a few extra months to adapt to the change. The bad news is that this requirement is likely to be difficult for many merchants to comply with — at least initially. As we have found through our years of being in business, there are far too many “Penetration Testing Services” that don’t follow any particular methodology for their services and hence would not be suitable for meeting this requirement.
While Praetorian Secure is confident with our Penetration Testing services model (Penetration Testing Execution Standard and OWASP Testing Guide derived) – many of our competitors may need to reshape their service offering in order to suit the need of merchants preparing for PCI-DSS 3.0 compliance.
An important new PCI-DSS 3.0 requirement pertains to risk assessments and the timelines in which these risk assessments must be conducted. As with the previous PCI-DSS standard, annual risk assessments still must be performed, but in addition, will also be required when any significant changes are made to a cardholder data environment (CDE). Currently, many organizations only perform an annual risk assessment of their CDE; there will likely be debates between organizations and QSAs about what constitutes a “significant change.” This is a specific point and valid question that organizations should discuss with their QSAs prior to an on-site assessment being scheduled.
Though PCI-DSS version 3.0 is void of any guidelines for addressing cloud technologies, mobile payments, and virtualization — it is important to note the many improvements made to the existing standard. While the overall value of PCI-DSS compliance remains intact and we certainly don’t forecast any of our current/future clients to plan massive overhauls of their CDEs to maintain compliance, we think it should be business as usual for most merchants. Keep in mind that in 2014 organizations will be able to choose to assess themselves against either PCI 2.0 or PCI 3.0, with all organizations transitioning to 3.0 by January 2015.