Slashdot Mirror
Amazon Confirms EC2/S3 Not PCI Level 1 Compliant
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."
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
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.
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?
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).
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.
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.
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?
Too many acronyms.
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.
Better question is why do you need to be storing that information in the first place?
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?
The audit itself costs €20k;. The cost of passing it is probably more on the order of $150k.
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.
A better article title:
PCI confirms not future compliant
"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.
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 process credit cards. That thing has *so* many vulnerabilities. Not trying to troll, it's just true. Of all the web site exploits I've seen, I can't remember a single one that didn't somehow involve PHP or a misbehaving PHP application.
Website security is possible, it just takes some brains. For example, PCI argues that credit card information should never be stored on a server. I think it can be done securely. For example, have a database user for the web application. That user is allowed ONLY to insert CC information, not read it. Have a separate admin user that can read back the information, and that user should only be able to connect from a known-secure network, such as the office. NOT even the server itself (unless maybe you are already root, but certainly not the web server). This for example could be implemented with security definer functions in PostgreSQL. Obviously you want to lock down SSH, and turn off FTP and most other crap.
This article makes none. Seriously, what the heck ?
GeoKone.NET
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 science can prove that it is impossible to construct such an anti-virus program ever, you still have to check this box and claim you ensured this. I'm sure there are more points in the specification that are 100% bullshit that others can find:
https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf
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?
IANAL but write like a drunk one.
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.
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.
The person in charge of the scan just need to ACK the false positives as such.
Whatever it was, it's the most refreshingly honest canned response I've ever read.
XML is like violence. If it doesn't solve the problem, use more.
>> For now at least, the official verdict is if you need to process credit cards, the Amazon cloud platform is off the table.
May I be the first one to say, no Duh!
-dZ.
Carol vs. Ghost
No, its possible. It just has to assume there is a virus, and then know how to thoroughly trash the hardware in question in order to remove said presumed virus, which should also prevent "reinfection" in the process.
Hrmm, scratch that, someone could write a meme on the case of the computer. While an operating computer could control a sandblaster to automatically remove notices of Kilroy's presence, an otherwise "secured" computer wouldn't.
Is amazon sayng that EC2 is not PCI compliant or hat storing cards in EC2 is not PCI compliant? It seems as valid to read it the second way as it is to read it the first.
PCI is crap, because it's only really meant to be a way to cover your ass if something goes wrong.
Except every time something goes wrong, Visa finds a way to claim the company wasn't compliant. Heartland was thrown to the wolves, and you can bet your ass Network Solutions was too.
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.
He was of the opinion that there were viruses on Linux. I looked up what he referred to, but those were basically press releases from proprietary AV vendors, and covered the usual POCs never seen in the wild. In one case one vendor claims that 80% of a certain type of Linux apps are infected with a Linux virus.
That certain type is "rootkit." Yeah, 80% of rootkits are infected with viruses. Scary shit indeed.
So we could have argued and wasted a few hours of his and ours' time.
But apparently that would have counted as a compensatory measure (is that the term?) anyway and we need to have as few as possible.
In the end installing a token AV and have it scan /tmp and /home nightly was easier.
Care to elaborate on that?
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.
http://slashdot.org/comments.pl?sid=1337431&threshold=-1&commentsort=0&mode=thread&pid=29078769
Those are my replies to you, answer them, point by point... That's for your stating this:
----
"2) You're talking to APK. He exists to write wall-of-text comments. His depth of knowledge is *really* shallow, so don't expect a good conversation out of him." - by ion.simon.c (1183967) on Thursday August 06, @08:09PM (#28980845)
----
That's where YOU came in & disrupted a GOOD CONVERSATION that DavidWr & I were having, which only serves as evidence of your "trolling" myself, & probably others here also... much to YOUR dismay, no less.
and this:
http://slashdot.org/comments.pl?sid=1230601&threshold=-1&commentsort=0&mode=thread&pid=28076381
----
"Do you remember saying this [slashdot.org]?
So, thus "you reap what you sow" & I promise you something, right now:
That posting of mine that shows your errors in this exchange? Well, that is going to go into EVERY ONE OF YOUR POSTS here, until you can't stand it anymore, & change your nick/handle here
You're breaking your promise to me. It's been a week since you've last posted anything to my comments on slashdot. I haven't changed my handle, and still post from time to time. What happened over on your end?" - by ion.simon.c (1183967) on Sunday May 24, @02:29PM (#28076381)
----
So, here I am, honoring YOUR REQUEST no less! You seem to think it's "OK" to troll others... & last time? You ran, just like you are, now. I "laid off", thinking "enough IS enough", because you're not even a "worthy opponent" really!
BUT, since you stated that? Well - then, here I am: I am now confronting you, directly, on those statements of yours, & in front of everyone here (&, they CAN see you "running")...
Albeit, unlike yourself?
I can do so, easily, & with evidences of YOUR ERRORS on your part, as regards the art & science of computing (IRAM, HOSTS files, DNS Servers, & that YOU ARE A PROFESSIONAL PROGRAMMER (not)) as well as your lack of visibly provable accomplishments in this field (which I have, from respected noted sources no less, in WRITTEN PUBLICATION in this field).
Want to state things like the above? Well, you "sowed the wind", & now comes time for the whirlwind in response.
APK
P.S.=> SIMIAN, bottom-line, is this - You don't even TALK a "good game"!
(However, YOU surely shoot your mouth off, as quotes of your own big talk above clearly notes (but, as per usual, you are unable to 'back it up', ion.SIMIAN.c)... After the crap you spouted above, I have every right to feel "righteous indignation" & to defend myself vs. it (using easily verified lists of facts, which you have nothing even remotely LIKE, to YOUR credit))... apk
When it comes to PCI, sounds like Amazon doesn't understand the difference between compliance and validation.
All merchants are required to be compliant with ALL of the requirements of the PCI-DSS. You cannot be 'compliant with level two but not with level one'. That's a fallacy.
The ONLY difference between the levels is in the method of validation required. Level 1 merchants are required to have validation performed by a third party QSA. All other merchant levels are required to complete various forms of self-assessment questionnaires to validate compliance.
Further, scans of internal and external IP addresses are required for merchants of all levels.
It's been almost five years since the first version of PCI was released. As a PCI-QSA, it really, really frustrates me that major players are STILL getting this wrong.
I work for a payment processing company writing software. We are PCI compliant and have to be, or we don't do business.
That said, the vast majority of PCIs requirements are fucking idiotic. They were visibly written by people who have no concept of computers and networks in general.
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.
The vast majority of organizations were not doing these 'common sense' controls. I've been in orgs where the IT department wanted and tried to increase security, but had no budget until PCI required it.
I thought everyone used PCI Express now? :)
How can it be bad news that you can use Amazon for level 2 compliance? This is really good news !
...'.
:)
Level 1 compliance is required by Visa for companies doing more than 6 million transactions per year. That is a tiny minute number of businesses - which means virtually NO ONE needs to bother with Level 1 compliance. The annual assessment fees to maintain Level 1 classification are $15,000+ per year, depending on who assesses you, of course and depending on your systems. Who can afford that in the first place?
If you look closely at the PCI regulations, you will find that they are wide open, and can often be interpreted in many ways. This means they are patently unclear, and so are many of the comments and interpretations by assessors as well as by people looking at PCI rules, who have never read the regulations.
The only reason why Amazon can - based on their own statement - not be PCI 1 compliant, is because they will not give assessors onsite access for a validation. This is required for level 1 compliance. All other rules can be met by the Amazon system. This is not just based on Amazon's own statement, but based on going through the questionnaire and actually assessing EC2 against each of the requirements AS THEY ARE WRITTEN DOWN and not as they are being interpreted by whoever feels like it.
I had PCI 'experts' tell me that any computer in my office which connects to a PCI compliant server from within my office has to be in a locked up steel cage. And some other comments here do not seem to be much better. For example Linux servers are specifically excluded from requiring Anti-virus programs within the specifications.
Amazon doesn't like you storing your credit cards on their system - well no, of course not. Because if you set up your system badly and someone does break in, you'll probably try to blame Amazon rather than your own server setup. This has nothing to do with cloud server. In fact I have no idea why everyone keeps bringing the cloud into these specifications. Cloud is not mentioned in the PCI specs, nor are many other so called required hardware set ups for compliance. There is also no requirement to use hardware servers - does this mean you are not allowed to use hardware servers? Cloud servers are neither excluded nor included in the specs.
To be PCI compliant you simply have to meet all the requirements in the questionnaire applying to you as they are listed in the paperwork. EC2 servers and the EC2 datacenters meet all the hardware requirements. On the security side and providing you with the ability to lock everything down as required by the various questionnaires, EC2 meets all the requirements. How you lock things down and how you set up your security groups and how you follow procedures and how you encrypt credit card details has nothing to do with Amazon. But it is possible on EC2 to comply.
Just as an example look at question 1.1 of self assessment questionnaire D. 'Do established firewall and router configuration files standards include the following â¦' It does not say 'Do you have your own firewall and do you have full access to the firewall configuration and have you personally set up your very own firewall rules and standards which include the following
Yet that is how many experts like to read the regulations. When you talk to some PCI experts, they will claim that you must have your own hardware firewall to be PCI compliant and that you must set it up yourself. No, you don't. In fact the PCI regulations do not even ask for a hardware firewall. So you can run a software firewall on all your servers, if you like.
I for one am thrilled about Amazon confirming that EC2 is PCI compliant. And so long as you do not require an onsite assessment, you could be too. Whether you want to use EC2 or not is an entirely different story. But that has nothing to do with PCI compliance.
Steffan Klein
santu.com