In a previous post, I discussed the so-called “Requirement 0” of PCI DSS 2.0; that is, responsibility for determining and documenting the scope for PCI DSS shifting from the Qualified Security Assessor (QSA) to the entity. Oftentimes this conversation comes up as part of a bigger discussion around the process of becoming and staying compliant while meeting business, financial, IT, and customer demands. Balancing these can be a daunting task.

Symantec Strategy and Advisory Services has developed a program model for PCI DSS compliance to assist with this. Using an ADTO framework – Assess, Design, Transform, and Operate – it breaks the process into four phases. This model is also a lifecycle as it acknowledges the need to feed data and lessons learned back into assessment, allowing for increasing maturity with decreasing cost over time. The model looks like this:

Let’s dive into the ADTO model and discuss how it can assist with PCI DSS compliance.

One thing gaining traction in PCI DSS is the notion of tokenization, which uses a unique identifier instead of the credit card data after its first use in an authorized transaction.  Afterwards, the actual card data is stored in a centralized, highly secure server called a “vault” and a token is used in its place.  This approach removes the actual card data from the applications and systems when it isn’t needed and reduces the amount of Cardholder Data Environment (CDE) that’s in scope for PCI. This, in turn, makes it easier to manage and meet PCI compliance!

Why?  Because if a system, application or host doesn’t actually store or process card data—remember, they’re using a token instead—then it may not be in scope for the PCI environment.  This may significantly reduce what “things” are parts of the PCI environment.  Another advantage of PCI tokenization is if an attacker compromises the system and obtains this token,  it isn’t card data, thereby, reducing the impact of a data breach.

One of the major changes introduced by version 2.0 of the PCI DSS is that responsibility for determining and documenting the scope for PCI DSS has shifted from the Qualified Security Assessor (QSA) to the entity (merchant, service provider, acquirer, and issuer). Specifically, the PCI DSS states that “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.” The resulting scope may include the entity’s and third-party’s system components, as well as those that may not store, process or transmit cardholder data but could impact the security of the cardholder data environment. If an annual onsite assessment by a QSA is required, he or she is now responsible for reviewing the entity’s scope. Since this requirement appears before the traditional twelve requirements of the PCI DSS it has been referred to somewhat tongue-in-cheek as “Requirement 0.”

It’s been a busy couple weeks since the release of the PCI DSS version 2.0, as organizations and assessors alike pour over the documentation and begin planning. Nowhere is this more evident than in the discussions I’m already having with clients. I’d like to talk about some of the questions and feedback I’m hearing, as well as some more of the changes you may want to consider in planning.

There are 132 changes to the PCI DSS: 115 clarifications, 15 items of additional guidance, and two evolving requirements. As I mentioned in my last post, this may seem daunting. However, while there may be items in the clarifications that do present opportunities or challenges, many of the clarifications will have minimal impact on what compliant organizations have been doing previously.

It’s official – on October 28, 2010 the PCI SSC released version 2.0 of the DSS and PA-DSS. The months of speculation are over, and we can all begin reading through the documents, trying to figure out how the changes will impact us. Before I talk about what I consider to be some of the more significant revisions, let’s review the scope of the work.

Over the past two years the Council received thousands of items of feedback and input. The 132 changes to the PCI DSS that resulted fall into three categories:

• Clarifications – 115. Per the documentation, “Clarifies intent of requirement. Ensure that concise wording in the standards portray the desired intent of requirements.”
• Additional Guidance – 15. “Explanations and/or definitions to increase understanding or provide further information on a particular topic.”
• Evolving Requirements – 2. “Changes to ensure that the standards are up to date with emerging threats and changes in the market.”

As a QSA I’m often asked which requirements organizations typically struggle with, what solutions they implement, and how these factor into the cost of compliance. With the introduction of PCI DSS 2.0 this year I’m adding another question to the mix: how does the revised standard change this?

As I’ve posted previously the changes to the DSS are evolutionary and should not present any major  issues to organizations already in compliance. I would further add that I do not see the changes significantly shifting the landscape with respect to the challenges that organizations already face in complying. Before I dig into that let’s take a look at what some of those are based on trends collected from the numerous PCI assessments Symantec’s Advisory Services QSA team has performed:

• Lack of formalized policies, standards, and procedures: these may be “social” but not written, and may not be reflected in the actual implementations (applies to multiple Requirements).

Last week was the PCI Community Meeting in Orlando, FL. Symantec was represented by myself and Chuck Kesler, who joined nearly 1,050 other professionals from across multiple industries for three days worth of sessions and presentations. The meeting was a great opportunity to hear about the state of payment card security, emerging technologies, the upcoming revisions to the Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS), and to network with clients and peers. It was also nice to put faces with the names and voices from the Scoping SIG after a year’s worth of work.

Having returned to the office the question we’re now hearing is this: what does PCI DSS 2.0 mean to me? How will it impact my compliance efforts, and what will the cost be? And how long do I have to comply?

It’s hard to believe it’s been two years since the release of the PCI DSS 1.2. In those two years we’ve seen the threat landscape evolve and mature with the commoditization of attacks, the continued changes in and complexity of infrastructure and operations, and a shift towards organized crime. The pending release of version 2.0 strives to evolve the standards, to enhance clarity and to address threat and technological changes. Work from several Special Interest Groups (SIGs) is also coming to fruition and should result in a series of additional publications such as Information Supplements and other guidelines.

We are anticipating that this version and supporting guidelines will address areas such as virtualization, tokenization, end-to-end encryption, cardholder data discovery, and provide for a more risk-based approach to protecting payment card data.  Equally importantly, we are expecting to see some areas of the scoping process clarified, including how the standards should be applied in issuer environments.