The future of PCI DSSDate: Apr 06, 2010
Bob Russo, General Manager of the PCI Security Standards Council, discusses upcoming changes to the PCI DSS, including when the PCI SSC plans to reveal the first details about upcoming changes to PCI DSS.
Watch part two of this interview: Re-evaluating QSA training
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact email@example.com.
The future of PCI DSS
Rob Westervelt: Hi, I'm Rob Westervelt, the News Editor of
Thanks very much for watching this video. Today we are going to be
talking about the Payment Card Industry Data Security Standards with
Bob Russo. Bob is General Manager of the PCI Security Standards
Council. Bob, thanks very much for joining us.
Bob Russo: My pleasure.
Rob Westervelt: Bob, in 2009 there were no major changes made to the PCI standards.
How would you characterize the year for the payment industry, given
the massive data breach in Payment Systems and the down
Bob Russo: In 2009, we are seeing a lot of uptake on the standard. Since it is a
global standard, we are seeing it throughout the world. We are doing
lots of training, lots of awareness-type seminars for literally every
place around the world. All of our training is pretty much sold out,
so much so, that this year, we are having to add extra training
sessions so that people can understand what the standard is and get
better prepared for an assessment. All in all, 2009 was a pretty good
year for the council. 2010 is a very busy year for us in terms of
releasing three standards this year in eight different languages. We
are working hard.
Rob Westervelt: The council recently undertook a study examining emerging
technologies that could be used in future versions of the standard.
Can you talk about some of those technologies that we may see in the
Bob Russo: Currently, we are studying a couple right now to give additional
guidance on, hopefully, this year when we release the standard, and
those are Chip, as an initial one because Chip is a mature technology,
there is a lot known about it, we have a lot of experience with it,
outside the United States. We are looking at Chip, and we are actually mapping
how Chip would compare with the standard, so if you were using some
sort of Chip technology, would that make you compliant with certain
requirements within the standard? We certainly do not think that there
is a silver bullet anywhere in any of these technologies, whether they
are Chip, Chip and Pin, intend encryption as the buzzword goes,
tokenization, or anything of that nature, there is still going to be a
need to comply with the standard. These technologies do, in some
cases, map up with the standard, and in some cases, make you already
compliant with some of these requirements. That is what we are doing;
we are creating a framework right now where we can map these standards
out and lay them right next to the standard so that we can give
guidance to somebody who is using one of these technologies and let
them know that if they are using these technologies and they do these
certain things, that they will, in fact, already be compliant with
this requirement, or that requirement, or close to compliance, or it
satisfies that requirement. That is what we are undertaking right now.
The first one will be Chip, the second one will be some form of
encryption. Intend encryption, I don't like that term, whether it is
point-to-point encryption, or account data encryption, or transaction-
based, whatever it ends up being, we will be mapping that as well,
then we will be moving on to other technologies. Tokenization, we will
be looking at virtualization later in the year and how that maps out
with the standard as well.
Rob Westervelt: I know you dropped Pin from Chip. Should we take anything from that?
Bob Russo: It's Chip technology that we are going to be looking at, and there
are different areas within Chip. Chip and Pin is one area, but rather
than call it Chip and Pin, we have to encompass the entire solution
there, which is, in fact, Chip.
Rob Westervelt: The standard is due for revision in 2010. Can you give merchants an
idea of what may be addressed?
Bob Russo: At this point we are still going through a ton of feedback that we
have gotten, and our feedback analysis closes at the end of April, and
what we are finding is that this feedback that we've got basically fits
into three categories. That would be: additional guidance,
clarifications, and these emerging trends, or emerging requirements,
and what these requirements will look like. As you can well imagine,
with a couple of thousand pieces of feedback that we are going
through, there are conflicting types of things there. As an example, in
the clarification area, we require strong hashing. 'What is strong
hashing?' So we have to put a clarification out and describe what that
may be. We have conflicting opinions on different things coming in; as
an example, passwords. Somebody will say, 'This length is too small.'
Somebody else will come back and say, 'That length is perfect.'
Somebody else will say, 'We need to have something smaller; it is too
big.' At this point, when do we change these passwords? Every 90 days?
Wait, that is not enough. It has to be every 180 days, or we need to
change it every 30. We have conflicts here, and we have to look at all
of this stuff and how they affect the standard.
The biggest thing that will affect the standard going forward is how
to best protect the data. That's the first consideration, then how
much will this cost a merchant to do? What is the return on investment
to do this? Is there anything that changes fundamentally the way the
customer actually will have to comply with the standard in the way
they have to do business? If there is something that fundamentally
changes the way they do business, then certainly we can't put that in
initially and have people go out of compliance at this point. In some
cases, that might be a best practice for a certain period of time, and
that was what happened in the last version of the standard on 6.6, the
requirement 6.6. It was a best practice for 18 months, so that people
had the opportunity to back into it because it was a big change in the
way they complied. It will be the same. A little too early to tell if
this will be a version 2, or a version 1.3. We are still analyzing the
feedback. When the feedback is finished being analyzed, we will be
releasing a summary of what the feedback was, that will be in the
early spring. As we get to the beginning of the summer, we will be
releasing summaries on what the changes will be, so when we get to
October and we actually release the Standard, there really will not be
Rob Westervelt: After the Heartland Breach, there has been this big push for end-to-
end encryption, not only from Heartland, but from other payment
processors. Is that something that the council will look at?
Bob Russo: As you mentioned earlier, we are looking at end-to-end encryption.
Some of the questions we have are, 'From what end, to what end?' That
is an issue. It's very big buzz word. There are no standards yet for
this type of encryption and how the keys are handled. In a lot of
cases, you could end up making things less secure based on how you do
this thing. You mentioned Heartland. That's one solution, but there
are probably a dozen solutions out there. Do they talk to each other?
Are they interoperable? What if a merchant is using more than one?
These are things that have to be considered when looking at this. What
we will be studying is an encryption solution and the minimum level of
things that needs to be done within the encryption solution. Then once
we got that, we will put out some guidance, probably nothing specific
within the standard. The standard will not change, but there will be
guidance based on using these things.
Rob Westervelt: Tokenization is also part of some payment encryption products. Could
that make its way into the next version of the standard?
Bob Russo: Guidance could make its way in. I don't see us requiring any kind of
tokenization, intend encryption, Chip technology, or anything like
that, in this version but certainly guidance on these things. If the
merchant has already started down a path and spent some dollars on one
technology, it would not be in our best interest to say, 'You chose
the wrong technology, now you need to use this technology.' There will
be guidance on each one of these things, as we roll out.