PCI Compliance

Sandman - I agree 100%

The more government seems to regulate something the worse it gets! The people making the laws in many cases have no idea the technical aspects.

PCI compliance certification is worth the cost, especially if it'll set you apart from other providers. Have you considered tokenization? This can significantly limit the scope of PCI by eliminating the storage of sensitive information. I wrote more on this here: http://resource.onlinetech.com/simplifying-pci-compliance-with-tokenization/

PCI isn't government regulated; it's regulated by the top credit card company brands that joined together to create a union-type organization to enforce the standards they came up with. The only government regulated technical-related law that affects IT/developers is HIPAA compliance that really doesn't even outline technical aspects, just security/privacy safeguards. Health information (and the health industry in general) needs a certain amt of regulation to protect general rights of people.

Is there a particular reason you don't just provide your bank or requesting party or merchant account supplier the self-assessment SAQ version.

I know with the red tape risk mitigation banks in my country a self-assessment SAQ is acceptable for their merchant account requirements.

I'd like to see NOPCommerce PCI DSS or PA-DSS compliant at the cart provider level but for now we and our clients are having no issues with banks and self asssessment SAQ's.

So far I found doing the SAQ painful enough.  I'm doing it now and for some of the questions I have no idea how I should answer, e.g.

3.6.b Do key-management processes and procedures include the following?

3.6.1. Generation of strong cryptographic keys

3.6.2. Secure cryptographic key distribution

3.6.3. Secure cryptographic key storage

Amongst others....

Answers on a postcard please.... (you might have to be British and of a certain age to understand that reference!)

Any (constructive) advice welcomed! ;-)

axdaws wrote:

Sure it was a little instense but it is payment and credit card data after all. Answers are below mate -

3.6.1 Yes the user password is Hash/Salt key encrypted and the credit card number is encrypted. You may like to upgrade NOP as sometimes the card security number it is stored for manual processing payment methods as plain text. Simply do a script to clean that field of data (say every hour or 15 minutes or triggered after successful manual processing) and then all things are compliant. However having the customer password and credit card number encrypted is enough to pass tests for the third party we hired to 'audit/test' our systems for certification.

3.6.2 The salt key (user password) and private key encryption method (credit card) are secure as they are not given out nor can they be decrypted easily.

3.6.3 Salt key is the standard Microsoft method for customer password encryption and a private key system for credit card encryption is used. The private key for credit card encryption is stored in NOP_Setting so you may make mention of that but there is not method for customers to access that key.

Noting such points and having an audit test by a SAQ approved tester was enough for us to pass certification and we have many clients using our certificate and eWay Australia's certificate to pass their bank requirements for merchant accounts.

Thanks for the words of advice Action.  Your input is appreciated.-)

I'm pleased to say we've completed the SAQ and passed our PCI scan too! We are compliant! :-)