Slashdot Log In
Amazon Confirms EC2/S3 Not PCI Level 1 Compliant
Posted by
timothy
on Mon Aug 17, 2009 01:31 AM
from the division-of-resources dept.
from the division-of-resources dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Amazon payments (Score:5, Insightful)
That is ok, you can just use amazon payments, and probably pay less commissions than you would on your own and not have to worry about storing cc data
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.
Parent
Re: (Score:3, Interesting)
Calling a remote API is also non compliant as you are not allowed to store or "transact" in PAN card data.
You have to send the customer to the payment site.
Re:Amazon payments (Score:4, Informative)
Parent
Re:Amazon payments (Score:4, Informative)
Parent
Good thing... (Score:5, Funny)
I'm glad this was posted to slashdot. Now I know not to buy the EC2 or S3 cards for my machine. I mean, if they're not PCI compliant, I'm going to guarantee they don't have FOSS linux kernel drivers. The PCI spec is so old anyway. Any word on when Amazon will make new boards compliant to PCIE with FOSS drivers? Someone who knows, please post a reply.
Re: (Score:2, Informative)
PCI [wikipedia.org]
EC2 [wikipedia.org]
S3 [wikipedia.org]
Re:Good thing... (Score:5, Insightful)
Parent
Re: (Score:3, Funny)
Re:Good thing... (Score:5, Insightful)
I realized (or at least hoped) it was a continuation of the original joke, that's why I didn't say something like "y0u 1d107"' I posted the wikis only so that for anyone who actually did want to know what all this gibberish was about, didn't get lost in some wikimess of the comparison of graphical accelerators and the pros and cons of various bus types.
Parent
Farm it out. (Score:5, Interesting)
Why would you jump through the hoops of processing credit card data yourself, instead of getting one of the many - including, as another poster pointed out, Amazon - credit card processing sites to do it for you?
Re: (Score:2, Informative)
because we're processing several million transactions a year across dozens of merchant accounts
Sure, and a PCI audit costs nothing, right? (Score:2)
The audit itself costs €20k;. The cost of passing it is probably more on the order of $150k.
Re:Sure, and a PCI audit costs nothing, right? (Score:4, Insightful)
We looked into this at one point: got details on the audit, etc. Technically, it seemed to be a pretty trivial check of your systems. As I recall, you also had to agree to pay for a annual remote check - basically a port scan - which also cost a pretty penny.
Basically, it's a way of raking in money. Of course, the people who go through with the audit wind up passing the costs on to consumers. This is in addition to the transaction costs of 3-4%, the transaction processing costs, the fees paid by the consumers, etc, etc.
Can we please find a secure way of using direct debit, so we can cut the credit-card companies out of the loop?
Parent
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.
Parent
Re:Sure, and a PCI audit costs nothing, right? (Score:4, Insightful)
Uh, no thanks. The couple percent the CC companies charge is small insurance to make sure that joes website is not able to go in and clear out my checking and/or savings accounts. Unless you are going to go with something like one time card numbers with set transaction limits which is too difficult for most people to grasp.
Parent
Re: (Score:3, Interesting)
And, sadly, cutting and pasting a Euro symbol into Slashdot doesn't work.
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).
Re: (Score:2, Funny)
Cue PHB: "Respect for what? Does that bring money?"
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.
Parent
Consideration (Score:5, Funny)
It's awfully considerate of you to invest large amounts of effort in research to avoid bothering the sales team with, you know, sales inquiries.
Re:Consideration (Score:4, Insightful)
Parent
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
Parent
Re:Consideration (Score:5, Insightful)
Here's a straighforward response: If you can't find any documentation on it anywhere and if, as you say, Amazon seems to avoid the question, then it is pretty much safe to assume that you should not store your credit card numbers in such system.
Being "PCI compliant" is hardly a skeleton in the closet, so I doubt any vendor would shy from offering such assurance if it were available.
-dZ.
Parent
Re: (Score:3, Insightful)
What. An honest one?
There are PCI Compliant service providers out there, in fact, Visa has a list of them[1]. I work for one.
[1]
http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-providers.pdf [visa.com]
Who would have tought? (Score:5, Funny)
It sounds like they really are behind the times. I mean, not even PCI compliant, I'd have expected at least AGP or PCI-X as a bare minimum.
Mind you, I wonder if this is an old story as I'm fairly sure S3 stopped making video cards many years ago.
On another point, I too have often turned to the Queensland Swimming Association for all of my questions about All Women Shortlists, I find they are very knowledgeable.
Re:Who would have tought? (Score:5, Insightful)
For those lacking humor components in their brains, the parent (and a few other people) along with myself would like to say.
FOR FUCK SAKE GIVE US SOME MEANINGFUL POINT OF REFERENCE FOR THESE ACRONYM FILLED NON-STORIES.
Parent
Re:Who would have tought? (Score:5, Funny)
I once experimented with producing summaries that people like you might appreciate [reddit.com]. Turns out they don't work so well.
Parent
Re: (Score:2)
No, its great!
Maybe make it so that when you mouse over a word it gives a description, then when you mouse over the word in the little pop up description it pops another...
Brb, patent office calls :P
Re:Who would have tought? (Score:5, Insightful)
Parent
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:Who is PCI compliant? (Score:4, Insightful)
I'd guess that less than 1% of e-commerce retailers are processing cards themselves.
Parent
Don't laugh, we had to install AV on Linux (Score:3, Interesting)
Before 1.2 there was an explicit dispensation for Unix machines. Not anymore; although it reads to me that it's not needed, the auditor disagreed. So we had to install a token ClamAV on each machine, and have it scan the disks for ... mostly Windows viruses, since the database contains thousands of them, along with a dozen Linux viruses, none of which was ever seen in the wild.
Re: (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.
Linux has malware, and malware != virus (Score:2)
We cover malware with an IDS and Ossec; but that does not check the box "antivirus."
And we don't have a single Windows box on our network (we have two completely isolated networks, everyone has two workstations, data is exchanged through USB keys).
But the auditor required the antivirus. So we installed one. In my opinion this is completely retarded and reduces security, as AVs have been known to have vulnerabilities, too.
As someone who works in web server support (Score:2)
PCI compliance is an absolute crock of crap. The scans produce an endless list of nitpicks, most of which don't matter a bit in terms of actual security. (If they did, Red Hat would ship it like that by default.) And they usually miss gaping-wide holes like old Joomla installations that cry out to be cracked. Oh and Apache should NEVER have write access to the filesystem, except maybe /tmp, something not picked up in scans.
Actually I would probably argue that any server that runs PHP should not be used to p
The scans are only a tool (Score:2)
The person in charge of the scan just need to ACK the false positives as such.
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.
Parent
Re:Who is PCI compliant? (Score:4, Insightful)
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.
If your hosting package doesn't allow you decent control over the firewall, it has no place in an ecommerce platform.
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.
Use a different web development company. I'd be unlikely to want to deal with any developer who ever suggested FTP for the transfer of important data.
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?
If Linux and Windows boxes share the same network, you should run anti-virus software everywhere.
Requirement 6: Develop and maintain secure systems and applications
Ha!
Yup. Have coding standards, peer review of code, formal test and release cycles, segregation of duties between ops and dev staff, a viciously strict regression test cycle and systematic testing for SQL injection, cross-site scripting, etc. It's not rocket science.
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.
Your contract with your hosting prvider should address these security issues - in fact, they should be able to confirm that they're PCI compliant themselves. If they can't demonstrate that physical access to data, including backup tapes, is properly controlled, you need another hosting company.
Requirement 11: Regularly test security systems and processes
When was the last time you performed a penetration test on your network?
We schedule frequent (but deliberately irregular so that our ops guys don't know what's coming) internal and external penetration tests. I'm appalled that anyone one should consider building an ecommerce platform with commissioning pen testing.
We're not required to be PCI compliant, but I know we'd pass a PCI audit with very little difficulty. The standards simply reflect good practice, and we aren't interested in being second rate.
Parent
Re:PCI is shit (Score:2)
PCI is crap, because it's only really meant to be a way to cover your ass if something goes wrong. I see you skimmed the headlines of PCI compliance, and a lot of it is either just common sense or plain bullshit.
1.4 Install personal firewall software on
any mobile and/or employee-owned
computers with direct connectivity to the
Internet (for example, laptops used by
employees), which are used to access the
organizationâ(TM)s network.
There are a lot of points about making sure as few people as possible has access to the card data environment, but still they slap on this. I'm sure your PCI auditor can sell you such a software if you don't already have it...
5.1.1 Ensure that all anti-virus
programs are capable of detecting,
removing, and protecting against all
known types of malicious software.
My absolute favourite. Never mind that anyone familiar with computer scien
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.
Am I the only one? (Score:4, Insightful)
Am I the only one thinking "A generic and uncontrolled system that is completely virtual and could be run anywhere isn't sufficiently secure for storing or processing credit card details? No shit!"?
Seriously, I can see the benefit of cloud (which is effectively a glorified grid) for research and the like, but for information that needs to be secured like corporate secrets, proprietary information and credit cards? How can people consider "thing that is inherently changing and not controlled by you" to be a good answer?
For those in the know (Score:2)
PCI confirms not future compliant
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.
Achronym soup. (Score:3, Insightful)
What are
PCI
AWS
QSA
EC2
S3
Why editors don't ask for this to be clarified or reject outright something making so many assumptions about the field of expertise of the reader?
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.
Parent
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.
Where are the editors? (Score:3, Insightful)
Okay, offtopic trolling flamebait here, but...
Seriously, do SOME editing before posting any old journal entry or story submission. You know that "Preview" button? Use it.
Re: (Score:2)
Re: (Score:2)
Whatever it was, it's the most refreshingly honest canned response I've ever read.