0

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?

Improve this question
2

4 Answers 4

Reset to default
3

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.

Improve this answer
3
  • 1
    To expand on this a bit; you may also be required to maintain PA-DSS compliance since this will be an 'application': pcisecuritystandards.org/pdfs/pci_pa_dss.pdf
    – Mat
    Feb 8, 2011 at 21:41
  • 2
    To expand on Mat's comment, only applications which are to be re-sold as a product must comply with PA-DSS. Applications which are developed bespoke for a purpose (one-off's) are required to comply only with the DSS. By application, I mean something like an EPOS terminal software or some gadget to connect with a PED device or Chip and Pin reader.
    – pobk
    Feb 8, 2011 at 21:46
  • PA-DSS is only needed if you're going to resell the software in an "off the shelf" fashion (install it yourself). If you're going to sell the software as an ASP (Application Service Provider), there are additional requirements in PCI-DSS for service providers.
    – Irving
    Feb 10, 2011 at 17:57
5

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'

Improve this answer
2
  • "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." ...which generally means NOT using PHP at all ;-)
    – rmalayter
    Feb 8, 2011 at 22:42
  • +1 For first stating ensure you need to store card details, personally, I recommend no company at that level store their own, most gateways will store sufficient to process authenticate/authorise and refunds, no need to store locally with the risks that entails.
    – Orbling
    Feb 9, 2011 at 3:09
1

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.

Improve this answer
0

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.

Improve this answer
3
  • 3
    I believe you should clarify the 'PCI compliance "out-of-the-box"' comment. While the device does go a long way to helping with PCI-Compliance, it does not provide compliance out of the box. What would happen if the switch which connects the servers storing card-data were to be compromised and port-mirroring configured to mirror data to somewhere else? It would be a trivial exercise to recover card details, even behind the "application firewall". I would not recommend devices like this as a 'magic bullet' without explicit clarification.
    – pobk
    Feb 8, 2011 at 22:03
  • "out-of-the-box" was a paraphrase from Barracuda, but yes, if you bypass the WAF, obviously it's not going to do much.
    – gravyface
    Feb 9, 2011 at 1:10
  • I have a question about the Barracuda WAF, I have a cisco ASA with the IPS module, would I also need redundant WAF's to provide a secure environment for PCI compliance for my client?
    – Rob
    Jun 17, 2011 at 17:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .