PCI Compliance with Meteor

[Loren Sands-Ramshaw]

Below is the list of PCI DSS rules, and if a company were to use a PaaS provider like Meteor/Galaxy, which rules each party would need to be responsible for. I was going to ask whether Galaxy might support PCI compliance, but after reading through the docs, I'm guessing that's pretty unlikely. While it's pretty straightforward on the application side, there is a whole lot to do on the hosting side. In any case, here's my research in case anyone else finds it helpful.

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Galaxy

1. Install and maintain a firewall configuration to protect cardholder data 

2. Do not use vendor-supplied defaults for system passwords and other 

security parameters 

5. Protect all systems against malware and regularly update anti-virus software or programs 

6. Develop and maintain secure systems and applications (security patches)

7. Restrict access to cardholder data by business need to know

8. Identify and authenticate access to system components 

9: Restrict physical access to cardholder data 

10: Track and monitor all access to network resources and cardholder data (Lots of logging, including database access, some of it which needs to be viewed by the company daily)

11: Regularly test security systems and processes. (WAP monitoring, network vuln scanning and pen tests, IDS, change detection)

12: Maintain a policy that addresses information security for all personnel. (Includes "contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder 

data environment.")

Company

3. Protect stored cardholder data (Encrypt data, either disk-level (Galaxy), or manually in code, with db hooks and complicatedly-managed keys)

4. Encrypt transmission of cardholder data across open, public networks (SSL between client + server and between server + processor)

6. Develop and maintain secure systems and applications (General web app/programming security, some taken care of by the framework, some not)

7. Restrict access to cardholder data by business need to know

8. Identify and authenticate access to system components (This has a whole lot of things, like rate limiting login attempts, lockout time, 15min idle logout, inactive account removal, but it seems you can get around implementing this in your app by just not letting your users view their own CC data.)

11: Regularly test security systems and processes. (App-level pen tests)

12. Maintain a policy that addresses information security for all personnel. 

[Aaron Judd]

Why are you storing credit card data would be the real question? That's a risk that almost no ecommerce shop should be taking.

As long as you avoid doing that (ie, usually it's a stored on the authorization processor, and you get a token), and encrypt communications you're ok.  

You also need to look at the different tiers of PCI, where does your volume put your PCI requirements?  As far as Galaxy - that might depend on where they are physically putting the boxes, but AWS at least, I belive is PCI certified (in that if you tried to get PCI certified, they've done their bit).

[Kyle McLaren]

AWS has a PCI Level 1 compliance package that is available under NDA. That's the best option as something like Galaxy (which could maybe be compared to Heroku) will likely not be flexible enough. You need to have your boxes running in a VPC, you need to have Intrusion Detection Systems installed, encryption of data at rest and in flight as well as solid key management system (whether software or hardware based).

It is 100% possible to become PCI compliant with AWS, but I guess we'll only know more about Galaxy after it launches. My advice is don't bank on it and go the AWS route.

[Arunoda Susiripala]

Hi,

Cloudflare recently announce PCI support: http://blog.cloudflare.com/cloudflare-is-pci-certified

May be that will the easiest way.

Thanks.

[steeve]

Loren

PCI-DSS is dependent on various categories associated with transaction volume.  We have significant transaction volumes and would be subject to the most severe and expensive PCI-DSS audits had we not chosen to A - never store any payment or card data and B- never transmit any payment or card data.

So, the simplest thing is to never store credit card data and never handle it unencrypted within your application in flight.  The remaining elements are not absolutely necessary but recommended and would be specific to your IAAS provider rather than something like Galaxy.  I think Galaxy is going to be more of a suite of DevOps tools allowing you to deploy and manage anywhere on any environment.  So you choose your IAAS and deploy and manage.  It is the IAAS environment that you have to suitable battle harden for your use case.

Also, any processor worth their salt should provide a methodology/module/library that tokenizes the card.  Card tokenization is absolutely critical and if you using a processor that doesn't support it then you should change NOW.  You should never be communicating actual card data to the processor in this day and age.  You should be communicating short lived tokens that represent the card.  The processor should support the ability to do things like adjustments, voids, reversals, etc... by token or for longer lived transactions by parent transaction id.  So for all manual entry whether it is CP or CNP, the card should be tokenized prior to any use, interaction or transmission of the card.

If you are going to go as far as card mag stripe reading, then also any processor worth their salt should be able to provide mag stripe readers that use pki dynamic key exchange and encrypt the entire mag stripe as it is being read with strong encryption.  Otherwise your mag stripe reader is subject to ram vector scrapping and the kinds of intrusions that target and nordstroms were hit by this last holiday season.  Cheapo clear text mag stripe readers are all over the place and right now in the real world 95% of the time when your card is swiped that is what is being use and your card is at risk because it is read in clear text and potentially communicated in clear text up stream.  If your processor doesn't provide mag stripe readers or terminals that encrypt the mag stripe data then you are subject to ram vector scrapping attacks.  

The above 2 options cover all 3 card use cases: cp mag, cp manual entry and cnp manual entry and if the solution is provided by the processor the scope of PCI-DSS diminishes and the liability shifts.  In fact, many processors provide insurance polices that cover your losses should there be an incident if you use card tokenization and mag stripe encryption.

In the USA, starting in October 2015, this becomes less of an issue for cp mag stripe transactions because EMV compliance hits and 100% charge back liability shifts to the merchant.  Thankfully, the US will finally join the rest of the modern world to deploy emv chip/pin cards (for both debit and credit) and merchants that do not deploy emv chip/pin readers are 100% liable for any and all charge backs with no dispute rights should they process something as a mag stripe.  This will be a huge win for card present swipe (well actually chip pin) merchants.

If we have learned anything from the slew of attacks over the last 2 decades it is DO NOT A- transmit card data even if it is encrypted in flight via SSL but rather make sure it is also tokenized and never use the card number and B - never store card data, ever.

[steeve]

Loren,

Noticed this hit the news about a week ago.

http://www.scmagazineuk.com/pci-dss-audit-tool-cracked-by-cybercriminals/article/349164/

So, I cannot reiterate enough...

1. Your processor/gateway should be encrypting mag stripe reads via hardware encryption only.  Most standard mag stripe readers whether they are in a point of sale device or connected to a pc, phone or tablet read in clear text and transmit in clear text.  Make sure you are using one that uses dynamic pki strong hardware encryption.
2. Your processor/gateway should be tokenization cards numbers so you don't have to store them and of course never store card data.
3. If your processor or gateway isn't doing this then you shouldn't be using them.  This includes gateways that provide forms, apis, widgets, plugins or whatever.  If they are not tokenizing the card and relying only on ssl then you should not use them.