developing a PCI compliant web app

[dadamssg]

I'm desperately trying to understand how to develop a PCI compliant web app. I'm a PHP developer not a system admin or anything. I've recently discovered not all hosting companies are PCI compliant.

Can anyone shed some light on:

1.What hosting provider they recommend for becoming PCI compliant while using authorize.net. A lot of hosting providers are PCI compliant only with like paypal or google checkout. 

2. What needs to be done, coding wise, to become PCI compliant. 

3. Any companies they've used to assist in becoming PCI compiant and are satisfied in using or one's i should stay away.

4. How much is becoming PCI complaint going to cost me? I'm going to  be a level 4 merchant. (< 20,000 transactions a year). 

5. Anything else you think i should be aware of while on my quest to become PCI compiant.

The authorize.net API is great, i just want to make sure i'm PCI compliant when using it! I'd rather not get fined...

[WHeisenberg]

PCI compliance is a pain in the rear (short version).

There are a vast number of things that are required,  and most of them are server-side things (have nothing to do with your actual code).

Everything from making sure all non-essential ports are blocked; port 21 is one of them (so you have to change the port your FTP server/client uses),  to restricting IP addresses for remote administrative logins.  There are tons of things server-side.

Finding a hosting provider who is actually willing to do all that work can be a chore.   I've got a client who uses Hosting.com and I've found them to be very understanding when it comes to PCI issues, and they're pretty quick to get things secured when you ask them to.

As far as your own code,  having catch code set up on the site to stop URL-based hacking attempts,  setting default values to everything you can think of to keep from having database based errors, and either having your SSL set up correctly or using something like the Hosted CIM system here on AuthNet are a good start.

If you plan on either A.) actually storing credit card data in your own database, or B.) giving your customers a form on your site to input that information,  the PCI rules of engagement increase dramatically.

If you want to make sure you are PCI compliant and not get fired (grin),  just use the Hosted CIM system.

Dont store any credit card numbers of your customers.

Dont provide any forms on your own site for a customer to input their credit card information.

Doing it that way, technically,  there isn't even a reason to have an SSL certificate on your site.   All secure information is handled on the AuthNet server and the customer doesn't ever actually provide a way for 'you' (or a hacker) to get at that information.

When the PCI question is asked, "Do your customers input any credit card information on your site?"  you can answer 'No'.

When the question is asked, "Do you store your customer credit card information anywhere on your server?" you can answer 'No'.

Kind of makes the PCI-Compliance Squad have nothing to do :)

As far as cost is involved,  if you use the Hosted CIM system I think it's $20 a month.

CIM isn't for everyone,  because there are some things that don't seem to be fully integrated to actually use it (like automated recurring billing) if you're not capturing the credit card information on your system.   But for the basic "Just need to pay for an invoice" or "Just need to get money from the customers credit card/bank account to our merchant account" transactions,  CIM works.

Good Luck,

Wheis

[dadamssg]

thanks for the response! but the whole point of using authorize.net's AIM API is for user's to input their card info to process a payment. Inputing transactions in authorize.net's website isn't an option for my web app. 

[WHeisenberg]

I didn't know the extent of how far you'd developed your web app.   Since the CIM system wont work for you, then you're right - you'll be destined for PCI compliance hell (/sarcasm)

There are a lot of places out there that assist with PCI compliance.   I've never been in a position to want help from those sources (prefer to handle it all myself) so we set up with the Better Business Bureau.   They've got a system that will bounce a bunch of PCI Compliance tests across your web site.  If they discover issues, they give you a report on what they found, and even provide recommendations on how to fix the problems.   Plus you get the nice 'BBB' logo to put on your site when you've got it all PCI happy.

As I said before,  the vast majority of theissues we had were server related and not 'code on the page'.  We are using a virtual private server (VPS) system for our hosting,  so a lot of the fixes that had to be made I was able to do by just logging in to the server and fixing them myself.    Closing open ports and making sure the latest patches were installed to the SQL server were pretty simple.  Making sure the FTP server we were using (even though they made us change the default port for it) was up to date with the latest versions was easy too.

For the things I had no direct control or access to,  like restricting remote server login IP addresses,  I just had to contact the tech support staff at the host and they did that for me.

As far as the 'code on the page',  there were a few things that came up that I personally felt were of no worry,  but the PCI regs required some changes and/or additional code to be put on the pages.

Most of it was keeping would-be hackers from forcing errors on a page that ran database queries,  and then using that information to use the URL string to fire their own queries to get to our data.    Wasn't too hard to fix,  but if you've never done it before it could seem like an impossible task.

Other than that, the only real 'issues' that we ever came up with were things that the hosting company had to do for us.  They were things that basically had to be done 'at the keyboard connected to the actual server' and not through a remote login on a shared system.    Hosting.com were great at getting those fixes done quickly and correctly.

It costs a lot more for a VPS, or other hosting service with a support staff that is willing to help with PCI, than a simple shared hosting account that you can get for <$20 a month.  But when it comes to tech support,  and that support staffs' willingness and ability to help with PCI issues,  you kind of get what you pay for.

Again,  Good Luck,

WHeis

[dadamssg]

thanks again for the response. I have no experience at all with dealing with servers so i'm afraid i should seek out a place that will help in becoming PCI compliant if i want to be compliant anytime in the near future. I'm hoping i can find a hosting service that handles all the server side PCI compliance for me, as i'll have no clue what i'm doing. 

I'm beginning to really worry about the costs of everything. I'm a start-up with not a whole lotta money. I'm wondering if getting a PCI compliant hosting account is gonna break me. I can't find prices for these types of accounts which is scaring me... 

Apparently Authorize.net has partnered with Trustwave.com for PCI compiant web tools and validation. Sent them an email to find out more info. Hope they're fee's are reasonable. 

I need someone to hold my hand throughout the process and tell me upfront how much it's going to cost me! I have absolutely no idea of the cost to expect. : /

[WHeisenberg]

We actually used TrustWave in the past.

We didn't actually 'ask' them to do it,  it was the bank where our merchant account was set up that did it.

What we got back were reports of the results of their various scans on our site.   There were items that were considered 'High Priority' clear down to 'Low Priority'.   We quickly found out that the only things they were interested in actually having fixed were the 'High Priority' items.   We, too, are in the <20,000 transaction tier.

Those weren't too difficult to handle from a coding standpoint (google is your friend) and the items that needed to be taken care of at the server end were simple enough.   We just sent a copy of the report to our hosting server's support staff telling them what we were unsure of - they responded back with either directions on how to do it,  or the things that had to be done at their end they just did them for us.

Some things I learned from my PCI experience that may be of value:

1.  If you are using a database to store your information,  it is better for that database to be housed on a separate server than the one actually hosting your web site pages.  (Access databases would be a no-no)

2. On any page that requires customer information to be entered into a field,  you have to validate every single field to make sure it is formatted correctly and does not contain any 'hacker code' before the form information has a chance to be run across the target page.

3. If you have the ability to do so,  turn off your FTP server when you aren't actually using it,  change the port it uses to something other than '21',  and make sure you are using the latest version of whatever FTP software you run.  (If you are using a shared system for your FTP,  the host usually has taken care of all that for you)

4. On any page that runs a database query (even if that query isn't being triggered by a form on your site),  you have to be sure you filter the form information AND/OR the URL string that was submitted to run that particular page to make sure it doesn't include anything that doesn't belong there.

5. If you take credit card information directly on your site from a customer, you must have SSL (pretty basic there)

Trustwave is nice because if you've got an issue that shows up,  you can do what you think is needed to fix it (they even give you references and basic instructions on what to do to fix a problem in their reports), and when you're done you can have them re-scan the site and get an updated report to see if your 'fix' actually worked.

I think they call this their 'Compliance Validation Solution' or something.. pretty sure it was 'CVS'.

As far as cost,  since our bank was the one that pointed Trustwave at our site,  it didn't cost us a penny for any of it.   I'm not sure, but I don't think Trustwave actually charges anything to simply have them scan your site for errors and give you reports.  You would be a 'Tier 1' merchant.. or maybe they call it 'Level 1',  so you are making less than umpty-million transactions a year.   Where I think they make their money is when someone can't fix it on their own, and hires them to fix it.

I knew nothing at all about PCI compliance myself until we got hit with the Trustwave report through the bank.  It took me about a week of fiddling around to figure out what some of the stuff meant,  but it wasn't too hard (again, google is your friend).

Good Luck

WHeis