The impact of PCI compliance on the channel

As a security solution provider, there's no doubt that you realize PCI is a big deal from a customer's perspective. But did you know that PCI outlines some requirements that are specific to solution providers?

Ed Moyle, founder of Security Curve, will outline how to approach PCI compliance for your own business, as well as your customers' businesses.

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.

The PCI compliance guide is a resource for security solution providers. It covers everything security solution providers need to know about PCI compliance, with tips, podcasts and videos.

 


Read the full transcript from this video below:

The impact of PCI compliance on the channel

Nicole D'Amour: Hello, and welcome to the SearchSecurityChannel.com webcast, "The impact of PCI compliance in the channel with Ed Moyle." I'm Nicole D'Amour. As a security solution provider, there's no doubt that you realize PCI is a big deal from a customer's perspective.

PCI also outlines some requirements that are specific to solution providers. Ed will outline how to approach PCI compliance for your own business, as well as your customers' businesses. He'll also discuss Appendix A of the standard, which is specific to solution providers.

He will outline these PCI requirements that you need to know about and explain some steps to take to meet them. Ed is a manager with CTG's Information Security Solutions Practice, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner of Security Curve.

Prior to joining Security Curve, he was vice president and information security officer for Merrill Lynch Investment Managers, where he was responsible for coordinating all aspects of information security within the business unit.

Thanks for joining us today, Ed. I'll let you take it away.

Ed Moyle: Thank you. As Nicole outlined, there are some specific requirements within PCI DSS that are unique to hosting providers for us in the channel. [I'm] just going to walk through what some of those are and hopefully give folks an idea of how best to approach them and what your customers might be looking for.

Just quickly from an agenda perspective, I  briefly want to introduce the topic of PCI, talk a little bit about the impact on the channel, and this is something that a lot of folks out there in the field are going to be familiar with already, I think.

[There will be] just a little bit of that level set at impact because obviously, this is something that your customers are demanding, something that they're coming to you with. I'll try to keep that as introductory as possible and move directly on to the specifics of what applies to you, what your customers might be asking you for and some strategies of how to respond to them.

That, in brief, is what we're going to be talking through, so let's just leap right in and talk a little bit about PCI.

From an introduction standpoint, obviously, PCI needs no introduction. It's [had] a huge impact [on] the security industry and a huge impact [on] the services that we provide in the channel.

Basically, what is it? It's the Payment Card Industry -- that's the PCI part. Then the Data Security Standard -- that's the DSS part. Specifically, [it] is a set of requirements that outline a minimum protection for credit card data, for cardholder information.

A merchant, or a service provider, or somebody who's involved in the card transaction flow … needs to adhere to these requirements. Again, it is a minimum baseline. It does apply to all entities in the payment process, so what does that mean?

That means that if you store, process, transmit credit card information, either because you're a merchant and you're actually accepting payments from folks, or if you're a service provider who is hosting services on behalf of merchants, or even of other service providers. Then in that case, the requirements apply to you as well.

Where can you get these standards to get more information?

If you go to the PCI Security Standards Council website … on that site, [there are] downloadable versions of the PCI DSS that you can go to and see.

You might want to do that, particularly if you're in the channel, if you're providing services to folks who are regulated by this requirement. This is something that you'd probably want to do. Take a look at those requirements.

So just moving on to the next slide: "Where does PCI impact you?"

Again, as we outlined, it's any system that stores, processes or transmits the credit card data. This could be your customers, obviously the machines that are in their environment that are doing these things -- that's going to impact them at that point.

As a service provider, if our customers are outsourcing any part of that environment to us, then those would be in scope as well.

Particularly useful to note because of the fact that we don't always [necessarily] know, in the channel … what our customers are giving us access to. They might be hosting credit card data within our infrastructure, within services that we provide to them, and we might not always know.

It's very much something that we need to be alert for in our processes.

What a lot of folks don't realize … is that when you look at what the PCI DSS actually says about the scope of compliance, not only does it apply to the systems that actually do the storing and the processing and the transmitting, but it also applies to the other systems that you might have in your environment that aren't segregated, that aren't scoped out from the systems that actually do it.

For example, if you have a payment server that's hosted within your infrastructure and you have another system next to it, then there's no firewall, there's no logical segmentation or segregation there; you're going to have both of those systems be in scope of compliance.

Again, this is spelled out in the requirements themselves. If you go to PCISecurityStandards.org and take a look at the documentation that they have available, if you're actually looking at the PCI DSS itself, it's pages 4-6 … where they talk about scope.

So that's really useful to take a look at. Taken all together, both of those systems that do the processing, storing and transmitting, as well as the connected systems, all together that's called The Cardholder Data Environment, or CDE. That's useful terminology to know as you approach the scope of the requirements.

Moving on: What's the impact to us if we're providing a service, if we're providing hosting capability, if we're providing something to our customers that might be within the scope of their cardholder processing or their payment infrastructure? First of all, we have to be compliant as well.

If we are doing the storing, the processing and the transmitting, then we have to be receptive to a compliance of these requirements. If we have a relationship with an acquirer, for example, if we're in the business of accepting credit card payments, we have our own compliance scope to worry about, because we're directly in the process.

From the standpoint of the [PCI Security Standards Council], the standpoint of the folks who actually write these regulations, we're just like any other merchant because we are accepting credit cards. We need to comply, and we're going to have our own scope, our own cardholder data environment. That's sort of the No. 1 impact. That sort of puts us in the same boat as our customers, right?

We also have a broader scope that impacts us, which is No. 2 on the slide: "Our customers are actually looking to us to help them meet their compliance requirements."

If they're outsourcing to us, if they're using services that we provide, if they're sharing their data with us, they have a requirement to -- and also an expectation that we're going to -- follow these requirements.

That we're going to do the additional things that are required in the standard for folks who are in our line of business.

Like any other kind of regulation, obviously, when it's their priority, it becomes our priority just because of where we are in the chain and the services that we provide.

Really, this discussion is about this No. 2. This second part: "How do we facilitate our customers' compliance efforts?" Keep in mind No. 1 -- our own compliance efforts and the specifics of how we meet the requirement -- is useful as well for us to know about.

In some firms, depending on the size of the organization and the size of the service provider, there might be different teams that are responsible for 1 and 2. Like we might be in the team that responds to customer inquiries, but be advised that there's also probably another part of the organization that -- particularly in a large vendor -- [with] folks who are concentrating on this No. 1.

It is very useful for there to be communication between the two because a lot of the time, one set of controls can be used to meet both sets of requirements. It's just useful to think about. Of course in the smaller shops, it's going to be the same people who are working with both sets of requirements.

As far as specifically within your product, looking at how your product might put you into scope for your customers' cardholder data environment, the first question you sort of have to ask yourself is, "What is it that you're doing on behalf of your customers?"

If you're actually in their chain, if you're actually in their payment life cycle -- if you're doing the storing of credit card data, you're doing the processing of credit card data, you're transmitting it on their behalf -- then your customers are specifically mandated, specifically required within the actual DSS itself, and we'll talk a little about what it says and where that is in a minute.

They're actually going to be required to track your compliance to the DSS. They're going to be looking to you to provide documentation to them that you are, in fact, compliant with the requirement. In a lot of cases, depending on how far your customers are into their own compliance process, they might actually be looking for you to sign off on some language contractually that you're going to need to adhere to those requirements as well. That's useful to know.

We also get a lot of questions from people who make tools. Folks, for example, who make file transfer tools, and they say, "We don't really know if our customers are using our tool to transmit their credit card data or not. They could be.

"Maybe we make something on the order of a product like FTP … in that case, would it be our responsibility to go and follow the whole compliance process for it?"

Not necessarily. We might need to do that, if our customers come to us and say, "We're using your product to move our credit card data around." Then the scope of their compliance is going to apply to your tool, and they're going to be looking for some information about it.

But they're not necessarily going to be looking for you to get certified or go through any kind of compliance process or anything like that. They're really just going to be looking to figure out -- the way that they use that tool -- what impact does that have to their compliance? And not necessarily looking for anything from you in particular.

Again, that's just for a data-agnostic tool and not necessarily for a service provider. It's useful to understand what service it is that you provide to your customers ahead of time.

It sort of goes without saying, but sometimes, particularly in a larger shop where there's a lot of different services that are being provided, obviously understanding the nitty gritty of each and every one is not something that's always feasible [and] it's  not something that comes easily.

This is something really good to know and really good to put on paper too, I think.

Moving on past that, the scope that our clients have within their cardholder data environment is going to impact us. A good example of this is, if they have a very large flat network that doesn't have any kind of segmentation internally, what you can have happen is, the actual machines that do the storing, processing and transmitting of the credit card information can actually not be segregated from where they're making use of our tool. Or making use of our service, or making use of our product, or outsourcing data to us or whatever the relationship might be. When that happens, by virtue of the fact that they haven't built those walls internally, their cardholder data can start to expand to us.

Even though we might provide a facility to a client that has nothing to do with credit card information and they come to us and say, "Hey, we really need to learn about the security controls within our application or within our service," because of their PCI compliance, that could be what's going on.

It could be that they haven't scoped internally. They're taking the all-or-nothing approach, where they're just assuming that everything on their network is in scope for their CDE, and they're moving through that.

Realistically, what does that mean? For a lot of firms, we're going to be in scope for their compliance efforts. Why? It's the path of least resistance for them. Most organizations, out of the gate, most of our clients -- well, I won't say most -- I'll say a lot of our clients going out of the gate are going to assume that their entire network is within their cardholder data environment.

They're going to pursue the path of either validating or self-assessing for their whole environment, which definitely brings us into the loop.

Moving on to the next slide, as far as what we need to do to address these requirements, there's sort of an easy part and a hard part. The easy part is, just like a customer, just like somebody who's regulated under these requirements, we have to specifically look at the requirements, address them, implement the minimum baseline controls and everything to the data security standard. It doesn't sound easy, but it's actually easier than the harder part, which we'll get to in just a second.

That's basically the same exercise that any of our customers might have to go through, the same exercise that any type of entity that's involved in the payment process would have to go through. It's basically just making sure that we are complying with the requirement.

Keep in mind that, as Nicole alluded to in the introduction, there are additional requirements over and above what's required just for a customer or what would be required for somebody who was not in the business that we are, that we have to adhere to as well.

These are, No. 1, additional requirements that actually in some cases -- depending on how you look at it -- makes it harder for us to comply than it would if we were a customer. It's kind of counter-intuitive, right?

We might be providing a service that doesn't have anything to do really with credit card payment, but yet the compliance effort required from us is actually harder than it would be for our customers.

When you take a look at why that is, it actually makes sense, but it's a little bit hard for folks to get their head around -- at least at first, when they enter into this process.

Let's talk a little bit about what that is. Moving on to the next slide, the PCI itself, the Data Security Standards, they're very clear. They're very prescriptive, and by prescriptive what that means is, they outline with a high degree of specificity what it is that we need to do from a technical standpoint in order to comply.

A requirement like HIPAA can be very vague; it might say things like "appropriate technical safeguards." That doesn't really tell us what we need to do. But if you look at PCI, the actual requirements themselves are very specific about what we need to do from a technical standpoint.

It says things like, "Have intrusion detection." It's not "appropriate technical controls" or something like that. It's, "Have intrusion detection" or "Have antivirus software."

The reason for that … makes a lot of sense. A lot of folks in the merchant community, when these were coming out, said, "Hey, look, we might not have the same kind of technical expertise that a bank or somebody who's highly regulated by that, so please make it clear to us. Tell us what we need to do." It's written to do that. It's written to be very specific about what … you have to do in order to comply, which is a good thing.

If you look at specifically how that applies to service providers, at least from the standpoint of the services that we provide, if you look at 12.8 of the standard in the sub-requirements, that's really where the meat of this is. This is where it tells the folks who are our customers what they need to do in order to get us to implement the appropriate controls.

It says, "If cardholder data is shared with service providers, then maintain and implement policies and procedures to manage those service providers, including … ." And there's a number of specific things under 12.8 that they're required to do, including tracking our compliance status, including having appropriate language within the contract to require that we adhere and so forth.

When I said earlier that they were going to be looking for us to follow those requirements, this is why. This 12.8 requirement is where it's spelled out for them that they need to lean on us to make sure that we're compliant.

Also, 2.4 talks about this a little bit: "Shared hosting providers must protect each entity's hosted environment cardholder data." Again, these are the specific requirements that you're going to want to look to. You can read it in the actual DSS itself.

There's also another useful document that's on PCISecurityStandards.org, which is called "Navigating the PCI SSC: Understanding the intent of the requirements." If you actually go and pull down that document, I think the most recent version of that document may be 1.l, and there's a 1.2 of the actual DSS itself.

Either way, they didn't change all that much between 1.1 and 1.2, so it's useful to take a look at it, even if the most current version is the 1.1 -- the "understanding the intent of the requirements" document. Again, a good resource to take a look at.

Specifically, the additional, those over-and-above requirements that I was talking about are outlined in Appendix A.

Appendix A is the specific additional PSS requirements for shared hosting providers. Now it says "Shared hosting providers"; basically, what that means is, anybody who is involved in providing these services that impact the cardholder data environment within the customers.

It could be a traditional hosting provider like we think of a hosting provider, but it could also be somebody who's providing other application-type services in addition to just flat-out hosting. So, again, useful to keep in mind. These are over and above the baseline requirements. They're not instead of the baseline requirement. Some folks read this and they say, "I'm in compliance with Appendix A, so I don't have to do all this other stuff." No, that's not the way it is. Not only do you have to do all the other stuff, but you also have to do these additional requirements. This does catch a lot of people by surprise.

Let's look at why these requirements are in there. Why are there additional requirements for shared hosting providers or service providers?

If you think about it, say hypothetically you're providing Web hosting and you have 10 servers that are shared [among] most customers. … You need to make sure that customer A can't get access to and control the website of customer B.

That's just Service Provider 101: to make sure that your customers can only get access to what is within the scope of their arrangement with you and not somebody else's information or somebody else's environment.

That's really what Appendix A is about mostly. It's mostly about ensuring that there's separation between customers. If you have a contract with … Applebee's on the one hand, and you have a relationship with Friday's on the other hand, those two [must be] separate and distinct.

Applebee's can't get to the other information, and vice versa.

In addition to that, it also talks about requirements for being able to support forensic investigation on behalf of your customers. For example, [if] somebody gets -- heaven forbid -- a breach, you need to be able to support a forensic investigation of that, to be able to say, “We're going to make available the information to you such that we can be able to investigate that, or so that you can investigate that.”

Or to be able to provide records and so forth that would support a forensic investigation. Again, it makes a lot of sense when you think about it because this is something outside of their environment.

It's something that you're providing to them, so they need to be able to make sure that if there was an incident, they can get to the data that they need. It makes a lot of sense why they do that.

Just as a quick … outline of what some of those requirements are that are specifically outlined in Appendix A: [There's] A1.1: make sure that each entity only runs processes that have access to that entity's cardholder data environment. What that means is, you want to make sure that individual organizations that you support … run [only] processes [that] impact their own environment. They can't extend to somebody else's environment.

If, for example, they're going to run a "find" or they're going to run some kind of application on a box that is within the scope of your environment, this requirement requires you to limit the scope of that only to that particular organization's or client's own data.

A1.2: Make sure that you restrict each entity's access and privileges to their own cardholder data environment only, and not be able to reach outside for them to have access and privileges to somebody else's cardholder data environment as well.

This can be a little bit difficult to enforce. … That cardholder data environment is where the actual storing, processing and transmitting of cardholder data happens, and any systems that are not segregated from it.

Read A1.2 very much in the light of the scoping requirements that are outlined on pages 4 through 6 of the standard. In order to enforce that separation from the cardholder environment, the real response to that is some kind of segmentation.

This might not be something that we have in place today from a service provider or hosting provider perspective, but it is something that your customers are going to be looking for. It does behoove you to address it sooner rather than later.

A1.3. Kind of a no-brainer … "Ensure logging and audit trails are enabled and unique to each entity's cardholder data environment."

Basically what that means is … No. 1, you don't want to have logging and auditing turned off. That would, of course, be very much out of the question.

No. 2, you want to make sure that the logging and auditing is unique to the actual cardholder data environment of each client. If you have a bunch of clients that are being hosted, you need to be able to produce the logs and the auditing for just that client and not a sum of all different clients.

This [is] something that you probably looked at already for other purposes, but maybe not for PCI. It's useful to take a look there as well.

A1.4: This is again that forensic investigation component that we were talking about. The actual text is, "Enable processes to provide for timely forensic investigation in the event of a compromise." Basically what that means is [that] you need to be able to respond to your customers if there is some kind of breach.

A good example of this would be a notification process between you and your customer where your customer can reach out to you to initiate a response, [and] you'll support them from a forensic investigation perspective, and so forth.

If you look at a default case, in an unregulated type of environment, this kind of thing can be very difficult to do. The client might have some breach, they reach out to maybe a relationship manager. Maybe that relationship manager doesn't know who in the organization to talk to about forensic investigation. There can be a period of time that elapses while valuable information is being destroyed on that box.

From … a further nefarious activity perspective that's going on in that box all the while and you want to circumvent that. You want to be able to have a very rapid response that you support for your customers in the event of a breach. So that's really the intent of that.

Again, they shouldn't be rocket science. They should be things that you've probably thought about in other contexts. You've probably answered questionnaires and responded to customer inquiry and maybe even walked some auditors -- customer auditors -- through already, as far as the services that you provide.

Again, from a compliance perspective, in terms of what your customers are going to be asking you for, these are very much in scope.

As far as what your customers are going to be looking for from you … one common request that you'll get is somebody looking for you to validate to the PCI.

What does that mean? That typically means having an auditor or an assessor -- an individual called a QSA, or qualified security assessor -- come to your facility and assess your environment for PCI compliance.

When you go through that process, they're going to be creating a document called a Report on Compliance, or ROC, that is basically an outline of where you are and where you aren't compliant. If you actually do choose to go through this process, be prepared for not being fully compliant your first time around. There is some flexibility around compensated controls, but just some of the activities that have been going on from a QA perspective within the [PCI Security Standards Council] itself means that folks are very much looking for you to be compliant with the actual requirements as written. So there's not as much flexibility or wiggle room as there might have been in the past. If you haven't been through this process before, if you're going to go down this road, you definitely [should] do a pre-assessment. You definitely want to look at the requirements yourself, intelligently self-assess, and make sure that you know any gaps ahead of time so that you're prepared for how to respond to them when somebody comes on-site.

Your bigger clients are probably going to be looking for you to actually go through this process if you haven't done so. [Smaller customers] might be just looking for a document called an "attestation of compliance."

It's required for you to complete the attestation of compliance. Whether you are required to go through the compliance validation, because of your relationship with your acquirer or for other reasons, it's also required if you fill out a self-assessment questionnaire -- if you're required to self-assess.

The self-assessment questionnaire material is also available from the PCI Security Standards Council. … If you go to that, you'll see that there are four different types of self-assessment questionnaires, based on the specifics of what you do.

Definitely, take a look at that. … You'll see that no matter which one you download, there's going to be a page on there that says "attestation of compliance" that requires you to fill out and sign it. No matter what process you go down, you're going to get one of these attestation-of-compliance documents as an artifact of it.

A lot of your customers are going to be looking for you to provide that to them. Why? Again, because of the requirement in 12.8 for them to track your compliance, a lot of folks have interpreted that to mean, collect attestation-of-compliance documents from their vendors. That's why you would be required to provide that, or your customers might ask you for that.

Moving on to the next slide -- how you can reduce the impact -- obviously, a lot of folks who provide service to folks and a lot of the folks who are on this discussion right now are going to have a lot of familiarity with responding to things like the BITS FISAP [Financial Institution Shared Assessments Program] questionnaire or other types of standardized information gathering and so forth from their customers.

This is very much in that same type of vein. If you have gone through that process as far as the shared assessments model for other regulatory requirements, having an attestation or having a document ready to send ahead of time obviously cuts down the amount of your personnel's time that goes into responding to each and every request in an ad hoc manner.

For example, you're required to complete [the attestation] anyway for other reasons. It doesn't contain any sensitive information about your environment. It doesn't have any IP addresses on it. It doesn't have any kind of potentially sensitive information, so why not have that ready to send to your customers, assuming that they're going to ask for it eventually. That's a pretty good strategy to just have this ready to go.

Another good strategy … even if your customers aren't asking for it, [is to] consider going through the compliance validation requirement anyway. Even if you're not in the direct payment life cycle, even if you're not required to formally validate using a qualified security assessor, voluntarily going through this process and being able to provide that kind of information and assurance to your customers is in a lot of cases a competitive advantage.

I know this because as part of the work that I do, I am a QSA. (Actually, [in] full disclosure, my certification renewal is pending, so technically, according to the [PCI Security Standards Council] right now, I'm not a QSA. I have gone through that process, and it's coming.)

This is not a shill for trying to sell services to people. This is really something that I've observed companies doing in the field -- going through this process voluntarily. Why? So that they can advertise to their customers that this is something that they've gone through and something that they do.

Again, that's a little bit more common in circles of folks who actually provide direct payment support services, but I have seen it in other contexts as well, in the hosting provider context and other service provider context. [It's] a useful option to consider.

To summarize and wrap up, your customers do need you to comply with these requirements. They are over and above the actual PCI DSS itself, so your customers are going to be pressuring you or looking to you to assist. It really behooves you to be ready to respond to them when they come around.

Keep in mind, too, that if you respond to the questions in a way that's disorganized for a first run, that can reduce their confidence in your ability to comply generally. It does reduce their confidence in your service.

When you do respond, make sure you do so in an organized, effective way that really gets to the meat of what your customers are looking for. In most cases, that involves being as informed, if not more informed, of the requirements than your customers are themselves.

 

View All Videos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

MicroscopeUK

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchDataManagement

SearchBusinessAnalytics

Close