Announcement

Collapse
No announcement yet.

PCI Implications of Custom Modules

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    PCI Implications of Custom Modules

    Do custom modules installed in Miva Merchant impact the PCI certification of the software? I started thinking about this after comments on another thread that running PHP scripts on the same site as Merchant would bring them into PCI scope, and it seems like the same would apply to modules. Those aren't part of the core that gets certified, yet they can access payment information. How does that work?

    #2
    I may not be precise, but I think I have some accuracy here.

    Regarding 3rd party/custom modules, I don't think the payment info available, if any, would be an issue if the Miva version is the latest. Which version was it that forced CC Simple validation to be encrypted with a passphrase? I personally have come up with valid reasons to try and bypass and get info, but there isn't a way.

    I've have written a KlarnaPay Credit module. This was also safe according to Klarna because it was using their iFrame technology.

    I don't think I can answer directly about customer name and address' and how much of that is directly in the PCI scope because IMO, there is no direct access or cross-reference to CC/Payment data except for the last 4 digits of a CC in some cases. That means you don't even know the CC type.

    I'd bet Rick or Brennan will give notice of a secure environment or not.

    FWIW,

    Scott
    Need to offer Shipping Insurance?
    Interactive Design Solutions https://www.myids.net
    MivaMerchant Business Partner | Certified MivaMerchant Web Developer
    Competitive Rates, Custom Modules and Integrations, Store Integration
    AutoBaskets|Advanced Waitlist Integration|Ask about Shipping Insurance Integration
    My T-shirt Collection is mostly MivaCon T-shirts!!

    Comment


      #3
      We should differentiate between PCI certification and PA-DSS validation. An entity gets certain, or all, operations certified, while a piece of software gets validated. One can make the other easier; if you're intent on obtaining, or required to have, a PCI certification, and you make use of PA-DSS validated software for the credit card handling, then parts of your certification that would have otherwise had to delve into your software can just reference the software vendor's validation.

      Miva's ongoing PA-DSS validations for specific versions of Miva Merchant are performed without third party modules added into the validated software. Operating a copy of Miva Merchant with third party modules would technically be a deviation from the validated configuration. However, to touch on the question of payment data, if a module is using the proper Miva Merchant functions to access that data, then the relevant security rules and privilege requirements would be applied, and logging would occur.

      The concerns that I often voice on the forum over running php applications on the same site with Miva Merchant are not actually specific to php, it just tends to be the language of choice for most popular web apps we find customers wanting to install. That popularity has also often resulted in those web applications having remotely exploitable security issues found, as there is a lot of php code being written by people not formally trained in programming. Last but not least, php being plain text makes for a VERY easy place for an attacker to hide a back door to let themselves back into a site they have compromised. For example, a typical Wordpress installation may have hundreds of php files, if not thousands. Three lines of code added to any of them would permit someone to get back into a site they'd previously compromised compromised, and it is nearly impossible to detect as it requires just simple functions that would have legitimate use in other non-compromised files. It would make me extremely uncomfortable having a Wordpress install parallel my Miva Merchant install.

      If a web application, or Miva Merchant third party module, has a vulnerability or 'feature' that permits a remote attacker to bypass security measures of Miva Merchant, security measures that PCI and/or PA-DSS may require, then that could potentially come under scrutiny if a credit card data compromise occurred and investigation ensued. Four potential issues with modules that come to mind immediately:
      • Allowing unauthorized remote operations to occur. Example; there was a third party module with a SQL injection vulnerability. The types of code reviews and testing PA-DSS requires would have caught the issue.
      • Allowing certain operations to occur without a permission Miva Merchant would have otherwise required of a store user. Example; this could happen if a developer used database operations to access data for a store user when an equivalent function call would have prevented it for the user in question.
      • Operations that are performed without a system event log entry being triggered when it would have otherwise been required.
      • Allowing access to the store database directly; example, there are modules out there which allow SQL queries to be sent to the database. These modules effectively bypasses all security other than the initial login, and allows any operation to be performed without it being logged.



      A definitive list would likely be much longer. We can't give legal / liability guidance, and a PCI QSA (Qualified Security Assessor) would be required to properly review any given business' operations for whether something they're doing could be a PCI issue. A QSA would also be able to analyze what potential impact any of the above would have. So, unfortunately I can't give you a yes or no answer on whether you should have concerns or not. I can say there are certainly numerous modules that I'd be surprised if an assessor would show any concern over, but there are also others that could allow someone with store admin access to do things they shouldn't, or elevate their privileges, all without logging, so that could certainly warrant greater scrutiny.
      David Hubbard
      CIO
      Miva
      [email protected]
      http://www.miva.com

      Comment


        #4
        Thank you for the detailed responses.

        Originally posted by ILoveHostasaurus View Post
        Operating a copy of Miva Merchant with third party modules would technically be a deviation from the validated configuration.
        This gets to the crux of what I was thinking about. Are we invalidating that PA-DSS validation by installing third-party modules and opening ourselves up to a more invasive PCI certification process? Is it incorrect for us to just say "we're running Miva Merchant and here's its PA-DSS validation information" when we're not operating the software in the validated configuration?

        Comment


          #5
          Well you're losing the benefit of our PA-DSS, you're not "invalidating" anything, you simply can't rely on our validation to make your PCI Certification easier.

          The thing being lost in translation here is merchants technically if they're in scope are supposed to hire an auditor and virtually none do because there's virtually no enforcement for anyone who's not a top 100 or 500 merchant.
          Thanks,

          Rick Wilson
          CEO
          Miva, Inc.
          [email protected]
          https://www.miva.com

          Comment


            #6
            I spoke to our auditor and he said that an entity going through PCI certification would have their assessor 'consider' the use of the third party modules and make a determination as to whether what has been installed, or how it's configured/used, requires validating the entire installation. He also said PA-DSS is going to be replaced with something else late next year so we'll have to see how that shakes out as well.
            David Hubbard
            CIO
            Miva
            [email protected]
            http://www.miva.com

            Comment


              #7
              When you say "It would make me extremely uncomfortable having a Wordpress install parallel my Miva Merchant install." do you mean sharing a database?

              Comment


                #8
                Originally posted by kayakbabe View Post
                When you say "It would make me extremely uncomfortable having a Wordpress install parallel my Miva Merchant install." do you mean sharing a database?
                It would take a very deliberate violation of PCI guidelines to share a database, so I was not directly addressing that. A payment application should not have its database credentials stored in clear text, so connecting some other app to the same database would require either extracting those credentials in a manner that shouldn't be possible, or explicitly adding additional user(s) to the payment application's database for connecting another app. If that were done, the other app could have not only access to the data, but the ability to change the data, independent of any security measures or audit logging the payment application has in place.

                What I was talking about in the paragraph with that sentence is where you have your Miva Merchant, or other payment application, in a different directory from Wordpress, on the same website, or, running as the same user under the same directory structure, which would give it the ability to manipulate the files of the payment application. That is incredibly dangerous, not only because of the potential access, but because of how easy it is to hide back doors in php files, and when there are thousands of them that could potentially hold the necessary couple lines of code, there's simply no way to ensure security.
                David Hubbard
                CIO
                Miva
                [email protected]
                http://www.miva.com

                Comment

                Working...
                X