*gulp* Where do I start? Complete newb thread.

[cbsteven]

Hi all,

I realize that the answers I seek are "out there", but honestly this PCI/DSS stuff is very overwhelming to me. I don't even know where to begin. So I guess I'll begin with this post and a little bit of background about our business, and look for comments.

This is a family business that my parents started 30 years ago. I am a techy kid and a computer science student, and about 6 years ago we started selling stuff from our store on eBay. Then we signed up with a website provider that specifically ties into our sporting goods industry. They offered the ability to have a catalog tied in real-time to our wholesalers inventory, so we could have a website full of products with no upkeep on our part.

That took off, and we abandoned eBay. As it grew, I would make adjustments to how we did things to accommodate the volume of business.

I built a home-made database using FileMaker to hold order information. The DB downloads order data, including CC#s, via XML, and populates the forms on a computer in our brick & mortar shop. At first, we would punch CC#s in manually to our terminal at the front counter, but eventually we signed up with Authorize.net. Our filemaker database communicates transaction information with Authorize.net via https, then we ship.

That brings us up to present day. Our website provider is working on their own PCI compliance issues, so they should be fine. The problem is the downloading and storing of CC data into our filemaker database. Filemaker (version 6.5) is pretty similar to Microsoft Access. User friendly but pretty powerful. But I doubt that it would pass any security tests. While access to the DB is password protected, I believe the files themselves are stored in plain text.

I really don't even know where I would begin to find out my next step. Any advice would be very much appreciated. I've never faced a problem like this where if it isn't resolved we would face thousands of dollars in fines. My parents rely on me to solve any aspects of the business that involve technology. I found the PCi website and poked around, but it really seems geared toward security professionals.

Maybe the solution would be to replace FileMaker with a different DBA which is more secure? Maybe it would be to delete credit card numbers from our DB after we ship? I recently deletes all card numbers that are more than 6 months old, to at least limit our exposure.

I assume that our real security problem is physical in-person stuff. Swiping our computer or the external back up drive. There may be exposure via the network, although changing that would be less intrusive than having to abandon our in-house software we've been relying on for years.

Anyone at least point me in the right direction? :)
Thank you!

PS. I'm not sure exactly how to define what level we are either. We ship 15,000-20,000 orders per year that would be ecommerce. Probably another 5,000-10,000/year in our brick & mortar.

[sm1978]

the challenge ahead of you but that's why there are forums like this.

First off, because you are a merchant you should be contacting your merchant bank to help you through the process. Your merchant bank would be the one who acquires the payments you are sending through authorize.net and into your merchant account, as well if its different the merchant bank who acquires for your brick & mortar.

About your database, it's important you understand why you are keeping full account numbers to begin with. If this is for chargeback protection, you do not need this, contact your merchant bank, many of them only need the last 4 digits. The more data you don't need, the less you'll need to worry about.

You will need to still secure your environment to PCI DSS requirements. Look through the standard, and dig around the pci security standards website, they have self assessment questionnaires that can help you define what areas of the DSS that would be the most pertinent to you.

As for the actual changes you'll need to make, well this is a large question and cannot be answered simply with X requirements, you need to look at where your card data is flowing, what data is stored, processed or transmitted and what protections you have in place, if there are gaps you need to focus on those areas. There are hundreds of security professionals who can help you... first step call your merchant bank they have resources they may be able to guide you through the process.

Hope that helps !

[cmark]

If you are using A.net you likely have an ISO as your acquirer and not a merchant bank. I suspect you will have a number of challenges getting reliable info out of such companies.

What you describe is a very common situation and exposes your company to significant risk. The fines associated with non-compliance are not very problematic as none of the major card brands are currently chasing level 3 merchants. The more immediate risk is the lose of such data.

I am returning from Asia on Monday and my company (who runs this forum and trains QSAs) can provide some info for you but I need to understand more about your business (ie. type of merchant, type of POI required etc.) if you want to coordinate a time to speak, shoot me a private message with your info and I will try to help you out..

[cbsteven]

Thanks for the notes, a couple thoughts off the top of my head:

- What are a POI and an ISO?
- We selected Wells Fargo as our Authorize.net bank/reseller/whathaveyou, since it was the only company that we'd actually heard of before on the list. Not sure if they have anything to do with DSS or if it is all in Authorize.net's court.
- The point on why we are storing full numbers is well taken. Perhaps the solution lies in not completely changing our software set up in the shop, but the flow of information. We had been keeping numbers for a couple reasons:
a. To process return credits if a return occurred in the order
b. For convenience if a customer re-order via phone.

Obviously (b) is not worth sticking our neck out over. As for (a), maybe Authorize.net does require the CC# for a return credit, maybe just a reference number. I honestly don't know, definitely worth investigating.

But even if we drastically reduce the amount of time we store numbers, I can't see it ever reaching 0. We would still be storing it for a few hours or days (either from the time the order came in til the time it shipped, or until the time we made a pre-auth charge).
I assume from the strictness of these standards that it doesn't matter if we are storing numbers for minutes or days or weeks or years, we still have to have the same level of security. Is this true?

[EPCHK]

ISO is "Independent Sales Organization". Put simply the re-sell acquiring services.

POI is "Point of Initialization" for the payment transaction.

As I understand things, you are correct. If you store the CC# even very temporarily you need to securely encrypt it.

[sm1978]

as though Wells Fargo is your acquiring bank. Although an Independent Sales Organization (ISO) may have sold you the device and/or merchant accounts, they work with acquiring banks to sign you up. So, call your acquiring bank, not your ISO. Wells Fargo can definitely help you with PCI DSS, so before you shop around for a security professional seek the tools, resources and guidance from your acquirer as to their strict requirements to prove you are in compliance.

Finally, you can store the account number prior to sending an authorization message. Most of the card brands have varying degrees to what is considered an acceptable amount of time pre-auth to store the mag-stripe or cvv2 values encrypted/protected. Storing the account number is allowed but it has to be made 'unreadable'...most practically encrypted. Once you have an authorization done you cannot store the mag-stripe or cvv2 values, you can store the account number but protected. Again seek the guidance of your acquiring bank.

[cbsteven]

I had come to the conclusion over the weekend that removing the burden of compliance would be the path of least resistance. Our web provider, which uses Securecart.net as the shopping cart provider, has its own option for integration with Authorize.net. We have never used it, and elected to work with Authorize.net directly for better control. I am investigating how this would work, but I believe this way Securecart.net would automatically run a pre_auth transaction when the order is submitted. I would then download the transaction results in the XML feed to my database. When I go to ship, I believe I can just use the transaction ID to trigger a capture transaction on the pre_authed amount. This would eliminate storage of full card numbers of website orders. They would just be stored by our web provider, which is doing their own compliance work.
Two issues remain that I can think of though:
1. The XML feed we use to download orders would still contain full card numbers. But instead of storing it in our database, we would just ignore it. I suspect this still may trigger some compliance issues, though (transporting).

2. We get a lot of people that don't like to type credit card numbers on a website and instead prefer to call in their orders, so we still have to store them in a local database. Unless I can think of some creative way to avoid storing them, this means I'd still have to do the security upgrades on our in-house database that we would if we were storing full credit card numbers from website transactions.

Just kinda thinking out loud here, but if you have any comments on this, I am trying to devour any information on can on the subject right now.

[EPCHK]

I had come to the conclusion over the weekend that removing the burden of compliance would be the path of least resistance.

You can't completely remove your burden but you can certainly reduce it significantly. You would still be left with, at least, managing contracts. Requirement 12.8 talks about this, "If cardholder data is shared with service providers, then ..."

... Two issues remain that I can think of though:
1. The XML feed we use to download orders would still contain full card numbers. But instead of storing it in our database, we would just ignore it. I suspect this still may trigger some compliance issues, though (transporting).

2. We get a lot of people that don't like to type credit card numbers on a website and instead prefer to call in their orders, so we still have to store them in a local database. Unless I can think of some creative way to avoid storing them, this means I'd still have to do the security upgrades on our in-house database that we would if we were storing full credit card numbers from website transactions.

For number 1, check with Securecart (or Authorize.net). Some web payment services can be configured to not send you the CC#. Otherwise you are right, you still have to deal with what you do with the XML file when you receive it.

As for number 2, you could have your staff fill in the web form for the customer that calls in. This could be done through an internal only web server (or other application) that feeds into the same Authorize.net service you use on the web site. Again, ask them. They might already have something suitable.

[darryl]

Give more details please?
Thanks for the nice collection of this posts.!!!
This is really good information....
Good luck!

[manukabay]

I had come to the conclusion over the weekend that removing the burden of compliance would be the path of least resistance. Our web provider, which uses Securecart.net as the shopping cart provider, has its own option for integration with Authorize.net. We have never used it, and elected to work with Authorize.net directly for better control. I am investigating how this would work, but I believe this way Securecart.net would automatically run a pre_auth transaction when the order is submitted. I would then download the transaction results in the XML feed to my database. When I go to ship, I believe I can just use the transaction ID to trigger a capture transaction on the pre_authed amount. This would eliminate storage of full card numbers of website orders.

You are correct. Authorize.Net only requires the transaction id to capture a transaction. The card number is not required. You are definitely going down the right track by not storing card numbers. It will greatly simplify your compliance probably moving you down from SAQ D to SAQ C.

They would just be stored by our web provider, which is doing their own compliance work.
Make sure that is true. Get it in writing - ask for their QSA Report on Compliance. Make sure your contract with them says they will remain PCI compliant.

Two issues remain that I can think of though:
1. The XML feed we use to download orders would still contain full card numbers. But instead of storing it in our database, we would just ignore it. I suspect this still may trigger some compliance issues, though (transporting).

You are probably going to get stuck with transmitting card numbers anyway because of the phone orders. That said you should still minimize the card numbers that get into your local environment. If Securecart.net can't give you a download file without the card numbers you should find another provider to handle your web site.


2. We get a lot of people that don't like to type credit card numbers on a website and instead prefer to call in their orders, so we still have to store them in a local database. Unless I can think of some creative way to avoid storing them, this means I'd still have to do the security upgrades on our in-house database that we would if we were storing full credit card numbers from website transactions.

You have a couple of options here. You could use the Authorize.Net virtual terminal to charge the card while the customer is on the phone and not store the number. Or you could get a standalone card terminal to key in the card number to charge the card while the customer is on the phone. Or you could write your own interface to Authorize.Net to authorize the card when entering the order and not store the card number. Then you can capture the payment later like you do with web download orders.

[creditcardsonline101.com]

Here's my two cents although it appears that you have lots of input. My contribution is that I'm pretty much like you: a small business owner who is trying to stay on top of how to take payment issues.

Unless you have a real IT person and want to create a very secure environment, I would suggest that you set up your shopping cart/website so that the credit card number goes directly to your merchant account vendor/ISO and that you only take the last few digits and expiration date into your own database.

There are oodles of combinations of banks and ISO (authorized independent sales agents) that want to be your processor. Rates vary dramatically. They will want info like your sales volume and average sales size to give you quotes. Switching is a pain but sometimes, you need to to keep your rates low. My overall credit card processing rate expense is around 3% of sales but that's because my individual order size is tiny.

When you get repeat orders, you should not require your customers to submit their credit card unless it's expired. There is some clever coding required here. You should make this part of your deal with a vendor that they'll help you get this all done.

Good luck.