Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Businesses The Almighty Buck Technology

Amazon Confirms EC2/S3 Not PCI Level 1 Compliant 157

Jason writes "After months of digging though speculation and polar opposite opinions from PCI experts, I finally sent a direct request to Amazon's AWS sales team asking if they are in fact PCI compliant and will provide documentation attesting that they are as is required by PCI guidlines. I fully expecting them to dodge the question and refer me to a QSA, but to my relief, they replied with a refreshingly honest and absolute confirmation that it is currently impossible to meet PCI level 1 compliance using AWS services for card data storage. They also very strong suggest that cardnumbers never be stored on EC2 or S3 as those services are inherently noncompliant. For now at least, the official verdict is if you need to process credit cards, the Amazon cloud platform is off the table."
This discussion has been archived. No new comments can be posted.

Amazon Confirms EC2/S3 Not PCI Level 1 Compliant

Comments Filter:
  • Amazon payments (Score:5, Insightful)

    by Anonymous Coward on Monday August 17, 2009 @01:38AM (#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 (Score:5, Informative)

      by Anonymous Coward on Monday August 17, 2009 @01:42AM (#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: (Score:3, Interesting)

        by Anonymous Coward

        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)

          by caramelcarrot ( 778148 ) on Monday August 17, 2009 @07:45AM (#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 (Score:4, Informative)

            by CastrTroy ( 595695 ) on Monday August 17, 2009 @07:52AM (#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.
          • Naw. You have always had an option with PayPal to do a deeper integration and have the payment processed "behind-the-scenes" without sending someone to PayPal to finish the transaction. I believe Google Checkout has a similar option, though I've only written cart processing that sends you to Google to complete payment.

          • Not necessarily... Paypal Express checkout does not send you to Paypal - you send the data to be processed from your own site via SSL of course and receive confirmation of processing completion.

            OTOH this doesn't require you to store the CC info. In fact no payment system requires that you store the CC info and it is bad practice to do so. Some businesses like to store the CC info to enable the 1-Click purchase method because they are very much impulse buy stores or think they are.

            The only reason to do any o

    • Except, unless something changed, Amazon payments requires *the customer* to have or obtain an Amazon account, something which I find offensive for processing a single payment. This is where PayPal wins over so many others despite sucking in a multitude of ways.

  • by Anonymous Coward on Monday August 17, 2009 @01:38AM (#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.

  • Farm it out. (Score:5, Interesting)

    by Gordonjcp ( 186804 ) on Monday August 17, 2009 @01:41AM (#29088951) Homepage

    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:1, Informative)

      by Anonymous Coward

      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 cha

      • The audit itself costs €20k;. The cost of passing it is probably more on the order of $150k.

        • by bradley13 ( 1118935 ) on Monday August 17, 2009 @03:40AM (#29089297) Homepage

          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?

          • by omz13 ( 882548 )

            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.

            • by aix tom ( 902140 )

              Not here. Here you can pay almost everything with direct debit.

              The only reason I have a credit card is because I have to order stuff from the US sometimes.

              And also being in an IT department of a retailer which used direct debit, and ponders every now and then whether to also allow credit cards, but always decides not to, I can also say the setup on the retailer side is also simpler and cheaper. (About a quarter of the cost credit cards would have)

            • Up here in Canada, we have the Interac [wikipedia.org] direct payment system.

          • by Nicolas MONNET ( 4727 ) <nicoaltiva@gmail.c3.14om minus pi> on Monday August 17, 2009 @04:46AM (#29089501) Journal

            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.

          • by afidel ( 530433 ) on Monday August 17, 2009 @09:57AM (#29091999)
            Can we please find a secure way of using direct debit, so we can cut the credit-card companies out of the loop?

            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.
            • by tlhIngan ( 30335 )

              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.

              The interesting thing is, direct debit here has merchants charging extra for it. Buy something, show your debit card, ding, $0.25 more is automatically added. (CC merchant accounts forbid

          • PCI is not only another revenue stream it is an attempt to effectively offload all security concerns from the companies that benefit from credit cards i.e. the ISOs, processors, and Visa/Mastercard themselves onto the companies that can ill afford it and are already paying extraordinary interchange rates (in the USA at least) to subsidize customers rewards cards.

            Visa/Mastercard have the means to devise a secure system. PCI compliance is NOT secure. You are only certified for the instant that your survey is

    • Re: (Score:2, Informative)

      by Fo0eY ( 546716 )

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

    • by jimicus ( 737525 )

      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.

    • Comment removed based on user account deletion
      • 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.

      • by pegr ( 46683 )

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

  • well, duh... (Score:4, Informative)

    by dirtyhippie ( 259852 ) on Monday August 17, 2009 @01:43AM (#29088961) Homepage

    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)

      by Opportunist ( 166417 )

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

    • Re:well, duh... (Score:4, Informative)

      by MtlDty ( 711230 ) on Monday August 17, 2009 @02:06AM (#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.

      • 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,

    • Re: (Score:1, Informative)

      by Anonymous Coward

      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 accredidati

  • by jasomill ( 186436 ) on Monday August 17, 2009 @01:47AM (#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 (Score:4, Insightful)

      by jdigriz ( 676802 ) on Monday August 17, 2009 @02:17AM (#29089071)
      Shows a healthy distrust of salesmen. Even if they're not actually dishonest, they are frequently clueless.
    • Re:Consideration (Score:4, Informative)

      by Fo0eY ( 546716 ) on Monday August 17, 2009 @02:23AM (#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 (Score:5, Insightful)

        by dzfoo ( 772245 ) on Monday August 17, 2009 @05:09AM (#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.

        • by Fo0eY ( 546716 )

          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.

          • by dzfoo ( 772245 )

            And what "hype" is that? That Amazon's EC2 and S3 are PCI compliant? I've never heard such a claim.

            Amazon even offers a payment processing service, for an additional fee. Why would they take the risk involved in compliancy for their cheaper solutions?

                    -dZ.

          • by dlgeek ( 1065796 )
            Really? You've suspected that a cloud computing provider might not allow PHYSICAL ACCESS to their machines which is required by a PCI Level 1 Audit? Given that the point of EC2 is you can run on any machine with free power, that means physical access to every single computer in their cloud. Gee, I'm shocked.

            As they said, a Level 2 audit which involves remote-probing is certainly fine.
      • Re: (Score:3, Insightful)

        by imag0 ( 605684 )

        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]

  • by netpixie ( 155816 ) on Monday August 17, 2009 @01:49AM (#29088981) Homepage

    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.

  • by julesh ( 229690 ) on Monday August 17, 2009 @02:05AM (#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?

    • by threephaseboy ( 215589 ) on Monday August 17, 2009 @02:29AM (#29089127) Homepage

      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.

    • 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)

        by CoccoBill ( 1569533 )

        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.

        • 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: (Score:2, Informative)

            by CoccoBill ( 1569533 )

            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

            • 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 c

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

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

    • 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 person in charge of the scan just need to ACK the false positives as such.

      • by CoccoBill ( 1569533 ) on Monday August 17, 2009 @06:57AM (#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.

    • by jonnyj ( 1011131 ) on Monday August 17, 2009 @03:49AM (#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.

      • 3rd party PCI compliance audits, or at least the sort we used to pay for, are a joke. We used to have them done despite the fact that we don't need to be PCI compliant. They're little more than simple port scans. It's ridiculous, and they charge lots of money for this.

    • 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

    • by Maudib ( 223520 )

      I am fairly certain that one can be PCI compliant so long as you never store or relay unencrypted card information on your systems. This means that most ecommerce solutions can be put on EC2 without violating compliance, simply by relaying the encrypted card information from the client to the PCI compliant facility/credit card gateway.

      Unless you actually need to view/store the CC information, I don't think EC2 and PCI level 1 compliance will be an issue.

  • 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?
    • by pmontra ( 738736 )
      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?
  • Am I the only one? (Score:4, Insightful)

    by IBBoard ( 1128019 ) on Monday August 17, 2009 @02:59AM (#29089203) Homepage

    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?

  • A better article title:

    PCI confirms not future compliant
  • by CoccoBill ( 1569533 ) on Monday August 17, 2009 @03:29AM (#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.

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

    • 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.
    • Mastercard now requires on-site audits for Level 2 service providers.
  • This article makes none. Seriously, what the heck ?
  • Achronym soup. (Score:3, Insightful)

    by jotaeleemeese ( 303437 ) on Monday August 17, 2009 @04:44AM (#29089495) Homepage Journal

    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)

      by dzfoo ( 772245 ) on Monday August 17, 2009 @05:17AM (#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.

      • AWS: Amazon Web Services, an API offered by Amazon

        I see what you did there...
        • by dzfoo ( 772245 )

          Ha! Sorry.

          AWS: Amazon Web Services, a programming interfaces so that applications can interact with Amazon's back end.

                  -dZ.

      • S3: and boy is it! I was pricing it and my estimate for my needs is 48 cents a month.

    • 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?

      If you don't know what the terms mean, you're extremely unlikely to care about this news story...

      Pretty self-regulating in that regard, except for the few people that feel the need to expouse their views that /. should be dumbed down to the point that it becomes CNet.

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

  • Virtualization (Score:4, Informative)

    by bobaferret ( 513897 ) on Monday August 17, 2009 @07:22AM (#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.

    • 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?

      • The nice thing about the ref-policy is that you can set your machine up so that root has no powers. Or even so root has no powers remotely. It took about a month, but what we ended up with is a situation involving roles that always requires two people in order to preform some change to the system. For example, I can't as the sysadmin, can't upgrade a file or even run 'ps aux' w/o the security admin dropping the enforement. the security admin cannot drop the enforcement remotely, he can only do it if I or th

  • by denmarkw00t ( 892627 ) on Monday August 17, 2009 @08:39AM (#29090863) Homepage Journal

    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.

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...