Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Amazon Confirms EC2/S3 Not PCI Level 1 Compliant

timothy posted more than 5 years ago | from the division-of-resources dept.

Security 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."

Sorry! There are no comments related to the filter you selected.

Amazon payments (5, Insightful)

Anonymous Coward | more than 5 years ago | (#29088935)

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 (5, Informative)

Anonymous Coward | more than 5 years ago | (#29088957)

Exactly,

For now at least, the official verdict is if you need to process credit cards, the Amazon cloud platform is off the table

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.

Re:Amazon payments (3, Interesting)

Anonymous Coward | more than 5 years ago | (#29089539)

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 (3, Informative)

caramelcarrot (778148) | more than 5 years ago | (#29090251)

Isn't that what the posters are talking about? APIs like Paypal and Google Checkout do redirect you to a payment site hosted by the API provider.

Re:Amazon payments (3, Informative)

CastrTroy (595695) | more than 5 years ago | (#29090293)

No, there's other web based APIs. Where you don't actually keep any of the credit card info on your server, but you post it to the third party for the client in the background to authorize the client's credit card. Without PCI compliance, you aren't even allowed to receive or have the credit card data in memory, let alone store it to a database.

Good thing... (5, Funny)

Anonymous Coward | more than 5 years ago | (#29088937)

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:Good thing... (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#29089015)

They admit the EC2/S3 isn't PCI [wikipedia.org] compliant, so that probably rules out AGP [wikipedia.org] , but that doesn't necessarily imply that they're not PCI-X [wikipedia.org] or PCI Express [wikipedia.org] . Personally I hope they'll release a PCIe x16 version. :)

p.s. Why is this crap on the front page?

Re:Good thing... (2, Informative)

Vectronic (1221470) | more than 5 years ago | (#29089123)

PCI [wikipedia.org]
EC2 [wikipedia.org]
S3 [wikipedia.org]

Re:Good thing... (1, Redundant)

superstuntguy (907884) | more than 5 years ago | (#29089273)

*whoosh*

Re:Good thing... (4, Insightful)

Vectronic (1221470) | more than 5 years ago | (#29089517)

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.

Re:Good thing... (1)

superstuntguy (907884) | more than 5 years ago | (#29089553)

Well, all I can say is to make your intentions clearer next time.

Re:Good thing... (1)

nedlohs (1335013) | more than 5 years ago | (#29091359)

Because the links in the summary were so hard to understand...

Re:Good thing... (4, Insightful)

trentblase (717954) | more than 5 years ago | (#29089281)

This post and all "informative" mods: whoosh. How many people on Slashdot actually run a business that accepts credit cards? To real geeks, PCI is and always will be the Peripheral Component Interconnect.

Re:Good thing... (0)

Anonymous Coward | more than 5 years ago | (#29089661)

I'm a security consultant and someone who knows the meaning of 'context'.
I wasn't in doubt as to which meaning of PCI was the correct one here.

Re:Good thing... (2, Funny)

will_die (586523) | more than 5 years ago | (#29089725)

Maybe to the young whippersnappers to the true ancient geeks it will always be the Protocol Control Indicator.

Clarification (-1, Offtopic)

s73v3r (963317) | more than 5 years ago | (#29088939)

Well, I'm glad that's cleared up. Now to settle the question of whether I've gotten First Post or not.

Eh hhem... (-1, Troll)

djupedal (584558) | more than 5 years ago | (#29088943)

> they replied with a refreshingly honest and absolute confirmation

My money says someone with a vested interest in feeding you blabhblahblah instead of the truth spoofed your query and you bought it...

Re:Eh hhem... (1)

ta bu shi da yu (687699) | more than 5 years ago | (#29089571)

Whatever it was, it's the most refreshingly honest canned response I've ever read.

Farm it out. (5, Interesting)

Gordonjcp (186804) | more than 5 years ago | (#29088951)

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:Farm it out. (1, Informative)

Anonymous Coward | more than 5 years ago | (#29089053)

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.

Sure, and a PCI audit costs nothing, right? (1)

Nicolas MONNET (4727) | more than 5 years ago | (#29089205)

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? (4, Insightful)

bradley13 (1118935) | more than 5 years ago | (#29089297)

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?

Re:Sure, and a PCI audit costs nothing, right? (1)

omz13 (882548) | more than 5 years ago | (#29089499)

Can we please find a secure way of using direct debit, so we can cut the credit-card companies out of the loop?

Direct debit is intended for regular payments, not one offs.

Trust me, it 's not trivial (4, Informative)

Nicolas MONNET (4727) | more than 5 years ago | (#29089501)

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:Sure, and a PCI audit costs nothing, right? (0)

Anonymous Coward | more than 5 years ago | (#29090003)

Aren't â20k and $150k about the same value these days?

Re:Sure, and a PCI audit costs nothing, right? (3, Interesting)

machine321 (458769) | more than 5 years ago | (#29090015)

And, sadly, cutting and pasting a Euro symbol into Slashdot doesn't work.

Re:Sure, and a PCI audit costs nothing, right? (0)

Anonymous Coward | more than 5 years ago | (#29090739)

And these companies regularly pull down $50m-$100m per year.

$150k on remediation and security out of $50m every year. Wow. My heart bleeds for them.

Re:Farm it out. (2, Informative)

Fo0eY (546716) | more than 5 years ago | (#29089087)

because we're processing several million transactions a year across dozens of merchant accounts

Re:Farm it out. (0)

jimicus (737525) | more than 5 years ago | (#29089177)

Have you ever looked into the prices of these card processors? They're astronomical, particularly when you consider that what they do is entirely computerised, has been for decades and once you've actually got the system setup almost certainly costs them an unmeasurably small amount per transaction.

I concede that getting the system setup is the expensive part, but even then I don't think their prices justify it.

Re:Farm it out. (1)

digitalchinky (650880) | more than 5 years ago | (#29089601)

The primary reason is to provide a seamless experience for the customer.

If I go to some slick looking website to buy whatever, and then get redirected to pay-pal or some other off domain payment system, then I'm probably going to shop elsewhere. For me it's a little like trying to run a government department where all public email is handled through @yahoo.com email addresses. (If you think this doesn't happen, take a trip to the Philippines)

Merchant accounts are not exactly cheap, but they can bring in customers you might otherwise not get. The whole PCI-DSS thing is a scam, but at the lower levels you can fill in the form yourself and mail it off. It's not difficult.

Re:Farm it out. (1)

smack.addict (116174) | more than 5 years ago | (#29090187)

You could do something significantly more professional like Aria or Zuora. There is no awareness on the customer side of being redirected to another site, and it beats maintaining your own PCI level 1 compliant infrastructure.

Re:Farm it out. (1)

pegr (46683) | more than 5 years ago | (#29090723)

Just so it's out there, there is no such thing a Level 1 compliant versus Level 3 compliant. Compliance is compliance. All merchants are subject to the same criteria of compliance. The levels apply only to compliance validation. Level 1 merchants must have an on-site compliance validation by a QSA (or attestation from a qualified internal audit signed by an officer of the company). Lower level validation requirements require only a Self-assessment Questionaire from the merchant.

(Why, yes, I am a QSA.)

Re:Farm it out. (0)

Anonymous Coward | more than 5 years ago | (#29091249)

like trying to run a government department where all public email is handled through @yahoo.com email addresses. (If you think this doesn't happen, take a trip to the Philippines)

Or Alaska!

well, duh... (3, Informative)

dirtyhippie (259852) | more than 5 years ago | (#29088961)

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:well, duh... (1, Funny)

Opportunist (166417) | more than 5 years ago | (#29089025)

Cue PHB: "Respect for what? Does that bring money?"

Re:well, duh... (3, Informative)

MtlDty (711230) | more than 5 years ago | (#29089043)

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:well, duh... (0)

Anonymous Coward | more than 5 years ago | (#29090673)

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.

Actually it's any device (excluding internet facing devices) which can conect to a device in the card holder environment is in scope. If every device in your LAN can connect to a device in your card holder environment then, every device on your LAN is in scope.

Re:well, duh... (1)

CoccoBill (1569533) | more than 5 years ago | (#29090735)

To be PCI compliant every box that stores or *transmits* card data is in scope, including any routers/switches/firewalls that data hits.

This is actually not the whole story. This is what the latest version of the DSS states:

"The PCI DSS security requirements apply to all system components. âoeSystem componentsâ are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications."

The traditional interpretation of that is that every system that transmits, stores or processes cardholder data, and every system directly connected to any of them, are automatically included in the cardholder data environment (CDE). The connected systems part is often forgotten, but it easily includes all backup/management/backend/support systems and workstations in the network. A system is directly connected, if it can "negatively affect the security of the cardholder data", and it's the merchant's responsibility to prove that it cannot. This can be done by for example system documentation or penetration testing.

Any application that allows card data to be captured (even if not stored) should go through PA-DSS (payment application) compliance testing.

PA-DSS only concerns commercially sold software, not software developed in-house or other custom software. The only relevant part about PA-DSS to merchants is that they should make sure that the commercial payment solutions etc. they purchase are PA-DSS certified.

Re:well, duh... (1, Informative)

Anonymous Coward | more than 5 years ago | (#29089073)

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:well, duh... (0)

Anonymous Coward | more than 5 years ago | (#29089851)

Yeah, our little 12 man company uses a similar system to process credit cards. But we're also PCI complaint. Is it such a pain to just never ever write someones credit card information to a disc? I mean we had something cobbled together with VB5, a serial port modem, and a rainy afternoon back in the late 90's. It was a system that was horrible and cryptic, but ran for damn near 10 years straight without failing (the modem finally died and we couldn't get another backup).

Consideration (5, Funny)

jasomill (186436) | more than 5 years ago | (#29088975)

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

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 (4, Insightful)

jdigriz (676802) | more than 5 years ago | (#29089071)

Shows a healthy distrust of salesmen. Even if they're not actually dishonest, they are frequently clueless.

Re:Consideration (4, Informative)

Fo0eY (546716) | more than 5 years ago | (#29089099)

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:Consideration (4, Insightful)

dzfoo (772245) | more than 5 years ago | (#29089613)

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.

Re:Consideration (1)

Fo0eY (546716) | more than 5 years ago | (#29091201)

I've always strongly suspect that Amazon is not PCI capable, however management here is 110% sold on the hype
I needed someone very black and white from an authority to get anyone to step back and start looking at cloud hosting seriously.

Re:Consideration (2, Insightful)

imag0 (605684) | more than 5 years ago | (#29089809)

I never asked the Amazon sales team because I never expected to get an answer like that

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? (5, Funny)

netpixie (155816) | more than 5 years ago | (#29088981)

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? (5, Insightful)

Barny (103770) | more than 5 years ago | (#29088997)

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.

Re:Who would have tought? (0)

Anonymous Coward | more than 5 years ago | (#29089039)

You mean something like linking keywords in the summary to web pages explaining what they mean? Yeah, it would have been great if they'd have done that.

Re:Who would have tought? (4, Insightful)

quickOnTheUptake (1450889) | more than 5 years ago | (#29089095)

Requiring readers to follow multiple links to figure out wtf the summary is about is annoying.

Re:Who would have tought? (5, Funny)

ubernostrum (219442) | more than 5 years ago | (#29089191)

I once experimented with producing summaries that people like you might appreciate [reddit.com] . Turns out they don't work so well.

Re:Who would have tought? (1)

Barny (103770) | more than 5 years ago | (#29089353)

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? (1)

ubernostrum (219442) | more than 5 years ago | (#29089811)

You're too late, there's already prior art [telescopictext.com] .

Re:Who would have tought? (1)

ion.simon.c (1183967) | more than 5 years ago | (#29090043)

a) That often doesn't stop the USPTO from granting an application.
b) Cute link. :D

Ion.SIMIAN.c - see the 1st url inside... apk (0)

Anonymous Coward | more than 5 years ago | (#29090919)

http://slashdot.org/comments.pl?sid=1337431&threshold=-1&commentsort=0&mode=thread&pid=29078769 [slashdot.org]

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 [slashdot.org]

----

"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

Re:Who would have tought? (1)

Aladrin (926209) | more than 5 years ago | (#29089949)

Wish I had modpoints. That's brilliant.

Re:Who would have tought? (1)

machine321 (458769) | more than 5 years ago | (#29090023)

tl;dr

Re:Who would have tought? (0)

Anonymous Coward | more than 5 years ago | (#29090809)

If the acronyms are not familiar to you, perhaps the story is not relevant to you.

Not Perfect (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#29089013)

What? You mean the end all and be all cloud computing isn't perfect? Hogwash!

Who is PCI compliant? (5, Informative)

julesh (229690) | more than 5 years ago | (#29089035)

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? (3, Insightful)

threephaseboy (215589) | more than 5 years ago | (#29089127)

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.

I'd guess that less than 1% of e-commerce retailers are processing cards themselves.

Don't laugh, we had to install AV on Linux (2, Interesting)

Nicolas MONNET (4727) | more than 5 years ago | (#29089219)

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:Don't laugh, we had to install AV on Linux (2, Informative)

CoccoBill (1569533) | more than 5 years ago | (#29089245)

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 (1)

Nicolas MONNET (4727) | more than 5 years ago | (#29089533)

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.

Re:Linux has malware, and malware != virus (2, Informative)

CoccoBill (1569533) | more than 5 years ago | (#29089859)

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.

Well we could have argued with the QSA (1)

Nicolas MONNET (4727) | more than 5 years ago | (#29090299)

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.

Re:Well we could have argued with the QSA (1)

CoccoBill (1569533) | more than 5 years ago | (#29090497)

I see. Well, if you were to ask the PCI Council about this, they would most likely answer "ask the QSA". :) If your QSA decided to be strict about the issue, other than changing your auditor there's not much you can do, installing the AV is probably the path of least resistance.

Btw the term is Compensating Controls.

Re:Who is PCI compliant? (1)

CoccoBill (1569533) | more than 5 years ago | (#29089315)

This might come as a surprise, but PCI does not have 12 requirements, it has (as of v1.2) 254 specific requirements. What the 12 categories that you're responding to state have very little to do with the actual standard.

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

The sad part is, however, that your portrayal of the compliance state of the systems in use is fairly accurate.

As someone who works in web server support (1)

Micah (278) | more than 5 years ago | (#29089317)

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.

The scans are only a tool (1)

Nicolas MONNET (4727) | more than 5 years ago | (#29089551)

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 (0)

Anonymous Coward | more than 5 years ago | (#29089565)

For example, PCI argues that credit card information should never be stored on a server

Never? Where does it say that? In a lot of instances credit card information is needed (recurring billing, refunds etc). PCI doesn't say you shouldn't store credit card data, it says you should do it securely.

Re:As someone who works in web server support (4, Informative)

CoccoBill (1569533) | more than 5 years ago | (#29090029)

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.

Re:Who is PCI compliant? (3, Insightful)

jonnyj (1011131) | more than 5 years ago | (#29089333)

I'm not sure if you're citing PCI rule to say that the requirements are too strict or because you think most people ignore them, but I'll bite anyway. You might be right that PCI is commonly ignored (it's a contractual requirement, not a regulatory one, so the risk of non-compliance is much lower than with other data protection rules), but IMV, the requirements are pretty sensible.

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.

Re:PCI is shit (1)

skrolle2 (844387) | more than 5 years ago | (#29089369)

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 [pcisecuritystandards.org]

Re:PCI is shit (0)

Anonymous Coward | more than 5 years ago | (#29089861)

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.

Re:PCI is shit (0)

Anonymous Coward | more than 5 years ago | (#29090009)

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.

2MA (1)

Snufu (1049644) | more than 5 years ago | (#29089051)

Too many acronyms.

Having just been through a PCI audit: DUH (4, Informative)

Nicolas MONNET (4727) | more than 5 years ago | (#29089193)

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.

Why? (1)

jaygridley (1016588) | more than 5 years ago | (#29089201)

Better question is why do you need to be storing that information in the first place?

Re:Why? (1)

pmontra (738736) | more than 5 years ago | (#29089233)

Don't know but I can think about a scenario: he's a hotel and needs to charge customers that don't show on the checkin day. Is there a way to do it without storing their credit card numbers?

Re:Why? (1)

jaygridley (1016588) | more than 5 years ago | (#29089247)

I suppose that makes sense.

Re:Why? (0)

Anonymous Coward | more than 5 years ago | (#29089875)

Take a booking deposit at the time of purchase - then you are covered. No storage required.

Re:Why? (1)

moj0e (812361) | more than 5 years ago | (#29091101)

There are ways for the hotel to store credit card information without storing the credit card information.
There are a various credit card processors (companies) that will accept the
customer's credit card and will give you a reference transaction number.

When you need to charge your customer, you can charge them
by using the reference transaction number instead of the actual credit card number.
That reduces the risk of your hotel being compromised and credit card numbers stolen.

Hope that helps :)

Am I the only one? (3, Insightful)

IBBoard (1128019) | more than 5 years ago | (#29089203)

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 (1)

_newwave_ (265061) | more than 5 years ago | (#29089261)

A better article title:

PCI confirms not future compliant

Level 1 compliant? Level 2 compliant? Wat? (5, Informative)

CoccoBill (1569533) | more than 5 years ago | (#29089275)

"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.

Re:Level 1 compliant? Level 2 compliant? Wat? (1)

CousinVinnie (241575) | more than 5 years ago | (#29090041)

I'm glad I'm not the only who noticed that.

As a further note, the same requirements are used for merchants and service providers. It makes no difference whether or not you are the merchant, and it makes no difference what "level" you are (ie: how many transactions you process), you get the same PCI DSS.

Re:Level 1 compliant? Level 2 compliant? Wat? (0)

Anonymous Coward | more than 5 years ago | (#29090099)

There seems to be a dangerous misunderstanding about PCI validation requirements in the reply from Amazon.

Agreed - though I suspect Amazon are trying to imply that "development" of PCI compliant apps on their platform is okay, just not execution. From the PCI docs though, even the definition of "firewall" would seem to preclude the public Cloud;

Knowledge Base : PCI Security Standards Council
9482 - Navigating PCI DSS (442.9 kb) - 7/7/2009 [talisma.com]

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Firewalls are computer devices that control computer traffic allowed between a company's network (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within a company's internal trusted network. The cardholder data environment is an example of a more sensitive area within the trusted network of a company

Confucius say; beware the CSO who classifies the public Cloud as "internal" or "trusted".

 

Re:Level 1 compliant? Level 2 compliant? Wat? (1)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#29090103)

I wonder if they are clueless, or simply cynical...

If the requirements are the same; but the strength of verification differs, it wouldn't wholly surprise me if, for the purposes of a lot of small time operators, the requirements effectively differ.

Sense. (1)

sakari (194257) | more than 5 years ago | (#29089335)

This article makes none. Seriously, what the heck ?

Achronym soup. (2, Insightful)

jotaeleemeese (303437) | more than 5 years ago | (#29089495)

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. (4, Informative)

dzfoo (772245) | more than 5 years ago | (#29089653)

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:Achronym soup. (1)

LearnToSpell (694184) | more than 5 years ago | (#29091219)

AWS: Amazon Web Services, an API offered by Amazon

I see what you did there...

Common sense? (1)

dzfoo (772245) | more than 5 years ago | (#29089595)

>> 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.

storage or CD2? (0)

Anonymous Coward | more than 5 years ago | (#29089921)

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.

Virtualization (3, Informative)

bobaferret (513897) | more than 5 years ago | (#29090135)

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.

SELinux (1)

Nicolas MONNET (4727) | more than 5 years ago | (#29090403)

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.

Care to elaborate on that?

Where are the editors? (2, Insightful)

denmarkw00t (892627) | more than 5 years ago | (#29090863)

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.

QSA (0)

Anonymous Coward | more than 5 years ago | (#29091331)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?