We're developing a new piece of software (really just a single php script) that collects cardholder information and stores it in a MySQL database. Obviously we're taking every precaution with security (Firewall, Anti-Virus, SELinux, restrictive access to the machines), but we're trying to understand what steps we need to take next before taking it live.
As the client is a Level 4 Merchant (no actual transactions, just storage of cardholder information), what scans do we need to go out and find?
Obviously we'll need to have the server/IP scanned, but what about the php script collecting the data?
First of all, make absolutely sure you have to store the card details. If there is a possibility you can avoid it, then I would suggest you make every effort to do so. There are often card processing gateways that will allow you to process 'repeat transactions' whereby you supply the card details for the initial transaction and are then given a transaction ID to facilitate repeat transactions.
However if you cannot avoid the storage then you'll need to take the following points into account
As for Scans, there are many on-line PCI-DSS approved scanning vendors. These can be found on the approved scanning vendor pages on the PCI-DSS Website. I can quite heartily recommend Qualys. We use them and they are really easy to use and assist you in completion of the SAQ.
As for the PHP script, there are few requirements about how the code is developed in that your developers must adopt best practices and various standards of secure code development. There's also a raft of requirements with respect to the testing and production environment.
Development of scripts that deal with card data is covered by the requirements in 'Requirement 6: Develop and maintain secure systems and applications'
Storage of card data is covered by the requirements in 'Requirement 3: Protect stored card data'. However this section covers all forms of storage, e.g. paper receipts or electronic...
It's rather tricky to implement storage of card data however, since not only must the card data be encrypted, but also the key used to encrypt the data must be encrypted and the second key should be known only to two separate responsible persons. There are however ways around this since the 'spirit' of PCI DSS is to not only ensure absolute compliance, but in areas where compliance cannot be guaranteed, then there is enough auditing available so as to trace and attribute data access.
Some of the relevant sections in this regard are requirements 3.4 for card data storage, 3.6.6 for manual-key management and split-knowledge however there may be several others due to your environment, so I would heed you to read and understand the requirements and the testing procedure.
Unfortunately I can't link directly to the relevant sections of the PCI DSS standard since it's a PDF.
Finally, don't forget that PCI-DSS is not a "best-effort" standard. You must comply with every requirement in order to be in compliance of the card providers. Where you cannot meet requirements or they are not applicable you must either have compensating controls in place or must note the requirement as Not Application and explain why. The PCI-DSS is 'all or nothing'
Unfortunately, cardholder data storage E-commerce environments are subject to the most stringent PCI-DSS requirements (type D).
NOTE: People will tell you that Level-1 merchants are subject to more stringent rules than Level-4. This is simply not true. Audits are only required for Level-1 merchants, but if you are a level-4 that is caught breaking the rules you are still subject to some massive penalties and legal liability.
The complete list of rules you need to follow are here: https://www.pcisecuritystandards.org/documents/pci_saq_d.pdf
During your app development, you will want to pay special attention to Requirements 1-4.
Often, I recommend that small shops outsource cardholder data storage and even shopping cart stuff if possible in order to reduce headache and liability. NetSuite, Paypal, Google Checkout and many others can help you there.
There's no real "one size fits all" answer to PCI compliance unfortunately, so the required steps will be different from situation to situation. The best way to find out what's required is to go through the PCI DSS Self Assessment questionaire.
Based on your description and the information in the PCI DSS SAQ Guidelines (pdf), it sounds like you'll need to work through SAQ D, but you'll want to double check that it's correct. If you have any specific questions on one of those steps, feel free to update your question and I'll see if I can add more specific info.
I wholeheartedly recommend buying a Barracuda Web Application Firewall. I don't work for them, but it's a great product (albeit with a fairly steep learning curve) and provides PCI compliance "out-of-the-box".
I'm not saying don't do regular code audits or fix your bugs, but with a properly tuned/configured Web Application Firewall, you can mitigate against the risks and vulnerabilities you don't even know exist yet.