Amazon Confirms EC2/S3 Not PCI Level 1 Compliant 157
Jason writes "After months of digging though speculation and polar opposite opinions from PCI experts, I finally sent a direct request to Amazon's AWS sales team asking if they are in fact PCI compliant and will provide documentation attesting that they are as is required by PCI guidlines. I fully expecting them to dodge the question and refer me to a QSA, but to my relief, they replied with a refreshingly honest and absolute confirmation that it is currently impossible to meet PCI level 1 compliance using AWS services for card data storage. They also very strong suggest that cardnumbers never be stored on EC2 or S3 as those services are inherently noncompliant. For now at least, the official verdict is if you need to process credit cards, the Amazon cloud platform is off the table."
Re:Amazon payments (Score:5, Informative)
Unless of course you just call a remote API or website to do it. Services like Paypal just need a retailer id and a product/price and they handle the rest. You could even write your own non-Amazon service for the sensitive parts of the transaction.
well, duh... (Score:4, Informative)
I liked the setup we had at my last job - we used a stripped down openbsd (actually 2 for reliability) machine with one incoming port open to receive RPC requests from machines on our backend. Recurring charges were done via outgoing connections from the openbsd box on port 443 to a service provider. Every other port, in or out, was blocked. No credit card data was stored anywhere else, period. It's amazing to me how little respect some folks have for their customers financial information (let alone privacy).
Who is PCI compliant? (Score:5, Informative)
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Err.. quite tricky when your machine is a virtual host that you're accessing over the Internet. Whatever firewall you set up, _you_ need to have a way around it. Very few people bother with VPNs or the like; most virtual hosting packages I've seen have FTP and other services open to all. This seriously compromises its security.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Most web development companies I've worked with always want to transfer data around over unencrypted FTP, often including database backup files. The chances are, if you have a subcontractor handling your e-commerce web site, they're violating this requirement on a regular basis.
Requirement 5: Use and regularly update anti-virus software
Oh, yeah. Everyone has antivirus installed on their web servers. Wait... you mean they don't? What's this Linux thing?
Requirement 6: Develop and maintain secure systems and applications
Ha!
Requirement 9: Restrict physical access to cardholder data
Somewhat difficult when you're not hosting the system yourself, so this requirement can only be met by less than 1% of e-commerce retailers out there.
Requirement 11: Regularly test security systems and processes
When was the last time you performed a penetration test on your network?
Re:well, duh... (Score:4, Informative)
This information alone doesnt indicate how PCI compliant this solution was. To be PCI compliant every box that stores or *transmits* card data is in scope, including any routers/switches/firewalls that data hits. Presumably you also had a source to the card number data, and that sounds like an area of particular difficulty to secure. Any application that allows card data to be captured (even if not stored) should go through PA-DSS (payment application) compliance testing.
Re:Farm it out. (Score:1, Informative)
Because they cost money.
When you get big enough, the percentage these places skim off the top is a significant amount of money which can be saved over time by investing in the mostly fixed cost of developing the hardware/software yourself.
Because they lock you in.
When you're earning recurring revenue via card payments, if you use an external service to hold the card details and process the payments, it means that organisation is holding data which is critical for your business: no card details to charge means no revenue. If the external processing service jacks up their charges you've now got a problem: you either pay the increased fees (with no guarantee that the fees won't increase again) or you decide to change to some other service, and if you do that, you might have some difficulty extracting the card details from the first service.
Re:well, duh... (Score:1, Informative)
Yes, but even that setup needs to be PCI compliant.. PCI compliance has more to do than just with storing card data.. if you are processing card data or even touching the card for an instant, then it needs to be PCI compliant. The only exception is if it is an "in house" solution that goes nowhere. The standard for accrediting applications was called PABP Payment Application Best Practices which merged into PCI DSS. VISA's website has all the information. The PCI Security Council now manages the accredidations and they can take upwards to a year to get plus around $15,000 or more depending on the consultant and complexity of the application. I know this because I acquired PABP compliance for my Company's applications and now we need to migrate to PCI DSS compliance too that PABP is becoming obsolete.
Re:Farm it out. (Score:2, Informative)
because we're processing several million transactions a year across dozens of merchant accounts
Re:Consideration (Score:4, Informative)
Poster here:
I never asked the Amazon sales team because I never expected to get an answer like that
I wrongly assumed that by now someone would have asked, and if there was a straight forward response like this it'd be public knowledge
Re:Good thing... (Score:2, Informative)
PCI [wikipedia.org]
EC2 [wikipedia.org]
S3 [wikipedia.org]
Having just been through a PCI audit: DUH (Score:5, Informative)
There are dozens of requirements that EC2 will never ever be able to fulfil. It's just not possible. Take requirements for network segregation. The machines with cardholder data must be on a separate vlan with no direct access to the outside, in or out. There are physical requirements not just for the datacenter (locked racks, surveillance cameras), but for the workstations.
It's just impossible to do that on EC2 or anything like it.
In any case, you don't want to manage cardholder data. Leave it to someone who is willing to go through the trouble.
Re:Don't laugh, we had to install AV on Linux (Score:2, Informative)
As often is the case with PCI, it depends. Under normal circumstances, in an environment consisting solely of Linux servers, an AV product is not usually required. However, while the linux servers themselves might be "safe" from malware, they can just as well be used to spread them through for example email, file shares etc. If the environment has even one Windows server in the cardholder data environment (CDE), an AV product that catches windows malware would be required on the Linux servers.
Level 1 compliant? Level 2 compliant? Wat? (Score:5, Informative)
"As for PCI level 2 compliance, that requires external scanning via a 3rd party, PCI-approved vendor. It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. "
There seems to be a dangerous misunderstanding about PCI validation requirements in the reply from Amazon. There's no such thing as "level x compliance", the levels refer to merchant levels set by the acquirer. The merchant level is determined by the volume of credit card transactions for a single card brand (e.g. Visa). The actual security requirements for all 4 merchant levels are EXACTLY the same, the only difference is how the compliance has to be validated. Level 1 merchants are required to perform an on-site audit by a QSAP annually, whereas the other levels only require filling a self-assessment questionnaire (SAQ) once a year. Quarterly vulnerability scans by an ASV are required for all levels except 4, where they are optional.
Trust me, it 's not trivial (Score:5, Informative)
The remote check is just one tiny part of it. You also need an internal check of the network every three months.
You need a web application firewall.
You need to log every single change on the server configs.
You need an IDS.
You need file integrity monitoring for the logs.
You need to backup the log.
You need multi factor authentification.
And so on and so forth.
You could be mislead while perusing the doc, because the really hard parts are not contrasted with the trivial ones ("run an antivirus"), and if you don't know what they entail, you could confuse them with something much harder. Take network segregation; at last count we have about a dozen VLANs.
A connection to our intranet goes through 7 of them, one each for the SSL front end, Web app firewall, web server, app server, web database, which is fed sanitized data from a database that is, in turn, twice removed from the cardholder application itself. Application that doesn't even talk directly to either terminals or banks, they go through at least one proxy, on another vlan.
This is not spelled out in the PCI standard, but was the only to respect it.
This is in addition to the transaction costs of 3-4%, the transaction processing costs, the fees paid by the consumers, etc, etc.
That number is a bit high, you can get a much better deal if you have a million TX a year, I think.
Can we please find a secure way of using direct debit, so we can cut the credit-card companies out of the loop?
Card hardware companies are currently all working on end-to-end encryption, whereby no unencrypted data will be stored anywhere between the card itself and the bank.
But that would require smart cards, something we've had here since, oh, 1989 (I've never had a card without a chip). And that doesn't cover card-not-present use cases. As long as you have to store any clear text card numbers, you'll have to abide by PCI, I'm afraid.
All considered, PCI is a very good thing. I was skeptical at first but no one would be doing a tenth of what's needed without it.
Re:Achronym soup. (Score:5, Informative)
PCI: Payment Card Industry. The full acronym should be PCI DSS for Payment Card Industry Data Security Standard.
AWS: Amazon Web Services, an API offered by Amazon to allow access to their internal back-end.
QSA: Quality Security Assesors, security firms certified by the PCI council to audit payment card processors.
EC2: Elastic Computing Cloud, Amazon's virtualized hosting system.
S3: Simple Storage Service, Amazon's cheap web-based storage.
Cheers!
-dZ.
Re:Linux has malware, and malware != virus (Score:2, Informative)
PCI DSS requirement: 5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.
Testing procedure: 5.1.1 For a sample of system components, verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits).
If your QSA required an AV in an all Linux environment, I would ask him to explain what he based his decision on. The standard requires AV software "on all systems commonly affected by malicious software", in my opinion Linux is not one of them. And yes, I'm a QSA.
Re:As someone who works in web server support (Score:4, Informative)
Sir, if you want to write a better security standard that can easily be applied to every operating system from embedded payment terminals to Windows NT3 to AIX, every environment from a cloud-hosted webshop to ones consisting of hundreds of datacenters or a chain of tens of thousands of stores around the planet, and be easily applied to every piece of commercial or custom software on the planet, yet still include specific settings for certain versions of Apache and Joomla, go right ahead.
For example, PCI argues that credit card information should never be stored on a server.
"3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
In other words, it does not say that. In fact, the whole requirement 3 deals with how to secure stored cardholder data.
Virtualization (Score:4, Informative)
At last check, the PCI folks still haven't even made up their minds as to virtualization. Our auditor (Security Metrics) made us move our card processor our of our in house virtualization to a dedicated machine, and we were running everything on a mainframe with LPARS, but they were not comfortable with that. Not a big deal, but you'll seee others out there like GSI how advertise the fact that their VMware clouds are PCI-DSS compliant. Given that all of the clouds are VM servers, I don't think you can go with any Cloud solution and really be PCI-DSS compliant.
We do exactly what amazon suggests and run our processing in-house while our app runs in the cloud. This seemed to be a best of breed approach.
As to why we would run/write our own processing software, we are a payment gateway, and that .5 to 1 percent we save on each transaction makes a large difference. Even if it did take 1.5 years to actually become PCI complaint.
As for the web application firewall of requirement 6, you can do either that, or formal code reviews by qualified (which they don't define) individuals or 3rd parties.
Is PCI worth it? Only if your going to be a gateway as far as I can tell. If you just need to process your own sales, use someone else. And don't go through the hassle.
oh, and use a highly modifed version of the SELinux ref-policy for your card processor so that even your admin folks can't get at the data.
Re:Amazon payments (Score:4, Informative)
Re:Amazon payments (Score:4, Informative)