Suggestion on how to be PCI Compliant

Question

I'm working on a system that takes the customers credit card information before sending it to the processor. It requires me to ask the customer for cc#, CVV, date, one at a time and send that to my server between each request (https, no cookies, cache, or sessions used). How should I keep track of the data between requests? I thought about Memcache(d) or storing (encrypted) in a database and deleting as soon as the transaction is completed. They don't really seem like the best options. I would appreciate some suggestions if you have some.

Answer 1

It is compliant to keep them in memory during the transaction. It is safer (from a compliance Pov) and easier that storing them temporarily in a database.

PCI DSS 3.0 provides now guidance to protect Sensitive Data in memory while being processed to avoid data leakage in crash dumps.

Best practice is to use a library that encipher volatile memory.

Answer 2

First up, I strongly recommend you offload your PCI-DSS compliance obligations entirely by moving the responsibility to capture and process payment credentials over to the payment gateway provider. Most payment providers host the payment capture pages for their clients for this reason. This allows you to simply pass price information and invoice details to the payment gateway and then they return if the customer actually paid. Rolling your own payment gateway is about as dangerous as rolling your own crypto - worse actually; as you'll be handling money and various banking liabilities.

However, if for some reason you or your organisation doesn't want to use any of pre-existing payment vendors; you will need to keep the following in mind:

• You will either need to encrypt or hash any credit card "confidential details" that you record. These include card number, card expiry and account holder name. Hashing is an easier compliance measure to meet than encrypting. Not storing at all is even better.
• The CSC/CVV value (number on back of card) is never to be stored on your servers, it is a transient "card present" authentication property only.
• I believe nowadays new PCI-DSS compliant websites are being strongly urged to implement 3D-Secure or equivalent, where the user may also authenticate payment with a password entered on a third-party credit network or banking website.
• SSL/TLS will often need to be of the highest most expensive type of Extended Validation certificate. Such certificates (and some renewals) also require slow paperwork on official letterheads and authority of delegated "officers" in a given organisational chart. Bob from IT in the basement doesn't cut it (at least until paperwork tells Verisign or the like that Bob is now the delegated officer). This process for new certificates is not fast.
• PCI-DSS requires auditing of any login to the servers that store credit card details or participate in any part of the processing chain, from the DMZ reverse proxy to database and backup servers. This includes cloud processing or storage.
• PCI-DSS requires auditing and access control of all software development and deployments; which is somewhat at odds with healthy/people trusting Agile projects.
• PCI-DSS has some fairly specific ideas of what your network topology should be; an arrangement which may increase costs if you don't already have routers, switches and firewalls arranged in the desired subnet structure.
• PCI-DSS expects mainstream databases and web daemons; and which are fully patched and up-to-date. To this effect, auditors will often require you have fully paid-up support contracts for your software. Many auditors (at least when I last had to work with PCI-DSS) will not like open source software where a more familiar "robust" commerical application exists. So expect the possibility of having to shift from PostgreSQL to an Oracle database.
• You will need to keep detailed records of any emergency repair personnel or ad-hoc software contractors who have any access to the source code or servers.
• You will need to pay for external PCI-DSS auditor on a routine basis.
• PCI-DSS external auditing also requires documentation of internal PCI-DSS auditing by the organisation. This both saves the external auditor some time and proves that the organisation actually has to periodically think about their security. Internal audits will also cost money.
• This is not a complete list either*. The external auditor can essentially ask for any adjustment to any system or business process to meet compliance. The company can sometimes sign off on a list of audit risks and still get a PCI-DSS certificate, but the company lawyers will scream about the liabilities absorbed by having to sign a "sort of compliant" audit waiver.

So think very carefully about your business' core goods or services. Then consider if establishing and maintaining direct credit card processing is a key product of your business.

_{* password cycling, shell sudo restrictions, full support documentation, division roles regardless of company size; the list goes on. The PCI-DSS compliance process can take 6 months or more.}

Answer 3

You can check and try OSSEC (Open Source Security) which is a host-based intrusion detection system. Being open source is a plus for security and it helps with PCI.

It is said:

OSSEC helps customers meet specific compliance requirements such as PCI, HIPAA etc. It lets customers detect and alert on unauthorized file system modifications and malicious behavior embedded in the log files of COTS products as well as custom applications. For PCI, it covers the sections of file integrity monitoring (PCI 11.5, 10.5), log inspection and monitoring (section 10) and policy enforcement/checking.