Clarification and Scoping

[exzactly]

Right now we do process credit cards, however not online. Customers call in and give credit card information to users who then submit them via an internal application to the payment processors (auth.net and paypal). They have operated this way for years, yet no one is knocking down the door (from the outside) for us to be PCI compliant. We do fall within the category of a Level 3 merchant, so my take is we have to achieve compliance. A new project is in the works to move to a outside (web) payment portal. In this case obviously we would have to achieve compliance. My understanding of the standard is that any systems that transmit, store and/or process CC transactions must be compliant. Any systems that connect to those systems must be compliant. If I am wrong here please correct me. So my questions are these:

Does a merchant who doesn't process transactions via the web need to be compliant (I believe this is a yes)

When will someone contact us about submitting our scans and SAQ? (No one outside of myself has even brought up PCI compliance and our processors and bank have yet to address it)

If every system that connects to the system storing and or transmitting CC info must be compliant does that mean I have to make all PC's switches routers etc that make up the infastructure PCI compliant, or can you logically separate out the network so that your only spending resources and money on the systems that actually do the transmitting and storage?

In the SAQ there are about 200 requirements under the twelve sections, must all of those be met, or can you still be compliant and not meet all of those criteria?

If so who determines that your compliant when all the answers are not a yes.



Any help would be greatly appreciated. Thanks

[wconway]

So my questions are these:

Does a merchant who doesn't process transactions via the web need to be compliant (I believe this is a yes)

When will someone contact us about submitting our scans and SAQ? (No one outside of myself has even brought up PCI compliance and our processors and bank have yet to address it)

If every system that connects to the system storing and or transmitting CC info must be compliant does that mean I have to make all PC's switches routers etc that make up the infastructure PCI compliant, or can you logically separate out the network so that your only spending resources and money on the systems that actually do the transmitting and storage?

In the SAQ there are about 200 requirements under the twelve sections, must all of those be met, or can you still be compliant and not meet all of those criteria?

If so who determines that your compliant when all the answers are not a yes.

Let me give this a shot. Yes, PCI covers all card transactions not just e-commerce so even if you use dial-up POS devices, you need to be compliant.

It is disappointing that your bank/acquirer hasn't contacted you about this, but it's not surprising. You seem to have fallen between the cracks, but that is no reason not to achieve compliance. You might want to call your contact and try and get through to a compliance officer for help.

Your PCI scope could include all the devices you describe, so the idea is to minimize your cardholder data environment. Good segmentation and maybe some changes in your business practices can go a long way to simplifying compliance for you.

Yes, you need to meet the entire Standard, but the "200 requirements" you mention is only SAQ D; there are three others and they are much simpler. Again, if you can minimize your scope you also will minimize your compliance effort. Based on what you have described, I'd at least aim to fall under SAQ C. Make sure your outsourced provider is compliant, though.

Lastly, once you get to "yes" and validate your compliance, your acquirer (you know...the one who isn't talking to you...) will accept/certify your compliance.

[exzactly]

Thanks for the response this does help, as a follow-up I am looking at the SAQ versions right now, and I don't believe C is the right category. We do in fact store the information (albeit in an encrypted format) however we do not have a true POS system if you will. What we have is a system that users put the CC information into, that then submits them for processing. I guess it could be considered a POS, but it's more of an encompassing system. In this system there is CRM information, information about every customer and where they are in their progress. Essentially its the core of our business. Since all cardholder data functions are not outsourced completely, wouldn't this make us a Type D shop?

As far as strategy goes, I am pushing to eliminate the storage of this information. I am unsure how folks go about doing that with recurring payments, but maybe someone on here can put some options out here.

So if we are in fact held to the SAQ D version, we would then have to achieve compliance in all of those areas correct?

How would one go about doing this without making every single system on their network compliant, when the same system that stores CC information is at the heart of your business and all 2000 plus users log into certain parts of it.

Again thanks for all the help so far, and it's nice to finally find a place to go back and forth with people on PCI, in my opinion they have done a poor job educating us security guys who are now stuck with this regulation as to what applies what doesn't etc etc etc ....

[El_Luke]

If you can prevent all traffic except what is needed to the cardholder data storing server, you may be able to remove the regular user workstations and other networks from scope.

If we can get more specific about your server with cardholder data, we may be able figure out an acceptable solution. You say its a CRM server. If people access it via a web browser and nothing else, first thing you do is put a firewall up and block everything to CRM except http(s). Next you want to make sure that logical access to cardholder data inside the CRM app is limited. Generally, if a few people need to be able to see individual card numbers, that is not a big deal. It gets to be a big deal if everyone in the company can access cardholder data or can access many card numbers at once.

[wconway]

As far as strategy goes, I am pushing to eliminate the storage of this information. I am unsure how folks go about doing that with recurring payments, but maybe someone on here can put some options out here.

Again thanks for all the help so far, and it's nice to finally find a place to go back and forth with people on PCI, in my opinion they have done a poor job educating us security guys who are now stuck with this regulation as to what applies what doesn't etc etc etc ....

I would support your idea to eliminate storing CHD. This could reduce your scope significantly. It also is the best place to start. Personally, I think looking at how and where you process payments is the first step in compliance: if you don't need it, don't keep it.

As for education, Visa offers a 2-day PCI course, and definitely check out the SPSP's CPISM/A training...it's excellent, and you even get to put even more initials after your name. ;-)

[exzactly]

Thanks again everyone!!!

The system at an application level is restricted based on your role. As an example only folks in a certain group have access to input CC info. This group is restricted and there is an approval process in place that users would have to go through to gain access. We do have FW's at the edge, however since everyone needs to access the server (it's via http access) for various functions, would it make sense to install a FW in front of the application? Couldn't the same be accomplished by an ACL that only allows port 80 traffic from our end users? Or since it's PCI it has to be a FW? I hope that adds a little more information.

[sam40]

PA-DSS is a security standard set for payment application developers, outlining security and auditing procedures for electronic payment applications. Software that falls under the PA-DSS envelope could include anything from a POS system to online shopping cart software.