It's that time again. Versions 2.0 of the Payment Card Industry Data Security Standard (PCI DSS) and Payment Application...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Data Security Standard (PA DSS) are making their debut. The Council's "Summary of Changes" document spilled the beans on what to expect from the changes prior to today's official "launch" of PCI DSS 2.0. (Editor's note: This tip is based on information in the Summary of Changes.)
From a PCI assessment standpoint, there are two things to call out about the changes at a macro level before going into the details of the changes themselves: First, the changes are relatively minor. This wasn't entirely expected; a number of industry experts had speculated that the standard would follow a "major release/minor release" paradigm (similar to what you'd see in a software product). Following a "point" release of PCI DSS 1.2 in October 2008, many thought the PCI DSS 2.0 "major revision" this year could mean sweeping change, but this wasn't the way it turned out. The council cites maturity in the standard as the reason for the relatively small number of changes, which means companies can also expect a lesser volume of change in future revisions. For those that were hit hard by the (fairly significant) changes in the 1.x iterations during the past five years, this should be welcome news.
Secondly, the enforcement timing of changes is beneficial: In other words, there is time to respond before organizations are called to task on how they've implemented the changes. Because the changes won't go into effect until January 2011, and because merchants have a year to comply, there is plenty of time to get environments in shape before enterprises actually have to go through an assessment based on the updates.
But these positive developments shouldn't encourage security and compliance managers to slack. Although most of the changes represent a reduction of the scope of controls, there could be a few that might have broader impact depending on your current processes, scope of compliance efforts, and how your company has interpreted the controls in the past. So starting now, look at the changes and update your compliance plan accordingly. It will be time well spent.
PCI 2.0: If anything, mostly a slight reduction of assessment impact
As outlined, most of the changes reflect a decrease in the effort associated with the PCI assessment process, changes that provide additional flexibility for the assessor or for you to generally decrease the scope of assessment effort because they allow interpretive latitude -- both for you and your QSA. That interpretive latitude means less time spent trying to force-fit what you've deployed into narrow parameters; in combination with clarifications about control scope means less time-consuming back-and-forth discussion between merchants/service providers and QSAs about intent and meaning. The following chart outlines areas where the changes have either no impact on PCI assessment effort or that decrease the effort associated with the assessment process:
|Requirement||Proposed Change||Assessment Impact|
|PCI DSS Intro||Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN. Align language with PTS Secure Reading and Exchange of Data (SRED) module.||In most cases, minimal impact on assessment effort. Potential reduction in assessment scope of effort if you or your QSA interpreted 3.3. or 3.4 as applying to other cardholder data in past assessments.|
|Scope of Assessment||Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.||Potential area of impact (described below)|
|PCI DSS Intro and various requirements||Expanded definition of system components to include virtual components. Updated requirement 2.2.1 to clarify intent of "one primary function per server" and use of virtualization.||Potential area of impact (described below)|
|PCI DSS Requirement 1||Provide clarification on secure boundaries between Internet and card holder data environment.||It isn't clear from the description what this clarification will be. However, since the controls around separation of the CDE from the Internet are relatively unambiguous currently, this is likely to be a minimal impact issue.|
|PCI DSS Requirement 3.2||Recognize that issuers have a legitimate business need to store Sensitive Authentication Data.||The scope of an issuer's business requirements has little bearing on an assessment at a merchant or service provider. Minimal impact to assessment effort.|
|PCI DSS Requirement 3.6||Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge.||We don't have enough information to know from the change description how this will change. The intent of the change is to increase flexibility, which suggests reduction in assessment effort.|
|PCI DSS Requirement 6.2||Update requirement to allow vulnerabilities to be ranked and prioritized according to risk.||This moves the requirement more in-line with what firms do; this change allows latitude to reflect that practice during an assessment.|
|PCI DSS Requirement 6.5||Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications. Include examples of additional secure coding standards, such as CWE and CERT.||Consolidation in this area means reduced assessment effort as merchants and QSA's are no longer writing up results twice for the same controls.|
|PCI DSS Requirement 12.3.10||Update requirement to allow business justification for copy, move and storage of CHD during remote access.||This change recognizes that business may need to manipulate cardholder data during a remote access scenario. Therefore, businesses that required doing this will no longer have to write up compensating controls to do so.|
As you can see, with the exception of the two areas called out, the items in this list connote relatively little impact on an assessment. It's these other two areas that merchants and service providers may want to keep an eye out for.
Two areas to watch
One of the most significant changes is the clarification of PCI assessment scope (item No. 2 in the change list above). It's still unclear specifically how the scope change will be reflected in the final document, but what is there should be enough for anybody who's been through an assessment to take notice. Specifically, according to this, scope of cardholder data flow diagrams should include all locations and all areas.
That's an "uh-oh" for many firms; as it turns out, many organizations just aren't where they need to be on this point. Producing up-to-date diagrams of cardholder data everywhere in the enterprise may seem negligible at first glance, but in a large retail environment with multiple business units, diagrams might cover only one business unit of many, or a subset of payment flows throughout the whole organization. So this change could very well mean a significant effort to share flow information between business units (since one process might intersect multiple business units) and to ensure all payment flows are accounted for in the documentation. Lack of appropriate documentation has always been one of the primary issues within an assessment context, so this change amps up what was already a known issue.
Secondly, the update for virtualization on the surface seems relatively innocuous; after all, many of us have been asking for a long time how virtualization ties into requirements like "one function per server" (Requirement 2.2.1). However, under the surface, expansion of the definition of "system components" to include virtual components might have additional ramifications beyond just 2.2.1; it could affect other requirements as well. For example, some requirements and test procedures specifically refer to "all system components" (for example, Requirements 10.6, "Review logs for all system components at least daily…", and Requirement 2.2, "Develop configuration standards for all system components…").
Requirements that address "all system components" now implicitly include the virtual environment as well, as do the test procedures. So a test procedure like 2.2.a ("Examine the organization's system configuration standards for all types of system components and verify the system configuration standards are consistent with industry accepted hardening standards") means that not only will an organization need to have a hardening standard for its virtual environment, but its assessor will also need to obtain and review that standard. This might not have been the case in prior assessments.
So overall for merchants and service providers, this version of the standard represents a streamlining of the assessment process, which should help ease the PCI DSS compliance burden somewhat. But the expansion of system components to include virtualization and the updates to required documentation could make those elements of the assessment process more complex, so be sure to address each with your assessor when the time comes for your company's first assessment under PCI DSS 2.0; also, it's a good idea to start the planning now for areas where your current control deployment may not address the entirety of the scope.
About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of SecurityCurve.