Compliance SchoolPCI DSS compliance: Two years later <<previous|next>> :Applying PCI DSS to Web application security
PCI DSS 1.1: Strategies for compliance
PCI DSS 1.1: Strategies for compliancedate:Jul 08, 2010
In this presentation, Diana Kelley of consultancy SecurityCurve and Ed Moyle of CTG discuss the changes that have taken place in the first two years of PCI DSS 1.1, and look forward to potential future changes.
Originally published Nov. 11, 2008.
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.
PCI DSS 1.1: Strategies for compliance
Eric Parizo: Hello and welcome to Reports from the Trenches.
Once working with
PCI DSS featuring guest speakers Diana Kelley, and Ed Moyle. My name is
Eric Parizo. It's great to have you with us. It's been more than three
years since its inception and the payment card industry data security
standard also known as PCI DSS is still causing headaches for enterprises.
Its intent is to protect cardholder data and allows for requirements to
appear straightforward, but they leave a lot of room for interpretation,
sometimes, too much. Making things worse, even assessors don't often agree
on what caused the dis-compliance, and with more pressure coming from the
big credit card companies and a PCI revision likely on the way, there is
plenty for security and compliance pros to worry about.
We'll discuss PCI compliance success stories and strategies, and
how you can apply them to your organization by using firewall,
IDE, access control, content management, web application
standards, and source code checkers coupled with strategy and
planning, it is possible to effectively meet PCI DSS compliance
mandates and deadlines. We will also offer guidance on
implementing a compliant framework for PCI DSS and mapping
requirements to existing controls and risk assessment decisions.
Our speakers today are Burton Group Vice President and Service
Director Diana Kelley, and CTG manager Ed Moyle. Diana has more
than fourteen years of experience creating secured network
architectures for a large corporation, and is one of the
industry's foremost experts on the intersection of security and
compliance. She has previously served as a strategist for
several top security vendors, and is a frequent speaker at
Ed Moyle is a certified PCI-qualified security assessor and
previously served as Vice President and Information Security
Officer for Merrill Lynch Investment Managers, where he was
responsible for coordinating all aspects of information
security. Ed is co-author of "Cryptographic Libraries for
Developers," and a frequent contributor to the Information
Security magazine. He is a public speaker and analyst throughout
the industry. Thanks to both of you for joining us today.
Ed Moyle: Thank you.
Diana Kelley: Thank you.
Eric Parizo: And now without further delay, Ladies and Gentlemen, Diana Kelley and Ed Moyle.
Ed Moyle: Hello. So, to just start us off in starting about PCI, what works and
what doesn't, stories from the trenches, Briefly what we're
going to talk about is introducing a bit of what PCI is and what
it does, talk a little bit about why we validate for compliance,
why firms are asked to do this, move through to talk about,
within the compliance validation process, some of the roadblocks,
some of the hiccups that firms experience along the way, and hopefully
by pointing out what some of those hiccups are, this will give
you some strategies on how to avoid those as you go through the
compliance validation process in your own organization and then to
wrap it all up before the Q&A, just a brief discussion on some
of the strategies that work and what you can do, some quick bang
for the buck type of solutions that you can bring to your company to
help move that forward and hopefully streamline the compliance
validation process. So let's move into it.
Diana Kelley: An overview of the PCI DSS - I think it helps organizations to
understand what it is and what it isn't. It's intended as a
minimum baseline of controls for helping organizations
understand how they can protect credit card data. This is not
the actual compliance final say because each of the card brands
do retain their own control over compliance. This is the
baseline so that organizations that do transact or use credit
cards for them, transact them, have a good set of baselines that
they can follow in order to know what they should do because before the
payment card brands got together, to issue the DSS of an entity
through the Security Standards Counsel, there was a lot of
confusion with the merchants.
Sometimes there is a confusion with entities that say, "Well,
process a lot of credit cards," or "Yes, it's true that we do
hold credit card information, but we don't actually use them for
payments, we use them for other reasons, identification for
example." and the point about the PCI DSS is that it really
applies to everybody that is a steward of credit card
information for processing transaction storage. So if you have
that information, if you retain it for your employees, you have
to take a look at what you need to do in order to protect that
If you're a retailer, a merchant, or a payment service provider,
it absolutely does apply to you. You may be at a different level
of what it means for you to be in compliance with the standard,
but it does apply to you regardless of whether you're processing
a large number of credit card payments or a very small number.
Finally, this was really the unified chance to bring this
standard together, because as I mentioned at the top, the final
compliance does remain with the individual card brands, but this
is a baseline that they've all agreed to use in the process of
that ultimate compliance.
Ed Moyle: A lot of you, or some of you, may recall in years past, there were a
number of individual validation programs. There were a number of
security initiatives within the different card brands. This
slide illustrates a few of what some of those historically were.
In the past there were a number of requirements and merchants
and service providers, gateways and so on, a lot of confusion
around this and folks were wondering, "What specifically do I need
to do?" So the intent of the DSS, the intent of having a unified
standard is to get everybody on board, to get one standard that
represents the minimum baseline controls folks need to apply to
We'll get into what some of those controls specifically are in a
second, but it really is a much less confusing world now. A lot
of people are confused by the DSS, but really this is a lot less
confusing than what it used to be. For example, folks who
remember CIS, the Cardholder Information Security program, you
may recall that there was quite a bit of difference technically as it
compares to the site data protection at MasterCard. And of
course, if you were a merchant that accepts multiple different types of
payment, there were quite a few standards that you might have to
So now hopefully you just have one. As Diana alluded to, your
particular card brand does have final say in terms of what the
specific requirements are, but this is the minimum baseline
standard that everyone needs to adhere to, so this applies no
matter, again we'll get to this in a minute, but this applies no
matter what size you are. So if you're a mom and pop shop, or if
you're a larger merchant, you have to conform.
Diana Kelley: So we will definitely keep talking about this, what does it actually mean?
We've got here the top level twelve requirements, we split them
over two sides so you can read them, but there are twelve top-
level requirements associated with the DSS. Sometimes, I call them
the twelve steps, because the first step is to admit that you
have a payment problem. No, seriously though. They are twelve
steps that help lead you to what you need to do to protect
credit card data.
A lot of times when people see these twelve steps, especially if
you've been in the information security profession for any
length of time, you may see this and go, of course, these
make perfectly good sense. Reading over them, if we look at the
beginning, we have install and maintain a firewall. How many
organizations are connected to the internet that don't have a
firewall, or even multiple firewalls, or even hundreds in some
cases with large organizations.
Looking down at requirement six, regularly update antivirus
software. These are things that we in the information security
profession have seen for a long time, we understand and accept
them. The point about the standard when you get into it is that
the devil is in the details in some senses. So it's not just
these twelve top steps, which are your good baseline top steps,
but then also the specifics that are associated with it. It sets
up requirements that are giving some organizations some trouble.
We're going to take a look at the rest of the twelve.
Ed Moyle: As you go ahead and look through these, these seem like good sense
security measures that make sense. A lot of information security
folks have seen these before, but there really are a few that I think
are important to call out as we go through this. We see as we
move through the specifics of what's required here, the actual
testing processes associated with these standards and the actual
certain sub components of each one, are real important for people to
pay attention to.
So if folks haven't already looked through some of the
documentation that supports these, the PCI Standards Counsel,
for example, maintains an actual standard itself which has the
steps within each of these requirements, as well as the auditing
procedures that they publish as well. Those are real useful for
folks to look at.
But again, just from a high-level overview perspective, these
are the twelve steps. It's not just about meeting the
requirements; it's also about documenting how you meet each of
the requirements. So that's actually a big chunk as well of
specifically what you would need to do.
Diana Kelley: Another interesting thing Ed mentioned but he went over it a
bit quickly, and I think that might be because he's actually a
qualified security assessor so he lives and breathes this
document, is the security audit procedures. It's about a fifty
page document, and I'm not a qualified security assessor so I
print it out, I keep it in my desk, because I do a lot of
research on PCI. I talk to customers about it. That shows you
what the assessors, folks like Ed, are actually looking at, when
they are saying yea or nay, you passed or didn't pass, that's
the document they're using. It is freely available at the PCI
Security Standards Counsel site, and I do recommend downloading
it and maybe keeping a copy in your desk if you're required to
do PCI compliance work at your company.
At the top of this, Eric mentioned that it's been around for two
years, and then Ed and I were talking about the other compliance
standards, the card brand specific compliance standards. There
is also a lot about deadlines, and all of these deadlines
surprised me. It's kind of interesting to look at how this has
changed because in the United States, it's really stepped up
and it's important for a lot of organizations that went from
"Yes, it would be nice to have," to "We really have to do this."
And I thought you might be interested in a little bit of the
history of why that happened.
Initially, this was actually 2001, Visa came out with their
first iteration of CIS, and it was intended for the e-tailers.
Because at that point, the concern was, "We're doing all this
commerce over the web, because we know the internet is a little
bit frightening." But ultimately it was found out that it really
wasn't just e-tailers that were involved, that on the physical
side in the brick and mortar world, we do have a lot of
concerns. Many organizations, even if they're not performing
online web-based sales, they may be authorizing over the web, or
they may just have their databases not fully protected, and they
are hooked up to the internet, the rest of the organization is
hooked up to the internet, and it could be a way to worm
through, or just to a corporate network that you could worm
through as well.
In 2004, we have the first deadlines. They were for the tier one
merchants. If you hear tier one or level one, that's set by the
brands themselves, what that means is it's based on the number
of transactions that you perform per year. 2005, the Security
Standards Counsel was formed and issued the first iteration of
the DSS under their office, and this was version 1.1, and there
were also compliance deadlines in 2006 for the tier two
merchants for the PCI counsel for 1.1.
The big thing in 2006 after September and the PCI counsel being
formed, the big thing was that TJX reported what there had been
what they're calling a computer intrusion, if you read their
10K. And that computer intrusion was initially thought to be
about 45.6 million cards that may have gone missing. During the
hearings for the cases that are going into the court against TJX
at this point, there was a person from Visa who said that they
think that it may be about double that amount of cards that went
missing. Whatever that final number is, it was one of the
biggest losses of credit card data that had been reported to
date, and that really shifted things quite a bit at the end of
2006, because suddenly it became of great urgency for a lot of
organizations to become compliant.
One, because a number of organizations didn't want to be TJX,
they didn't want to be the ones that were saying, "I lost all
that card data." The other big reason is that the brands and the
acquiring banks started going back to the retailers and the
processors and saying, "We could give you fines and fees." These
were larger fines and fees than they were hearing previously to
late 2006, early 2007.
Another interesting thing occurred in 2007, which was that
Minnesota Plastic Card Security Act was signed into law. It was
a response in part to TJX, and what occurred there. It appears
the intrusion first occurred in Minnesota. Even though the TJX
servers were in Framingham, Massachusetts, it appears that the
attackers got through from a parking lot outside of a TJX retail
store, I believe it was a Marshall's, in Minnesota. This act
kind of shifts the equation quite a bit, because it is looking
for the liability and remuneration for the loss to be put back
on the retailer. Specifically, the big one here would be the
cost of reissuing cards.
When a credit card has to be reissued from an issuing bank,
costs can be anywhere from $7 to $30 as I've read under the
reports. Now, if you multiply, even if you take a low ball
number such as $7 and you multiply that by 45.6 million off of
the low ball estimate, you still have a pretty high number. So
if we actually see this kind of thing going through with case
law, either with the cases against TJX now from the issuing
banks, or if someone is actually held to the standard of the
Minnesota Plastic Card Security Act, the financial impact for
the retailer, merchant, or processor that lost those card
numbers could be extremely high. Some of the other states that
are looking at these kinds of laws are California,
Massachusetts, and Connecticut.
Another big point in 2007 was in September, the Security
Standards Counsel met with a community meeting which took a lot
of the stakeholder information on what we might see in the next
version of the DSS, how well this one is working for them as
well as what might need to be changed in upcoming versions. So
for 2008, looking into the crystal ball is always a little bit hard but
I think the two things to look for are the PCI, next version of
the DSS, whether it be 1.2 or 2.0. We have just seen as of
November 7, the payment application practices go from Visa into
the Standards Counsel, so we'll see organizations now working to
meet that that may not have before, if they were just MasterCard
or American Express processors, now that's in the Security
Standards Counsel as well.
Finally we may see state laws or case laws, as I have mentioned,
that are continuing to shift liability, should loss occur.
Ed Moyle: Earlier on, we had said everybody must be compliant with the DSS,
which is true. However, there is an additional step that some
folks need to take in bringing this into validation of
compliance. Basically what this means is there are some firms
that need to not only be complaint as everybody does with DSS,
but they also need to validate that they are complaint, they
also need to submit to the folks that are above them in the
payment chain a Report on Compliance, an ROC, that demonstrates
that they have been through a compliance validation process.
The specific criteria that dictates who needs to validate
compliance or not is defined by the individual card brand. They
do differ from brand to brand. 95 or 96 percent of the time, the
way this works is they will contract with an individual
professional who is a QSA, Qualified Security Assessor, which I
am one, and they will utilize them to complete the assessment
criteria that Diana referenced earlier that is held online on
the PCI standards website. So they will go through that
assessment process, they will complete and sign the report on
compliance, and submit that through the appropriate channel.
We talk about the appropriate channel, usually that's your
merchant that you're acquiring. I say 96 or 97 percent of the
time, if you are a level one merchant, you can in fact complete
this without the assistance of a QSA. You can complete the
documentation yourself, have an executive, an appropriate
individual within the company like CFO, sign off on that and
submit that instead. Again, that is if you're a level one
merchant, so that does not apply to service providers. Level one
merchants are the folks who do the most transaction processing,
who handle a tremendous volume of transactions. When you're
thinking of level one merchants, think of Amazon.com, the very
large, very active, high volume transactions.
Historically, the reason for this was that for the
that have a lot of retail shops that may be distributed
throughout the country, because of the fact that the scope is
set by the assessor, obviously if you have hundreds of thousands
or more retail locations, obviously that can get expensive if
the scope is set to validate all of those. In practice, it
almost never happens. The level one merchants, more often than
not due to liability and other concerns, do tend to bring in a
QSA to do this. Actually, I have yet to hear of somebody
actually validating themselves, but the provision is there to do
it if they wanted to.
Again, that's a quick overview on the validation of
and what it's for, how it works, just before we move on to
talking about what works when you actually get down to the
validation portion of this.
Diana Kelley: I agree, I've heard some of the large organizations that I've
spoken with saying after going through a validation with a QSA
for one or two years that they may start to do it internally as
they gain confidence that they feel they could do it
appropriately. But the majority of organizations that I've
spoken to are actually using a QSA, at least for the first one
or two compliance assessment cycles. That is those level four
merchants that can do their own self assessment. In that case
you are seeing internal self-assessment.
We're going to actually talk about the stumbling blocks, and
these came from a compilation of customers that I've spoken to
during my research at the Burton Group, and what Ed has heard
from his customers as he's been going out to do his assessments.
Some of the main ones that we've heard here are the scoping and
the zoning, application security being a big bugaboo, and that's
including access control to the applications, which is actually
touched on in other pieces of the standard as well as in the
application part, and the finally the readiness, organizations
getting ready for what they need to do for the assessment.
Ed Moyle: So this is actually trying to be a bit funny here, but there is a
lesson. A lot of firms fail the first time through. This can be
failing when they first undertake their first look at the thing
and first internally work through the assessment requirements to
validation of compliance, or it can be actually having a QSA
come on site and say, "You're not ready to validate and submit a
ROC where you actually pass." Basically, the lessons that I
would suggest folks take away are to look very critically and
very carefully at the scope. The temptation in a lot of firms,
and we'll get to why this is a bit erroneous in a minute, but
the temptation is to say, "We're not able to segregate our
cardholder environment from the rest of the network, and
therefore the scope of the assessment, we want that to be the
entire network." That is the number one most likely way to get
you to fail the validation process right there.
In addition, a lot of folks particularly in some of the larger
merchant communities have a lot of applications in place. If
you think about the type of software and the mechanics of
keeping a system at a large merchant fully operational, you
understand that the applications are huge. A lot of the times
they are either heavily modified commercial off the shelf
products, or they are applications that are written in house. If
they're written in house, guess what, the requirement still
applies, even if it's a legacy product that is driving your
The third most common issue that we see arise, the folks
into the assessment cold. What we mean by that is without
planning and preparation, without having a chance to sit down
and go through what it is that they'll be required to do. The
best time to do this is not when your QSA is on site and say,
"Show me your evidence," it's six months before that, when
you're actually contracting, when you're getting ready to get
through the process.
Diana Kelley: I would agree, maybe instead of the failure, maybe you can
think of it as the little guy from Hitchhiker's Guide, which is
"Don't panic." Don't be worried if as you do your initial gap
analysis that you can't get everything right, or you don't see
that everything's right, because in many cases this is really a
process of going to get it right, making sure the steps are in
place, using commentating controls until you can move to other
types of controls, the more desired controls.
To reiterate what Ed said, he sees scopes and zones as the
number one most common assessment issue, and I would agree with
that. I do have some large customers that have actually gone to
a completely physically separated data center, because they do
feel that that's the best way for them to scope off the rest of
the organization. You may not have to go that far, that's a
pretty costly endeavor for most organizations, but get some
segregation, get some zoning for your environment so that you
don't have an assessor come in and look at every single host
throughout your entire network as part of your PCI compliance
Ed Moyle: So just to take a look at this because this is such an important
lesson in my opinion. A lot of folks tend to start this the
wrong way, and I'm not sure what the dynamic for that is, but
just to illustrate why this is so significant. If you look at
two scopes, and on the left you have the scope of an assessment
where there's absolutely no segregation between the cardholder
environment and the rest of the network, and if you look on the
right side, where there is some segregation.
When you take a look at those requirements that we looked at
earlier, say for example, access control and auto-logging,
making sure that information has an appropriate audience and so
on, data confidentiality, in this example, you have Carl's cell
phone, Eric's laptop, and Kenny's PC. Where are the audit
requirements for Eric's laptop? Where are the specific access
control requirements for items in Carl's cell phone? Guess what?
You don't want somebody to come and actually evaluate that
because more likely than not, it's not going to meet the
So if you open that scope up by not carefully zoning, by
documenting what the scope and surface of the assessment is
going to be, you wind up with the situation where everything and
the kitchen sink is included in the assessment, and that is very
problematic because some of these devices that might participate
on the network that might in that case be in the cardholder
environment, they might not have been designed, or not been
built out or configured with the PCI DSS requirements in mind.
That can over the long term become a significant issue.
Diana Kelley: One key to remember as you're doing that scoping work is that
you're making sure that Carl's cell phone doesn't have any PAN's
primary account numbers on it. You want to make sure that Stan's
printer also doesn't have that. So as you're doing the scope,
what you first need to do is do a discovery to make sure that
you don't have any of that information that's covered under the
DSS outside of that little red zone that you see there. Then
what you do is you can put monitoring at that firewall at that
segment point to make sure that it isn't going out of the
payment zone. So as you're scoping down, don't forget to do your
due diligence and make sure that you've done discovery and
eradication of any information that should not be stored outside
of the payment zone that may be part of the DSS. Scoping and
zoning on how you can actually do perimeter control. This is
from a Burton Group technical position on this point.
We broke it down to a couple major differences. Separation, for
example, you can do a full air gap, you can do physical
separation, you can also use your firewalls or your routers to
ensure that you're tracking ingress and egress of that traffic.
You can perform filtering as well, such as web content filtering
and data inspection, specifically looking for things such as
primary account numbers. I mention those a lot because that's
one of the big gotcha's in PCI, you have to be very careful what
you do with that. Something else you could look for is
sensitive authentication data. This data is only usable during
the authorization process, so you should have no sensitive
authentication data on your network that's being stored or being
transferred to a device for storage. So if you see that kind of
information data that's not part of the authorization process,
and you see it with your filtering, you can stop it, block it,
make sure that it's not moving beyond your zone.
You can also use transformation, what some people call
encryption, you can protect that data so as that sensitive data
is moving around the organization, such as that primary account
number, which you are allowed to store if you control it and
protect it properly, and you can use such things as VPN. That
creates a little perimeter around the data as it passes over
networks, including untrusted networks. You can use deception,
such as network address translation and port management to help
keep those out that you don't want coming in. Then finally, and
this is also listed in the DSS very specifically, do some level
of monitoring, intrusion prevention or detection, recording the
information that goes past on the network to see if there's
something going around that you don't want.
A note with the monitoring, especially if you're
everything that goes on the network, do take a look at what's
being recorded because if you are actually recording that
sensitive authentication data or even the primary account
number, you need to scrub that sensitive data from any of the
logs that you're keeping because you are not allowed to hold
that under the PCI DSS pass authorization. If you do have the
primary account number in there, do remember that even in an
audit log, it now has to be protected at the same level of 3.4,
which is what you would do for protecting the primary account
number if it's in a database.
Ed Moyle: One thing to bring up at this point is if you're going to apply one
of these strategies to scope the assessment, just don't decide
ahead of time, this is going to be the technology we're going to
use to scope the assessment and have it be that. You want to
document why you think that technology reduces the scope, and
you want to provide that to your QSA when they show up on site.
You want to make sure that they agree with you, because if for
any reason they don't and the audit goes beyond the scope of
what you'd originally intended, that puts you back in that big
red circle where the whole network is in scope, so keep that in
Taking a look at the application issue, this is again something
that we find to be a significant factor. A lot of these
applications, particularly legacy point of sale type
applications, were not necessarily designed with these
requirements in mind. So there are applications out there, and I
won't name any names, that do all kinds of crazy stuff that you
were never allowed to do, like store magnetic track data, track
one, track two type, they would store CVV information, the
verification value, that little number that's printed on the
back of your card that you're never allowed to store, that type
of thing. Take a look at the applications within your firm and
just do a little bit of investigation and see, am I going to be
surprised what these applications are doing during the actual
assessment process itself.
Like I said, this is a big issue. Typically, at least in every
assessment I've ever done, there's always some application issue
that rears its head throughout the thing and nine times out of
ten it wasn't anticipated ahead of time. Take a look at that and
make sure that things are what you expect.
Diana Kelley: This is something that I was really pleased to see in the data
security standard. As you can see here there is some great
common sense about maintaining your systems and the applications
securely. It's actually saying straight out here, put security
throughout your software development life cycle. This is a very
strong trend in business these days as organizations realize
that their applications are actually a very vulnerable area
within their whole risk life cycle, but we haven't seen a lot of
standards call this out specifically prior to the DSS, and now
as the payment application best practices has gone into the
Security Standards Counsel.
So if you've been trying to get your organization to adopt a
secure view of the software development life cycle, or to
implement things such as code reviews, additional security
testing to add to your QA testing and your application life
cycle, you've got it called right out here in the DSS, so that's
a good point here if you need to support that throughout your
organization. If you didn't even know about it, then do take a
deep look at requirement six and the sub-requirements related to
it for more information on what they're talking about at least
here for application security.
It is true that applications are hard to get right. The DSS
makes quite a big pointer to the OWASP, which is the Open Web
Application Security Project's top ten. This is a great starting
point, although the DSS does just list OWASP's top ten without
any additional information, so I do recommend that you take a
look deeper into the artifacts that are available on the OWASP
site at OWASP.org. They actually have a testing guide that can
help you with testing the top ten. Another thing that I'd like
to point out is that organizations are finding that in many
cases they've architected their applications to, as Ed said,
store way too much data. A lot of point of sale systems are out
there that are storing the data because they could, and by that
data, I mean sensitive authentication data, PIN-based data, or
the CVV or CVV2 code. So go through audit and make sure that you
can eradicate that as well.
The payment application best practices which we've discussed a
couple of times already. You can take a look at that, there's a
copy, it just went into the Security Standards Counsel, it gives
you additional guidance on what you can do in your applications.
Make sure that you've understood exactly what the process is. To
Ed's point, document, because that's a lot of time what the
assessor is coming in for. I've had customers call me and say,
"We're using this product, and this is how we're using it," or
"We're using this methodology," or "We're using this process and
this is what we're doing, and the assessor said it wasn't
enough." I say, "Do you have it documented?" They say, "No, but
we all know. It's cultural. We know we're using that product, or
we know what process we're using." Well, the assessor doesn't
know, they don't live in your culture, so you do need to
document it and make sure that you have that ready for the
assessor to review when they come in for the validation.
Ed Moyle: That translates directly into planning. Planning is hands down one of
the most important things you can do. Basically, when an
assessor comes in, they're going to be looking for the
documentation that you have in place to support these
requirements. From an application perspective, they're going to
be looking for what kind of documentation you have that
describes your software development life cycle. What kind of
documentation do you have in place that describes how you scope?
So going through ahead of time and preparing some of this
documentation really saves you a lot of time and energy.
A lot of folks say, "We don't have the time to document this
stuff," or "we don't have the inclination," or "Doing that is
going to take away from time that we could have spent doing
other things that would help to get us to compliance."
But really, if you spend that time and you do document, that
really does help because as you can see if you take a look at
the actual assessment procedures that are on the PCI Standards
Counsel site, documentation is pretty much the majority of what
the QSA is going to be looking for.
Just to tie that back to applications, keep in mind that in a
lot of cases, the QSA is not going to necessarily be looking at
the applications themselves. In some cases they will, it really
depends on the thoroughness and the role of the application in
your infrastructure. Really, they're going to be looking for the
documentation that surrounds it. They're going to be looking for
how your SBLC is documented. Of course, as Diana said, doing the
right thing. That's great, but unless you say how you're doing
the right thing, that really doesn't do much for you.
Diana Kelley: Quickly, we're going to run through some quick hits, wins, and
recommendations on how you can succeed with PCI and PCI
validation. I like to say this as, don't store what you don't
need. It really talks to, first of all, do not store that
authorization data. It may be in the past that your application
developers realized they could so you did just to be safe.
That's not safe. That's not a best practice according to the
DSS, and in fact, you will fail should you be storing that. The
thing that you can store, but check to see if you need to store
it, is the primary account number. The National Retail
Federation sent an open note in October to the Security
Standards Counsel and said, "It's the brands that are forcing us
to store the full PAN, because if there are retrieval
requirements, we have to have that available." I've read other
reports as well saying that no, that's not really true, the
brands aren't forcing that.
It depends. You need to talk to your acquiring bank, talk to the
brand. But if you can store a truncated PAN, and if you can
store an authorization code number, ask yourself if you need to
store that full primary account number, because that does
increase the level of protection that you need to provide,
especially for the 3.4 requirement related to the primary
account number. So those are the two top ones. Don't store what
you don't need. Definitely don't store SAD, Sensitive Account
Data. And also, look into if you can store a truncated version
of the primary account number.
Ed Moyle: Something to keep in mind, too, I have heard a lot of folks say, "My
acquirer has told me to keep the magnetic stripe track data," or
"So and so said we need to keep it." Don't ever keep it, no
matter who says to, even if it's your acquirer. If a QSA comes
across track data somewhere in your infrastructure, they have to
fail you. They have to mark that as an issue of non-conformity.
So that's really important. And of course, validate your
assumptions when you're going into this because in a lot of
cases, folks are storing this information for one reason or
another, but there might be other ways to approach the problem.
Part of the DSS, knowing that not every control is applicable in
every organization, or knowing that not every control can be
technically met by every organization, there is a provision for
compensating controls. The QSAs know this. You can use this if
you do that planning phase we were talking about, if you do a
gap analysis, if you know ahead of time about what controls you
can't meet, you can turn that into a document that describes why
that's not necessarily a security issue. The goal of this is for
the compensating control to meet the intent and the rigor of the
So for example, if the control says to use technology A to get
appropriate auditing, and you can't do that, you might look to
some other product to give you that audit information. For
example, if you're using an application that doesn't generate
audit logs per se that would allow you to track back how a
transaction occurred, maybe there's another product that you
might be able to use. Maybe you can turn on a feature in the
operating system that would do that auditing for you. So long as
it meets the original requirement, so long as it does the same
thing and provides a control that's at least as strong as what
was originally intended by the standard, you can definitely do
An important thing to keep in mind, too, is that these
compensated controls are stop gap measures. The goal is not for
you to put a compensated control in place that exists in
perpetuity, the goal is to be able to go through and eventually
fix and put the appropriate control in place.
Diana Kelley: Do perform your pre-assessment and gap analysis. Maybe you
don't pass the first time, that could mean through your gap
analysis, not necessarily through your first validation process.
Keep in mind that you can work with a QSA in advance, not the
same QSA, of course, that you have giving the actual validation
on site, but you can work with a certified QSA and their firm to
take a look before you go through the validation process, or if
you've been having trouble in the past passing, you don't want
to back to the same QSA that did the assessment to have them re-
mediate. That doesn't provide proper separation of duties in the
assessment process. But you can work with another QSA firm to
actually help you with that, or just a network consulting and
application consulting firm that understands how to implement
these kinds of controls for you.
So go through that, and if you do have the issues, make sure
that you have a plan in place, document them, and also if you
know that you can't fix them before the QSA doing validation
gets in there, have a plan in place for correction of those.
There is a way that they can put onto the audit procedure that
no, that particular requirement hasn't been met, but there is a
clear plan in place to go ahead and meet that.
Ed Moyle: A lot of folks are hesitant to share their preliminary gap analysis
with their QSAs. I would encourage folks to just open the kimono
and say this is our gap analysis. This is our documentation of
records we've kept of how we've met these open items. Maybe
we're not all the way there yet, but in the mean time we've put
these other compensating controls in place. Most QSA's, I would
think all QSA's will appreciate that. They'll say you've done
the right thing by doing this gap analysis and maybe you're not
all the way there, but let's work together on documenting your
compensated controls for your Report on Compliance. That's
really the way to get you and your assessor on the same side so
you're working together to put the documentation together rather
than working at odds.
Just to summarize what we've said, number one, document,
document, document. They say cash is king, well, in this case,
documentation is king. Any document that you write, that you put
together and you make available to your QSA is effort saved,
both by you and your resources, as well as by the QSA. And keep
in mind that with the QSA, you're paying the bill for that
Diana Kelley: Also, it really is a journey, not a destination, and this
applies not just to the DSS but to any compliance work that
you're doing at your organization. You really want to make sure
that you understand what your framework is, why you've chosen
particular controls, that you've masked them to your risk
assessment, and that as new changes occur, be it with the DSS or
the next regulation that we have coming down the pipe, you can
start to map to the decisions that you've already made and
implement it into controls that you've put in to control data
and protect the organization, that you can then see how they may
map to the changes, whether they be in the DSS or they be for
other regulations that you're trying to be compliant with.
I'd also like to mention that part of the journey is that we
have a lot of legacy out there. So a lot of organizations feel
very challenged by the fact that they can't go and rip out their
payment application, or they can't even rip out the current
architecture, so they are putting compensating controls into
place, such as a web application firewall in front of an
application that they can't get PCI compliant now, but they can
protect with roles on the web app firewall. Do remember that
you've got that journey work to do, and if you can't rip out
that legacy, which few of us can afford to do en masse, just rip
it out, do keep a plan in place. Have your steps in front of
you, so that you know as you're moving forward that you're
getting to the next stop at the station at least rather than
spinning yourself into circles.
Ed Moyle: Very last thing; definitely try to limit the scope as much as
possible. If you can have QSA show up and the scope is one
machine that would be ideal. Just do whatever you can to try to
limit your scope to as small a pinpoint as possible. You
definitely won't regret it.
Diana Kelley: Don't store SAD.
Ed Moyle: Yes, don't store SAD, that's important too.
Eric Parizo: Alright, great presentation Diana and Ed. Thank you both so much.
Time now for our Q&A segment. Diana and Ed, a few follow up
questions for you. In regard to 3.4, or appendix B, compensating
control, is one better than the other? What should people be
thinking about when putting together strategy for encrypting
Diana Kelley: Appendix B appeared in 1.1 in large part because a lot of
retailers and merchants said that it would be too difficult for
them to encrypt the data in the database, and not difficult in
that they don't know how to do it, but there was concern about
performance on the database, the architecture on the application
would have made it challenging for them. So Appendix B came out
with the compensating controls. To Ed's point, very often
compensating controls are a stop gap, rather than a control that
you want to end up with. Looking at 3.4, this is very much about
the primary account number. With that, you either want to get to
a point where you're storing only a portion of the primary
account number, such as a truncated piece of it, or you are
protecting it with the encryption that's recommended in 3.4. But
if you need to again take that journey to it, then the Appendix
B compensating controls are the way that you can actually get a
level of protection now.
Eric Parizo: Next question, let's put you on zoning again briefly. How separated
do the zones need to be? Do we need physically separated data
centers, or are VLANs enough?
Ed Moyle: I would say as separated as your QSA will accept. I'm kidding.
Basically, what you want is a strategy for zoning and separation
that your QSA is on board with. So for example, if you say,
"They're on different VLANs," that's separate. Well, if your QSA
agrees with that, that that's separate enough, then that works.
But if they don't, that's an issue. So the instate of that is,
vet it past your QSA, make sure that they agree with you that
whatever strategy it is that you use, Diana went through and
listed a number of different technologies that you can use to
establish that zoning. Just make sure that whatever technology
it is that you use, the QSA who is actually performing the
assessment for you agrees to that.
Now, if you don't have the luxury of doing that, if for example,
you're preparing six or eight months ahead of time and you don't
have access to your QSA ahead of time to ask them that, whatever
it is that you choose, go through your typical risk assessment
process, your typical risk analysis, analyze what you think the
risk associated with putting a particular technology will be,
and document why you think it is that your strategy is
sufficient. Even if it is something that we as security folks
might feel is weak, sometimes that's the reality. Just document
why you think that's sufficient. Most of the time, if you've
thought about it ahead of time and you've documented it,
generally you know your own environment better than someone from
the outside would, so they'll tend to defer to your analysis.
Eric Parizo: Another question regarding 6.1, the new security patches getting done
within 30 days. It doesn't seem like nearly enough time for many
organizations. How should organizations go about dealing with
Diana Kelley: I have heard that from some admins, saying they need longer
than 30 days. I would say take a look at how you can streamline
the process for applying patches. I realize organizations do
need to do a thorough testing and vetting of those patches. Some
of the patches get patched. Organizations say they don't want
this patch on, they're not ready yet, and then you'll see the
vendor that put it out a couple days later issue a new patch. So
that is valid, but I really do think organizations should try to
streamline the testing and application process of those patches.
One thing that they can do is offer to look at what you can do.
If that patch is, for example, saying this port on this machine
is the reason that there is a vulnerability, does that port need
to be open? So looking at some of the specific compensating
controls, or could you block that port from the firewall, at
least from your external entities that can get to that
application or that server. Also look at the compensation
controls as well. Finally, maybe look at processes or systems
that could help them to, as I mentioned before, streamline the
patch testing and the application features themselves.
Eric Parizo: Just out of curiosity, in your experience, for companies that you see
go through that process, do you find there are areas in the
process where they can cut down on the time?
Diana Kelley: Yes, they can get a testing lab so it's easier for them to test
and they know it's in an essentially duplicated environment.
Another really good thing that we've mentioned a lot before, is
scope. If you've only got a number of applications that you need
to have in the DSS patch cycle response process, then you can
test those more quickly. Imagine if you had to test patches and
apply them in 30 days for every single system in the
organization. So again, this is a place where scoping can help
quite a bit.
Eric Parizo: Here's our final question. How do we know if a compensating control
is strong enough? What criteria does your organization use to
Ed Moyle: At the end of the day, what you should look at is the intent of the
original requirement. As security folks, there is a lot of
guidance that spell out in a lot of detail what the intention of
some of these requirements are. Good resources to use would be
ISO 27002, used to be 17799, but now 27002. If you refer back to
that, that has a lot of information about what some of the
underlying intent is for a lot of general security requirement.
So just look at what the intent is, look at what the strength or
rigor of that requirement is. Look to see what it is about that
requirement is that it is designed to prevent.
So in the case of 3.4, we talked about that a little bit, in the
case of encrypting of PANs, what is the point of that? The point
of that is to prevent folks who don't necessarily need to have
access to the PAN, keep the PAN away from them so they can't use
it to shop, so that it doesn't get leaked out and people's data
become compromised. So in that case, whatever control it is that
you put in place, make sure that it does the same thing. so in
the case of 3.4, make sure that it is designed to prevent folks
from getting access to that PAN. Make sure that the strength of
that control, that rigor, is equal to or greater than what was
originally defined within the standard.
If you do those things and you document why it is that you're
doing that, and you present that to your QSA as your
compensating control, I think you'll be in really good shape,
and I think you'd be hard pressed to find a QSA who would still
flunk you for that particular requirement.
Eric Parizo: Alright, that brings us to the end of today's webcast. Once again,
we'd like to thank Diana Kelley and Ed Moyle for joining. For
more information on PCI DSS be sure to read Diana Kelley's
exclusive companionship on PCI and web security via the link on
your screen. Be sure to check out the rest of the informative
content in SearchSecurity.com's compliance school, also view the
link on your screen, or at searchsecurity.com/complianceschool.
And to all of our listeners for joining us on this
searchsecurity.com webcast, I'm Eric Parizo. Stay safe out